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 これがシングルスレッドおじさん再登場の瞬間であった シングルスレッドだけで出来る仕事って限られてないか。通信なんか絡んだらマルチスレッド必須でしょう。私の現場は.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作ってみろ、って恫喝的に書いたろ。
あのフォローをしてくれ。論理的に。 >>233
たびたび訂正ですがアンカ間違えた。
すまん。 わかりやすく発狂してんなー
初学者どうたら言うんならもっと普及してるもん押すべきじゃあないの?
言っとくけどC#自体は他でも使われてるからなUnityとか
>>229
毎度再現するんでもないからなー
Formでは一回も落ちたことないからXAML関係が比較的不安定なのはそうじゃないの >>235
見っともないぞ。
昔からいる古狸かも知れないが、もっとちゃんとしろ。
初学者惑わす書き込みを堂々とするのはやめて、自分の考え披露するのは構わないけど。 アンカさえまともに書けないやつがコード書けるのか？ >>237
ごめん。
ちょっと酔っ払って熱くなった。
もうここらで寝ます。
>>238
ご心配いただきありがとうございます。 >>241
.NET Core Global Toolsおもしろいよね フォームアプリケーションで
A.初期設定画面
表示する円の大きさ、数、表示座標の範囲などの初期値を設定
B.ゲーム画面
初期設定画面からAの初期値を取得し、メンバ変数に代入して
円を表示する
円を消去する
円の当たり判定をする
などの3つぐらいのメソッドで使用しています。
Bのコードが長くなって200行ぐらいになると、
メンバ変数をどこで使ってるのか全部見なければいけないのは
可読性が悪いのかなと思うようになってきました。
3つのメソッドそれぞれのグループ変数として
それぞれ3つのメソッド内でAの初期値を見に行くコーディングをしたほうが良いのでしょうか？
メンバ変数の方が冗長性はないけど可読性が低くて、
メソッドないのグループ変数にしたほうが冗長性が高いが可読性も高い気がします。
独学でコーディングしているので、お仕事でプログラミングされている方のご意見を伺いたいです。 >>243
Aが入出力と, モデルのデータ保持という3役を担っているのが良くない。
出力が本業なので可能ならばそれに特化するが, 差し当たってはデータ保持を分離して別クラス(モデル)に切り出す Aは
public int GetTimeLimit
{
bool resultOfGetTimeLimit = int.TryParse(this.timeLimit.Text, out int timeLimit);
if (resultOfGetTimeLimit)
return timeLimit;
else
return 0;
}
が10個ぐらいあるだけで、Aの可読性はいいのですが。
Bのクラスから→Aのインスタンス生成→フォーム表示しているので、
Bが
1. Aからの初期値取得
2. 取得した初期値でゲーム画面表示
3. ゲーム中の処理
4. スコアデータとAの初期値テキストファイルへの書き出し
という4つの異なった処理（特に2,3のコードが長い）をしているのと、
Aのコードの量も400行近くになっているのが可読性低下の原因かと思います。 Bの別のクラスを作って分離させたいんだけどBからAのインスタンス生成しているので、
BAの画面処理に基づいた1234はすべてBに入れることになってるんですよね。
これって画面遷移が良くないってことなのかなぁ？
一般的に1234の処理を一つのフォームクラスに押し込んでクラスメンバ変数10個程度、
400行のコードって可読性の観点から許容されるものなんでしょうか？
チームでプログラミングされているプロの方の意見をお伺いできればと思います。
（長文本当に申し訳ありません） 人の話聞いてないねｗ
じゃあもう好きにしたらいいと思うよ ■ このスレッドは過去ログ倉庫に格納されています
