C#, C♯, C＃相談室 Part93©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/
■コードを貼る場合はこちら
http://ideone.com/
■前スレ
C#, C♯, C＃相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured とりあえず一般的には
FindWindowやEnumWindowsで目的のウィンドウのウィンドウハンドルを手に入れて
SetWindowPosする
>>133のウィンドウがこれでできるかどうかはそのプログラムの作り次第 >>134
ありがとうございます
それで移動、サイズ変更できないウィンドウをどうにかできないかなと思い質問してみました
ユーザーが移動サイズ変更できないウィンドウでも強引にしてしまうプログラムがあるらしいので、どうしてるのかな？と >>135
とりあえず直接のC#の話でなくWinAPIなんだからそっちで調べた方がいいと思うよ ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 厳密に言うとC#の話じゃないんだけど
TcpClientでコネクション使い回しというか
開けっ放しでデータ送り切るって出来ない?
flushしてもデータ残っててCloseしないと全部送られない そんな複雑な話じゃないんだ
GetStream()でストリーム取ってWrite()するだろ
でもClose()しないとケツのいくばくかはいつまで経っても送られない
断続的に送りたいから、いちいちClose()してからConnect()やり直すとかしないで済む方法あるか知りたい 質問です。
非同期実行について勉強中です。
以下のサイトの内容なんですが、
https://ufcpp.wordpress.com/2012/11/12/asyncawait%E3%81%A8%E5%90%8C%E6%99%82%E5%AE%9F%E8%A1%8C%E5%88%B6%E5%BE%A1/
ページ中ほどにある
"スレッド プール実行"
の
"一方、内側は、スレッド プール上での実行になりますが、スレッド プール上のコンテキストではawaitしてもスレッド プール上のどこかで実行されるだけで、決してUIスレッドには戻らなくなります。"
の意味が理解できません。プール上のどこかで何が実行されるのでしょうか？
また、その下の”問題となる書き方の例”
の
”Task.Runの中のawaitでは、単一スレッド実行にはならないので、lockが必要になることがあります。”
理解が出来ませんでした。
2連続someTask()は同時に実行されるという意味でしょうか？ スレッドは使い捨ての領域だから、
その中で遅延実行しても戻り値は受け取れないよ
だって戻る領域が数秒後も存在しているか分からないからね
って意味だと思う マルチスレッドなんて、素人がやるものじゃない。
Ruby を作った、Matz でさえ、何十年もやっていないのに
OS・CPU が今、どのプロセスのどのスレッドの、どの実行コードを実行しているのか、
君のプロセスのスレッドから、わかるわけないでしょ
同期処理じゃないのに。
バラバラに、無関係に動いているのに
逆に言えば、バラバラに動くスレッドの、
現在実行中のコードがわかるのなら、それは同期処理になる これがシングルスレッドおじさん再登場の瞬間であった シングルスレッドだけで出来る仕事って限られてないか。通信なんか絡んだらマルチスレッド必須でしょう。私の現場は.net3.5なんでback|ground work|er使ってるよ。 >>150
確かそうです。
taskとか使えると楽なんですが4.0強制もできない案件なんで。 どうしても.net3.5を使わないといけないんだったらRxで処理するわん おっ！
いいこと教えてもらった。
Rxってsilverlightだけじゃないんだ。 そんなの使えるなら.NET4だって使えるでしょw
3.5が使えて4が使えないプラットフォームは存在しないと思うけど お客様のPCがWindows7ならデフォルトで3.5が入ってるでしょう。4.0にしてから使ってくださいとは言いずらい。 ちょっと前までUnityも3.5止まりだったから多少はね? ググれは正論だけど、せっかく話題になったんだからここの住民の意見も聞いてみたい。使ってる人の感想とか。 全然関係ないけど、receiveの略が何でRxなのか昔から結構謎 それ組み込みの世界だね。送信ポートはTxだ。スレチだね。 インストールされている証明書の読み取り、エクスポートをやりたいんだけどさ
ググるといろいろ出てきてX509とかってのを使うと良いとある
まだ実装とか全然なんだけど、この情報だけだと不安なのでだれかやったことのある人いない？
X509Cartificate.Exportはバイトデータを吐き出してそのままファイルに保存できるるっぽいけど、秘密キーを設定したいとかあったりしてモヤモヤしてる ﾜｯﾁｮｲなしスレが1000行ったからこっちをage windowformアプリケーションで
form1 ディスプレイの解像度等を入力する。入力したデータをもとにform2に表示する長方形の大きさ（rx,ry)を算出
form2 form1で算出した（rx,ry）をもとに長方形を表示
ってしたいんだけど
A. rx,ryをpublicで定義してform2.csから参照する
B. form1のrx,ryを求める計算式をクラスにしてform2からインスタンス生成して求める
のどちらがお作法的に正しいんでしょう？ データとUIを分離するとして、データ保持と計算用のクラス、formは入力のみ、表示のみって感じになるのかな
でも、まぁそんなのAでもBでもいいだろ
関係ないが解像度ぐらい自動で取得してくれると楽 なんとなく、こういうのを"お作法"と呼ぶマにはいいイメージがない >>168
ありがとうございます。
解像度は自動取得なのでディスプレイの㎜サイズでした。 >>169
すいません。
プログラミング初めて勉強なので、なるべくへんなコーディングしないように可読性高くと考えてまして、
普通はどう描くんだろうなというところが気になって仕方ない。
public変数作りすぎると、後でどこかで変に触るとわけわからんことになるのかなと極力使わないように心がけてます。 何かフリーソフトを作ってみたくて勉強しているところなのですが、GUI？を学ぶ上で良い本があれば教えていただきたいです >>171
フォームは入力の受付と出力の描画だけをする
内部で使うデータはモデル側で持つ >>173
それでいってみます。
ありがとうございます。 連投すいません。
ユーザー側でフォームのサイズを変えたとしても
常にフォーム右端にボタンを固定する方法ってないでしょうか？ >>175
ボタンのAnchorのプロパティをTop, Rightに変更 >>176
Anchorって設定があったんですね。
できました！
ありがとうございます。 Form1で作成したmethod1をForm2で使用したい場合どのようにすればいいのでしょう？
Form1.method1();
だとエラーなのですが、form自体がクラスだからインスタンス生成が必要ということでしょうか？
本当に初歩的な質問ばかりですいません。 駄目だ煮詰まってきた。
Visualstudioで新規ソリューションを作成して、既存のソリューションからフォームを追加したのですが、
フォームデザインでは新規フォームが表示されているだけ、.Designer.csを除くときちんとコードが記載されているのですが、
[デザイン]:の画面では反映されておらず、この画面でコントロールを追加などするとエラーがでてビルドできなくなります。
フォームの追加の仕方が間違ってるのかなぁ。 >>181
エラー CS0121 次のメソッドまたはプロパティ間で呼び出しが不適切です:
'InitalMonitorSetteing.InitializeComponent()' と 'InitalMonitorSetteing.InitializeComponent()'
エラー CS0111 型 'InitalMonitorSetteing' は、'InitializeComponent'
と呼ばれるメンバーを同じパラメーターの型で既に定義しています。
です。 ソリューションエクスプローラーで
追加→既存の項目
でフォーム一切合切を取り込むと
フォームの[デザイン]タブのところで新規のフォームが表示され、これをいじると上記エラーが出ます。
フォームの[デザイン]タブをいじらなければ正常に実行されます。
.Designer.csを見るときちんとコードが書かれているので
[デザイン]と.Designer.csが一致していない状態になっているようです。 地道に
フォームのデザインすべてコピー貼り付け
コードすべてコピー貼り付け
ってやって追加しました。
なんかネットで見ると、
ソリューションエクスプローラーで
追加→既存の項目
でフォーム一切合切を取り込む
ってやると後々まで得体のしれないエラーに悩まされるので、上の方法を推奨している方がいました。
Visual Studioかフォーム自体の持つバグなんですかね…。 ～VS2015しか使ってないが俺はエラー起きたことないよ。原因分からないけど、何かやらかしてるんでしょ 無闇にコピペした結果を環境のバグとか
プログラム向いてないよお前 失礼しました。
私がよく理解していないために、しなければいけない作業をしていないのかもしれませんね。 むしろしちゃいけない作業をしてるような気がする... >>178
そもそもこの質問の時点でFormsのコード部分が何をやってるのか理解できてない可能性がある 基礎も身につけずに一端のフリして解決しようとして、半端で折れるバカってのはよく聞く話
とりあえず何か入門書籍に頼って動くものを作れ
話はそれからだ >>184
情報共有する場所なんだからこういったいいかげんなこと書くのやめてほしいな
まずソースをそのまま取り込みたいのならプロジェクトに追加で何も不具合は起こらない
それでデザイナが反映されないのならDesigner.csを直接書き換え(認識できなくなるような書き換え）やっているはず
あとユーザーコントロールを内部で追加している場合は一度ビルドするとデザイナで反映される
プロジェクトでなくソリューションにソース追加しても当然何も起こらない
最初からふらっとにいけばいいのに WinFormのデザイナは中途半端に内部実行するからしょっちゅうトラブるんだよな
コンストラクタでなんかやってる奴は特に要注意 フォームをコントロール含めて継承すると継承先でコントロールの編集ができなかったり云々
という書き込みを見たので、
そこで提案されていた新規フォーム作成して
そこにコピペとしてみて結果オーライだったのでそれで良しとしたのですが、
私の方でなにか既存のフォームを取り込むのにまずいことをしてたのかもしれません。
記憶にないけどDesigner.csを直接書き換えしたかなぁ・・・。
フォームで作成するかWPFを使うかを悩んでた時にフォームは放置されたバグが多いと警告されていたので、
単純にバグなのかと思いましたが根拠なくソフトのバグと書き込むのはまずかったですね。
失礼しました。 FormかWPFか悩んでるならWPFを推す。
最初は難しいがXAMLはUWPでも使っていて今後につながると思う。 今後ピクセル単位でのUI作成は完全に無くなるからなぁ 多段継承してるカスタムコントロールはぶっ壊れやすい
Winアプリ作らにゃならんならWPFのがマシってのはまあそうだ
でも将来性あるとは思わんな WPFそのものの将来性はともかくとして、その技術のエッセンスが次代に引き継がれると思うんです。
今後もWinアプリを開発することになるんで、なるべく将来性と言うか潰しのきく技術に投資したいと思ってWPFにしたんだけど。 >>199
それはないよw
継承の段数は関係なくて、単にコントロールのカスタマイズは意外と難しいってだけの話
俺も経験があるけど簡単にシステム側のバグを疑いたくなる現象にぶち当たるけど、
ほとんどの場合はプログラマの理解不足によるユーザーコード側のバグが原因 潰しがきくってんならなおさら独自仕様なんぞあかんやろ
WPF出てから何年経ってるよ
他に採用してるとこないのはそういうことだ >>201
いや正確にはシステムがぶっ壊してるんじゃなく
レイアウト決定だの初期化順番だので罠にはまる確率がガンと上がるって話
コントロール1種を少々カスタマイズしたくらいじゃあんまハマらんさ GDIが使えない時点でゴミ
WPFでCADを提供してみろ >>202
対案示してくれると検討もできるんですけど。 >>206
オプショナル独自仕様なんぞわざわざ覚えんでもC#だけ抑えときゃいいじゃん formとwpfどっちかじゃなくて、状況に応じてどっちか使えばいい
言語だってそうだ。c#に拘らず、必要に応じてほかの言語も使えば楽になるぞ
縛りプレイとか馬鹿臭くてやってられん xamlが単なるコードトランレート言語だったなんて知らなかったんだよ。 >>207
まさかの浅い答えでしたね。
今時、なんか開発する時は言語だけじゃなくAPIとかプラットホームとのセットじゃないの？ 最近form触る機会あったけど、WPFになれた後だとバインディングが面倒でならない
formはformでわざわざ部品探したり作る必要ないから良いんだけどね なんか変なイチャモン付けてる人いるけど。
CAD作れるかとか、Formならできるの？
Windows、.net、C#でGUIアプリ作るならFormかWPFしかないじゃん。
Formは終わった技術で行き止まり、WPFは普及しなくて過渡的な技術になるかも知れないがその先につながりそうでって言ってんです。
もっと論理的に反論して欲しいです。 >>215
昔から居てもアホな書き込みすると初学者は惑わされるのよ。
自分が理解出来ない技術はみんなダメって言ってないか？
ちゃんと論理的に反論してよ。
出来ないなら駄まってろ。 formでCAD作ってる奴ぐぐると日本人でも複数いるよ >>214
お前さんみたいな銀の弾丸求める奴ぁ先がないぞ
XAMLは文字列だらけで設計の筋がいいとは到底言えない
もし次があるなら全然違うもん出してくるんじゃないの >>217
FormでできるならWPFでもできるだろう。
Formの優位性は何？ >>218
XAMLは面倒よ、たしかに。
でもね、オレは使ってないがGUIのリソースエディタがあるんじゃないか？
なくても直ぐにできるよ。 >>218
UWPもXAMLだよ。
MSは当面これでいくんじゃないの。
あんたよりMS信じる。 XAMLの筋が悪い一例としてIDEサポートがHTMLにすら劣る点が上げられる
今でも時々vsごと落ちる
まあ次が出る前にWinアプリ自体がオワコンになる可能性も低くないけどな
あんたの人生だから好きにしたらいいよ >>222
XAMLでの開発3年弱だがVS落ちた経験ないよ。
Winアプリがオワコンになるんだったら、早いとこ他の言語・環境に移行したら？
オレはWinアプリだけじゃなくタブレットとかスマホにも適用できると思ってるから、この道行くよ。 >>222
俺も落ちたことないんだけど、どんな環境で何したん？ WPFはもちろん最良ではないけど
すくなくとも現行のUWPと共通のXAML使ってるぶんFormsよりは十倍マシ メモリ8Gで5段くらいネストした奴編集してたらストンと落ちたぞ
vs2015だ
>>225
「現行では」比較論でまあせやな
将来性は怪しいが >>226
ハードウェアアクセラレーションの問題ではなくて？ >>226
すごいな。なかなか落とせるもんじゃない。
そんなにWinの将来に悲観的なら、本当にどこかに行ってください。
間違った書き込みを堂々と恫喝的にされると初学者の道を誤らせるよ。
それって罪なことです。
このスレタイでは。 >>229
他の環境はそんなに安定してるのか？
VSが特別に酷いとは思わないけど。
MSデスってなんでここにいるの？ >>230
俺がいつMSをデスった？いつ他の環境と比較した？
ID:OZSh5wZJ0と間違えなさんな >>231
Winアプリはオワコンって言ったろ。
それより、CAD作ってみろ、って恫喝的に書いたろ。
あのフォローをしてくれ。論理的に。 ■ このスレッドは過去ログ倉庫に格納されています
