ふらっと C#,C♯,C＃（初心者用） Part137

2018/04/06(金) 17:40:19.48

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part136
http://mevius.5ch.net/test/read.cgi/tech/1520057345/

■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2018/06/04(月) 21:56:07.60

>>970
Mono Releases | Mono
http://www.mono-project.com/docs/about-mono/releases/

2018/06/04(月) 23:32:00.59

メインクラスとシリアル通信クラスの2つを使っています
シリアル通信の受信完了でイベントをメイン側に発生させることら可能でしょうか。受信完了したらメイン側から受信データを取りに行くようにしたいのですが。

2018/06/05(火) 00:07:28.69

>>976
何でそうなるのw
発想が逆だってw

そのシリア通信を担当するクラスSがデータ受信を通知するイベントを発生させて
受信したデータを利用する側がSの参照を握ってイベンを受信すればいいでしょw

ついでに言えば受信データもEventArgs使って渡してしまえばいい

2018/06/05(火) 00:33:25.52

しょうがねえだろ初心者なんだから

**976** (ﾌﾞｰｲﾓ MMbe-fUxx) · 2018/06/05(火) 07:18:51.35

>>977
やりたいのことはそれなんですよw
説明が下手ですいません
厳密にはデータを受けた事が分かったらメイン側は受信データの内容を解釈するクラスに送って処理分岐という形にしようかと思ってます。
用語や処理の知識がおいついてきてないので、あれを応用しようという感じにならず、調べるためのキーワードも出てこないです。

>>クラスSがデータ受信を通知するイベントを発生させて受信したデータを利用する側がSの参照を握ってイベンを受信すればいいでしょw

ここが具体的にどういう構文になるのでしょうか。

2018/06/05(火) 08:07:17.14

Signalを使っても作れるな。

2018/06/05(火) 09:11:21.09

>>958
PCをあまり使い慣れてない人とか、ボタンはシングルクリックでいいのをダブルクリックしちゃったりとかあるんだよなこれが・・・

2018/06/05(火) 09:29:57.56

非同期じゃないならボタンイネーブル切ればいいだけじゃね

2018/06/05(火) 09:32:16.99

すまん。忘れてくれ

2018/06/05(火) 10:35:58.82

状態をGUIだけに持たせておくのはおかしいといつか思うはず

2018/06/05(火) 12:11:20.04

>>979
class FrameReceivedEventArgs:EventArgs
{
　　public byte[] Frame{get; private set;}
　　....
}

class CommunicationPort
{
　　public even EventHandler<FrameReceivedEventArgs> FrameReceived;
　　....
}

class FrameDecoder
{
　　public FrameDecoder(CommunicationPort c}
　　{
　　　　c.FrameReceived += CommunicationPort_FrameReceived;
　　}

　　private void CommunicationPort_FrameReceived((object sender, FrameReceivedEventArgs e)
　　{
　　　　....
　　}
　　....
}

2018/06/05(火) 12:44:05.86

>>985
引数に渡されたものを弄るのは行儀の悪い設計
IReceiverインターフェイスみたいなのを用意してport.AddReceiver(decoder)とするか、
>>979の言葉通りにいったん双方のクラスの外でイベントハンドラで受けて仲介したほうがいい

2018/06/05(火) 12:51:41.81

>>985がなぜ行儀が悪いか補足しておこうか
普通、オブジェクトを別のクラスのコンストラクタに渡すとき、プログラマは　受け取った側→引数側　の向きの参照ができることを期待する
ところが、>>985だとそれが逆なんだよ
new FrameDecoder(this.port) としただけで、portがGCされないかぎり作り捨てたはずのFrameDecoderがGCされないという、非直感的なコードになるわけ

2018/06/05(火) 12:55:30.14

何言ってるのかさっぱりわからん
よくわからん思考回路だな...

2018/06/05(火) 13:09:28.12

言い回しがようわからんが
>>985みたいなのするのが解放されないオブジェクトを量産するっていうのはなんとなくわかる

2018/06/05(火) 13:11:38.32

>>988
分からないならイベントというものを正しく理解してないんじゃないかな
ボタンのクリックイベントをフォームが受け取れるのは、ボタンがフォームへの参照を(実際には間にデリゲートが入るので間接的にだが)持ってるから
基本的に、引数に渡ってきたものに自分自身を登録するのは避けたほうがいい
オブジェクトのライフタイムが非常に分かりにくくなるから

2018/06/05(火) 13:53:28.61

reactive extensionsって.NET発祥なのに使う人少ないよね

2018/06/05(火) 15:23:49.06

>>969
ちょまど神って？？？状態でしたので調べてみました。
一つ知識が増えました。ありがとうございます。

2018/06/05(火) 15:24:19.24

>>970
そうなんですか。。。
NET Coreっての調べてみます。どうも有難う御座います。

ちょど昨日　GUI　って何だ？？って検索したばかりでした。
３日前からプログラムの勉強をはじめたばかりで。。。

2018/06/05(火) 15:24:34.93

>>975
ありがとうございます。TRYしてみます。

この掲示板すごーい！！皆様に感謝です。

2018/06/05(火) 16:15:32.44

>>989
ないないw
イベントの購読解除はリークの原因になるのはその通りだけど、
それは>>986が主張するように、イベントを発生するオブジェクトを引数で受け取ったかどうかと無関係。

>>990
俺は理解してないのは君の方だと思うよw
その君のいう俺様ルール、何が悪いのかさっぱり分からない

そもそも今はそんな話をしてるんじゃないw
単に質問者の参考になるかもしれんコードの骨組みを示しただけw

2018/06/05(火) 16:16:25.51

あ、

× イベントの購読解除
〇イベントの購読解除忘れ

2018/06/05(火) 19:31:17.11

次スレたててみる

2018/06/05(火) 19:33:22.39

ふらっと C#,C♯,C＃（初心者用） Part138
https://mevius.5ch.net/test/read.cgi/tech/1528194762/
たった
議論は他のところでよろしく

2018/06/06(水) 00:18:56.95

>>995
想像力のない人だなあ
>>985だと、イベントハンドラの登録を解除しない限り、FrameDecoderが不要になっても
登録先のCommunicationPortよりも先にGCされることは絶対にない。
じゃあ不要になったらイベントハンドラを登録解除できるようにしよう。いつ解除する？
それはFrameDecoder自身には分からない。知っているとしたら、それは>>976のいうメインクラスだろう。
登録解除するにはFrameDecoderクラスのDisposeメソッドを呼べ、という仕様にするか？
結局、985のFrameDecoderを正しく扱うには、メインクラス側がそういうクラス外から見ただけでは想像できないFrameDecoderの気難しい仕様を理解した上で、
必要に応じて明示的な解放を行わなくてはならない。
そんなことをするくらいならメインクラス側で明示的に登録・登録解除をやったほうが遥かに素直で分かりやすい。

2018/06/06(水) 00:26:33.34

質問いいですか？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 60日 6時間 46分 14秒