C#, C♯, C＃相談室 Part53

C#, C♯, C＃相談室 P ..

237:デフォルトの名無しさん
09/07/12 16:30:51
>>235
>>229のリンク先は読んだの？読んだら、どこが分からなかったの？

238:デフォルトの名無しさん
09/07/12 16:45:01
言語非依存WinFormsスレなんかあってもまず機能しないだろうな
WPFは現状VBerがほとんどいないからこそ専用スレが成り立つ

239:デフォルトの名無しさん
09/07/12 16:50:33
>>238
実際、以前.NETスレがあったが、過疎だった。
みんなC#とかVB.NETのスレへ流れるもんだから。

240:デフォルトの名無しさん
09/07/12 17:01:34
WPFにはXAMLという共通言語があるし
言語とライブラリを混同するようなレベルの初心者ユーザも少ないからな

241:デフォルトの名無しさん
09/07/12 17:17:18
>>212
aboutっていわゆるバージョン情報のフォーム？
だとすると、面倒なことをせずにShow()ではなくShowDialog()で一つ表示する方法が普通だと思うけど

242:デフォルトの名無しさん
09/07/12 17:29:10
>>237
あの…恥ずかしながら、
ユーザーコントロールを追加しましたが、
テキストボックスのパディングをどこで設定するのか…
またはテキストボックスの垂直の位置をどこで中央にするのか…
（水平の中央はありますが）
が分からないんです。

243:デフォルトの名無しさん
09/07/12 17:29:31
>>239
俺もそのスレ見てたわ。
次スレどうしようか悩んだけど、過疎ってたのでやめといたら結局誰も立てなかった･･。

244:デフォルトの名無しさん
09/07/12 17:33:08
Gridの中にテキストボックスを入れるんだよ

245:デフォルトの名無しさん
09/07/12 17:34:11
テキストボックスじゃなくていいならラベルで出来る

246:デフォルトの名無しさん
09/07/12 17:37:31
関係ないけど、WPFではLabelは特殊なコントロールで、普通の文字描画には使わないんだよ
TextBlockというのを使う

247:デフォルトの名無しさん
09/07/12 17:41:23
グリッドってなんだろ…
(T_T)？

ところで、テキストボックスのパディング設定は果たしてできるのかな。

248:デフォルトの名無しさん
09/07/12 17:46:47
Paddingの追加って、こんな感じに入力するだけでしょ。
<TextBlock …… Padding="10">……</TextBlock>

249:デフォルトの名無しさん
09/07/12 17:49:58
Paddingプロパティがあるだろ？
パディングはそのコントロールの親(GridやBorderなど)を基準にして行われる
WPFはとにかくコンテナ(WinFormsでいうPanelみたいなもの)をネストしまくるんだ

250:デフォルトの名無しさん
09/07/12 18:19:59
>>249
それは、Windowsアプリケーションでも可能なの？

251:デフォルトの名無しさん
09/07/12 18:22:24
>>217

252:デフォルトの名無しさん
09/07/12 18:24:16
何この馬鹿は。
やってから言えよカス。

253:デフォルトの名無しさん
09/07/12 18:26:27
Ｗｉｎｄｏｗｓアプリケーションには
textblockとかgridってあるのかな。

254:デフォルトの名無しさん
09/07/12 18:30:15
WinFormsなら無い
ユーザーコントロールに枠線消したTextBoxを張る
みたいな汚い方法しかない

255:デフォルトの名無しさん
09/07/12 19:02:18
ビジュアル重視ならば、
ＷＰＦで作った方がよかったんじゃないかな。
俺もよく知らないけど。

256:デフォルトの名無しさん
09/07/13 00:13:27
見た目こそWPFの領分だね

257:デフォルトの名無しさん
09/07/13 00:55:49
しまったな…
俺もWPFで作れば良かった。
できることはWindowsアプリケーションと変わらないし。

258:デフォルトの名無しさん
09/07/13 01:37:11
何だか勘違いしてるようだけど、WPFで作ってもWindowsアプリケーションだよ。
場合によってはMFCとか.NETじゃないやつまで含んじゃう言葉だから、誤解を避けるためにWinFormsって書く方がいい。

WinFormsで見た目をちょっと改善しようと思ったら、自前で描画するとか泥臭い手段しか無かったというのはよくある話。
WPFでは馬鹿みたいに（褒め言葉）柔軟で何でも出来るけど、設計思想がWinFormsやMFCとは別物の新しいやつだから、最初は戸惑うと思う。

259:デフォルトの名無しさん
09/07/13 07:29:50
そして起動が遅いと言われるわけですな

260:デフォルトの名無しさん
09/07/13 09:54:35
Formでやるなら>>224でいいじゃない

261:デフォルトの名無しさん
09/07/13 11:19:26
ListViewでItemをひとつひとつ.Selected=Trueする方法で選択していくと、
Items.Count が非常に多い場合にはあまりに時間がかかりすぎることが
わかりました。

Items.Count=10000ぐらいで２分ぐらい（Core2Duo/2GHz）。

ところが例えばExplorerでﾌｧｲﾙを同じくらい用意してやってみると瞬時に
全部が選択されました（3秒ぐらい）。これと同じ程度のスピードで選択
したいと思います。良い方法がありましたらご指導のほどお願いしたく。

よろしくお願いします。

262:デフォルトの名無しさん
09/07/13 11:49:28
試したけど3秒くらいだったよ。
イベントハンドラがあったりする？
あと描画関係なら、BeginUpdate - EndUpdateで挟むとか

263:デフォルトの名無しさん
09/07/13 11:59:23
>>262
実地に調べてまでして下さり、大変ありがとうございます！
いろいろすみませんです。

＞BeginUpdate - EndUpdateで挟む

これたった今やってみました。結果として時間の変化はありませんでした。

＞イベントハンドラがあったりする？

わかりました、すぐ調べてみます。どうもです！

264:261
09/07/13 12:15:11
>>262
＞イベントハンドラ

この件、仰るとおりでした。Selectされた時点で、何かのメッセージの
Hookが行われているようでした！これは別のコントロールのものでしたが
対策を考えてみます。ご指導、大変どうもでした！助かりました！

265:デフォルトの名無しさん
09/07/13 19:26:25
インデックスで回してない？
foreachにすれば大丈夫だと思うけど。

266:デフォルトの名無しさん
09/07/13 23:23:23
VirtualModeにしてみたら？

267:デフォルトの名無しさん
09/07/14 09:41:49
良く使うジェネリックコレクションは何？
とりあえずList<T>とDictionary<T>覚えておけばいい？

268:デフォルトの名無しさん
09/07/14 09:42:31
Dictionary<K,V>だった。

269:デフォルトの名無しさん
09/07/14 09:52:07
K,VじゃなくてTKey,TValueな
型パラメータの命名ガイドラインは接頭辞Tプラスその型引数の意味
（ただし用途が明らかな場合List<T>とかはT一字でOK）

2.0ならあとはLinkedList<T>, KeyedCollection<TKey, TItem>辺り？
あ、Queue<T>とStack<T>があった
3.0（WPF）ならObservableCollection<T>
3.5はHashSet<T>とか？　コレクションじゃないけどやはり最重要はIEnumerable<T>だな

270:デフォルトの名無しさん
09/07/14 10:24:18
>>269
ふむふむ。
IEnumerable<T>はLINQで出て来るなあ。
ObservableCollection<T>はWPF本で出てきたけど
まだいいや。

List<T>
LinkedList<T>
KeyedCollection<TKey, TItem>
Dictionary<TKey, TValue>
IEnumerable<T>

とりあえずこのあたりからマスターする。

271:デフォルトの名無しさん
09/07/14 10:29:51
あ、KeyedCollectionは後で良いよ
つか全体にマスターするほどでもないような
IEnumerable<T>以外は

272:デフォルトの名無しさん
09/07/14 13:37:18
T[] も忘れないで上げてください、影薄いですけど

273:デフォルトの名無しさん
09/07/14 21:15:32
>>269
.NETの型引数の命名規則は合理的で優れてるよな
java式のK,Vとかイミフ

274:デフォルトの名無しさん
09/07/14 21:33:54
Tとかそういう意味だったのかw
ほかの引数にSとかUとかつけてたわｗ

275:デフォルトの名無しさん
09/07/14 21:43:12
c++テンプレートのTypenameだよね

276:デフォルトの名無しさん
09/07/14 21:44:53
>>274
SとかUってどういう意味よ？ｗ

277:デフォルトの名無しさん
09/07/14 21:45:31
SとかUつける人いるんだｗ

278:デフォルトの名無しさん
09/07/14 21:46:57
ｱﾙﾃｨﾒｯﾄﾌｧｲﾅﾙｸｿﾜﾛﾁｗ

ま、俺はVをつけてたけど。

279:デフォルトの名無しさん
09/07/14 21:56:52
>276,277
いや、Tの前とか次の文字とかｗ
HogeHoge<S,T,U>ってかんじ。

280:デフォルトの名無しさん
09/07/14 22:08:04
型引数を真面目に変数っぽく名前考えてるのって
C#くらいだよね
javaもc++もそんな習慣無い

281:デフォルトの名無しさん
09/07/14 22:23:47
C++には型引数に普通の名前付ける文化もある(STLなど)
わかりやすいけど普通の型名と見分けがつかないので、
.NETの(プリフィクス)+(意味)はその落としどころ

282:デフォルトの名無しさん
09/07/14 22:30:04
>>281
今VC9見たら真面目に命名してるな
VC6とか_Aとか_Cとかだったんだが

283:デフォルトの名無しさん
09/07/14 23:45:07
>>280
.NET も初めからそうだったわけではなく、型引数のこの命名は
ベータかどっかでやっぱりこうしようみたいに一気に変えたんだよ
確か。Connect とかの Suggestion も絡んでた気がする

出来上がりとか見てみんな思うところがあったんじゃないかな

284:デフォルトの名無しさん
09/07/14 23:52:12
>>283
.NET 2.0ベータ中は一文字だった、ように記憶してる
リリースされた正式版のドキュメント見て初めは違和感あった

285:デフォルトの名無しさん
09/07/14 23:57:32
制約がわかりやすいのはいいよね
TEventArgs : EventArgs なんか神

286:デフォルトの名無しさん
09/07/15 00:09:02
>>284
ああごめん。
>出来上がりとか見て
はベータのです。
なんか変わると発表したときにフィードバックの存在を
書いていた記憶があるから。

287:デフォルトの名無しさん
09/07/15 00:17:22
おまいらC#でオープンソースとか使ってる?
Log4netはつかってるがほかゴリゴリ書いてるので時間かかるお(´・ω・｀)
URLﾘﾝｸ(csharp-source.net)

288:デフォルトの名無しさん
09/07/15 03:22:30
SerialPortクラスについて質問

DataReceivedイベント使えばVC++の時みたいに自分でスレッド組まなくて済みそうで楽出来そうなんだけど
実際に受けてみると欠ける時がある
STXhoge123ETX
↑見たいなデータが改行無しで垂れ流しで延々と来るんだけど
たまに
STXhoge123ETX
STXhoge124ETX
STXhoge125ETX
STXhoge126ETX
STXhoge127ETX
STXhoge128ETX
STXhoge129　　　←ETXが受けれて無かったり
STXhoge134ETX←間の130-133までが無かったり・・・

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
　string recvData = serialPort1.ReadExisting();
　Console.WriteLine(recvData);
}
こんな感じで直接出力しても途切れる・・・
何故なんでしょうか？誰か詳しい人教えて

289:デフォルトの名無しさん
09/07/15 03:22:38
すいません。質問ですが、
new RelayCommand(param => this.OnRequestClose());
この=>はどういう意味があるのでしょうか？

290:デフォルトの名無しさん
09/07/15 03:34:36
ラムダ式
URLﾘﾝｸ(ufcpp.net)

291:デフォルトの名無しさん
09/07/15 05:26:44
>>288
フロー制御はうまく言ってる？

292:デフォルトの名無しさん
09/07/15 06:30:27
>>290
おお、ラムダ式。
どうもありがとうございました。

293:デフォルトの名無しさん
09/07/15 14:06:19
ジェネリクスのクラスの型パラメータを配列に制限したい
のですが、以下だと上手く行かないようです。

class Widget<T> where T : IEnumerable
{
public void Iterate(T arr)
{
foreach (object item in arr)
{
Console.WriteLine(item);
}
}
}

・型パラメータTは、競合する制約IEnumerableおよびobjectを継承します
・foreachステートメントは、TがGetEnumeratorのパブリック定義を含んで
いないため、型Tの変数に対して使用できません。

というエラーが出ます。どうかご教示願います。

294:デフォルトの名無しさん
09/07/15 14:13:11
間違ってない
それだけならコンパイル通るし動く
他のところに問題がある

295:デフォルトの名無しさん
09/07/15 14:13:14
ジェネリックでdelegateを指定するにはどうすれば
いいでしょうか？
やりたいことは
public delegate_T func<delegate_T>( string str )
こんな感じなんですが。

296:デフォルトの名無しさん
09/07/15 14:25:37
コンパイル時にチェックするのは無理
Expression<TDelegate>みたいに、名前だけそれっぽくして実行時にチェックする

297:デフォルトの名無しさん
09/07/15 14:31:40
typedefがないので無名になるが
Func<string, int> func;
funcがstringを受け取ってintを返す関数になる
戻り値がdelegateって言うなら
Func<string, Action> func;
とかです

298:デフォルトの名無しさん
09/07/15 14:44:14
>>294
レスありがとうございます。
using System.Collections;
を宣言していませんでした。

299:デフォルトの名無しさん
09/07/15 15:04:49
>>296 >>297
上で書いたような書式じゃ無理ということとですね。
Funcとか知らなかったので試してみます
ありがとう

300:デフォルトの名無しさん
09/07/15 16:12:22
C#入門としてオススメな本があれば教えて下さい

301:デフォルトの名無しさん
09/07/15 16:20:19
>>291
レスありがとう

フロー制御に問題がある様には思えません
送信側と合わせてるので

疑似で
STXhoge0ETX～STXhoge5000ETX
までのデータを作ってtxtファイルにして
ハイパーターミナルからテキストファイルの送信で流してみたんですが
5000までデータはあるのにコンソール上には200行から300行くらいまでしか出てこない・・・
フロー制御もいろいろ設定変えて試したんですが変わらずです・・・

302:デフォルトの名無しさん
09/07/15 16:53:02
症状はどう見てもバッファあふれだろう。

＞フロー制御に問題がある様には思えません　
経験的にいえば強く思い込んでるところが間違ってる可能性が高いな。
コントロールパネルで設定したとか言うなよ。
あとＰＣ－ＰＣでの接続だったらリバースケーブルになるけど、
結線に種類があってハード制御用のラインが自分のほうに戻ってきてるのもあるから要注意。

303:デフォルトの名無しさん
09/07/15 17:36:23
threshold設定してるだけ？
アレってあんまり信用ならなかったとおもう

304:デフォルトの名無しさん
09/07/15 17:37:26
概算じゃなくてデータのサイズきっちり計算してバッファと比べたりしようぜ

305:デフォルトの名無しさん
09/07/15 19:30:24
すいません。質問です。

C#や.NETの資格で、MS社以外のものはありますか？

また、MCPですが、
70-505 TS: Microsoft .NET Framework 3.5, Windows Forms Application Development
などの「開発経験が 1 年以上」は、大学の研究室での開発や趣味プログラミングでも大丈夫でしょうか？

306:デフォルトの名無しさん
09/07/15 21:48:39
Console.WriteLine(new　Uri("URLﾘﾝｸ(example.com)"));

この出力が　"URLﾘﾝｸ(example.com)"　になるんですが、これってバグですか？

307:デフォルトの名無しさん
09/07/15 21:52:30
いいえ

308:デフォルトの名無しさん
09/07/15 22:03:26
sample/../foobar.txt

/ を足して味噌

309:デフォルトの名無しさん
09/07/15 22:07:41
>>308
いや、それはわかるけど、俺が聞きたいのはそれじゃない。
".."　が消えているのはなぜかと、どうすれば回避できるのか、だ　(´･ω･`)

310:デフォルトの名無しさん
09/07/15 22:22:46
OriginalStringプロパティ

311:デフォルトの名無しさん
09/07/15 22:27:16
URIの仕様としては>>306の動作は正しいのかい？

312:デフォルトの名無しさん
09/07/15 22:42:31
RFC2396

Similarly, parsers must avoid treating "." and ".." as special when
they are not complete components of a relative path.

これ？

313:デフォルトの名無しさん
09/07/15 22:45:45
sample.. の .. を特別扱いしちゃいけないから
>>306の動作は仕様を満たしてないってことかな

314:デフォルトの名無しさん
09/07/15 22:49:36
>>310
Console.WriteLine(new　Uri(new　Uri("URLﾘﾝｸ(example.com)"),　"sample../foobar.txt").OriginalString);
ごめん。こういうのを書いて、ちょっと　(´･ω･`)　とした。

RFC　か何かで規定されているなら、まあ無視しちゃって良いかなって気にはなるんだけど、
まだ読みきってないス　(´･ω･)

315:デフォルトの名無しさん
09/07/15 23:25:59
全然関係ない。
趣味でも十分な奴もいれば仕事でも無理な奴もいる。

316:デフォルトの名無しさん
09/07/15 23:27:39
ふらっとの誤爆か？

317:デフォルトの名無しさん
09/07/16 19:30:14
Path.DirectorySeparatorCharとPath.AltDirectorySeparatorCharを
くっつけたものを出来ればconstで定数にしたいんですが
どう書けばよいでしょうか？
もしくはC++の関数内で
static string str = "123";
みたいなことは出来ないでしょうか？

別な方法はありますが、これが出来るとすっきりしそうなのです。

318:デフォルトの名無しさん
09/07/16 19:40:42
readonlyじゃ駄目なの？

319:デフォルトの名無しさん
09/07/16 19:57:42
>>318
なるほど。うまくいきました。
readonly static string str = string.Format( "{0}{1}", Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar );
ちなみに
>もしくはC++の関数内で
>static string str = "123";
>みたいなことは出来ないでしょうか？
これって出来ますか？

320:デフォルトの名無しさん
09/07/16 20:01:25
できない

321:デフォルトの名無しさん
09/07/16 20:04:56
そうですか・・。
了解しました。

322:デフォルトの名無しさん
09/07/16 21:15:10
>>319
C++で関数内のstatic string str = "123";は可能では？
まあスレ違いになるからC++スレで聞け。

323:デフォルトの名無しさん
09/07/18 00:36:11
internal修飾子の使いどころがイマイチわからん

324:デフォルトの名無しさん
09/07/18 00:40:57
ライブラリ作成をしてみると分かるんじゃないか

325:デフォルトの名無しさん
09/07/18 00:41:24
プログラムをDLLで分割しまくって
アクセス制限考え出すとわかる

326:デフォルトの名無しさん
09/07/18 02:26:16
TabIndexに-1を指定できるようにしてほしい

327:デフォルトの名無しさん
09/07/18 03:00:27
何故？

328:デフォルトの名無しさん
09/07/18 03:09:19
使用していないことを明確に表すため

329:デフォルトの名無しさん
09/07/18 03:16:08
継承して、使用していないことを明確に表すためのプロパティを用意すればいいじゃん

330:デフォルトの名無しさん
09/07/18 03:31:49
いえ、相談ではなく提案です
TabIndexプロパティの仕様の話で、-1が使えた方がスマートだということ

331:デフォルトの名無しさん
09/07/18 03:35:20
でもそれだとデザイナで設定できなくなるし、
そもそもTabStopがあるからいらないと思う

332:デフォルトの名無しさん
09/07/18 03:38:55
どうでもいいオブジェクトのTabIndexの値がふらふらしてて気持ち悪い
収まりが悪い

333:デフォルトの名無しさん
09/07/18 07:04:28
そう良かったね。

334:デフォルトの名無しさん
09/07/18 08:19:21
使ってないやつは-1とか
発想が前時代的

335:デフォルトの名無しさん
09/07/18 14:04:06
そうだな。
TabIndexはタブの移動順序を決めるためのプロパティだから、タブの有効/無効とは無関係だよな。
TabEnableてきなプロパティを作るべき。

336:デフォルトの名無しさん
09/07/18 14:27:34
ヌルあぶればいいじゃない

337:デフォルトの名無しさん
09/07/19 04:05:27
おまえらセンス無い

338:デフォルトの名無しさん
09/07/19 04:05:56
ごめん

339:デフォルトの名無しさん
09/07/20 10:11:32
2つの256色ビットマップを読み込んで（パレットは2つとも同じ）、
1つの大きな256ビットマップに描画して、保存したいと思っています。

System.Drawing.Bitmapオブジェクトは作成できたのですが、
ピクセルフォーマットがFormat8bppIndexedになっているので、Graphicsオブジェクトが作成できません。

256色ビットマップに描画するには、どのようにすればよいでしょうか？

340:デフォルトの名無しさん
09/07/20 10:42:12
1枚をRead→Writeはできてるの？

341:デフォルトの名無しさん
09/07/20 10:44:29
>>339
Bitmap コンストラクタ (Int32, Int32, PixelFormat) でコピー先ビットマップ作って
GetPixcel/SetPixelで書き写すしかないんじゃね？

342:デフォルトの名無しさん
09/07/20 11:45:19
最近、ビットマップ合成がらみを色々見てて、
2.0以前のSystem.Drawing.Bitmapよりも、
3.0以降のSystem.Windows.Media.Imaging.BitmapSource と
WriteableBitmap の方が使いやすかった。

343:デフォルトの名無しさん
09/07/20 12:19:39
そんなことSetPixelでやったら死ぬよ
LockBitsだな
WPFが使えるならもちろんそっちの方が遥かに便利で強力

344:デフォルトの名無しさん
09/07/20 12:27:12
結局、32bitBitmap上に描画し、LockBitsして32bit->8bit変換を行いました。

回答してくださった方、どうもありがとうございました。

345:デフォルトの名無しさん
09/07/20 12:28:08
>>344は>>339です。

346:デフォルトの名無しさん
09/07/22 02:08:09
会社で社内の業務改善ツールを任されることになりました
上からＪａｖａかＣ＃を選ぶようにいわれましたが
どちらが扱いやすくて今後の将来性がありますか？

347:デフォルトの名無しさん
09/07/22 02:12:17
C#スレで訊いたらC#と答えるに決まっているだろう

348:デフォルトの名無しさん
09/07/22 02:23:27
>>346
Javaスレで聞いたら？
Javaって返ってくるだろうけど。

まぁ、アレですよ。
自分で使いたいと思うほうを使えばいいと思います。
どっちも将来性なんて分からないので。

349:デフォルトの名無しさん
09/07/22 02:29:17
>>346
製作されたソフトウェアのどちらが長期使用に耐えられるかと言ったら
C#だろうな

350:デフォルトの名無しさん
09/07/22 04:16:08
URLﾘﾝｸ(www10.ocn.ne.jp)

RPGClientでログインして、少し動かした後で切断。再度ログインすると、KeyNotFoundExpectionが発生してしまう。

しらべてみると、MapChangReq（）のunits.setUnit()でunitlistに登録したキーの値がfindUnit(）でキーを元に検索しようとする前の段階で入れ替わってるのが原因だとわかった。

でも、治し方がわからない。
詳しい人がいたら教えてほしい。

351:デフォルトの名無しさん
09/07/22 07:48:58
Windows環境限定でいいんだったらC#でいいんじゃね？

352:デフォルトの名無しさん
09/07/22 07:59:31
互換性考えるとC89だよな

353:デフォルトの名無しさん
09/07/22 08:37:00
コンシューマ用ならC#が俄然有利な気がするが
後方互換保ってくれるかわからないんだよなぁ
なんだかんだで１０年来動き続けてるVB6という手も怖い

354:デフォルトの名無しさん
09/07/22 09:17:18
>>352
互換性(笑)

>>353
少なくとも IL は互換性保たれるんじゃないかな。

355:デフォルトの名無しさん
09/07/22 09:48:41
>>350
プロジェクト開けねーじゃねーか・・・XNA入れないとならんのか？ﾒﾝﾄﾞｸｻ

356:デフォルトの名無しさん
09/07/22 10:01:33
>>350
解凍できね

357:デフォルトの名無しさん
09/07/22 10:25:04
>>356
7zipで解凍できたよ。

>>350
ぱっと見なんだけどRPGServerをリブートしていたというオチではないか？
UnitManagerのunitlistをセーブしたりしている箇所はどこだ？

しかし、なんかUnitの管理とかが微妙な感じがする。
精査したわけじゃないが、unitsが座標ごとに持ってる部分とか。

358:デフォルトの名無しさん
09/07/22 12:04:26
>>357
RPGServerをリブートしているという落ちは残念ながありませんｗ
unitlistをセーブしている部分はsetunit、removeall、removeUnitの三つです。

359:デフォルトの名無しさん
09/07/22 13:40:05
>>358
右クリックして、送る→圧縮(zip 形式)フォルダ
で圧縮したものでうｐしなおしてくれ。

360:358
09/07/22 13:54:39
>>359
すまん。今使ってるウィンドウズにはその機能はない。

361:デフォルトの名無しさん
09/07/22 14:44:12
>>360
機能がないんじゃなくてテメーが無効にしたんだろ。

362:デフォルトの名無しさん
09/07/22 15:05:03
使っているWindowsかビルド環境が古いというオチか。

363:デフォルトの名無しさん
09/07/22 16:11:02
Vistaの標準のエクスプローラで解凍できたけどな

364:デフォルトの名無しさん
09/07/22 16:33:30
>>358
んじゃ、recive_packetでMapChangReqコマンドを投げる前にHandleInput受け取って
SetPosコマンド投げた。とか？
は無いか、initedチェックしてるから。

わかんね。ギブ。

ただ、ひとつ気になったのはunitlist.Add(id, u);。
Dictionary#Addは「ただし、指定したキーが Dictionary<(Of <(TKey, TValue>)>) 内に
既に存在する場合、Item プロパティを設定すると既存の値が上書きされます。
一方、Add メソッドは、指定したキーを持つ値が既に存在する場合、例外をスローします。」

365:デフォルトの名無しさん
09/07/22 22:30:01
何が何だかよくわからない。
切断した後IPとか変わってても大丈夫なの？

366:デフォルトの名無しさん
09/07/22 22:54:46
駄目だけど、そこんとこはまた別の問題。
ツッコミどころはまだまだ多いけど、それは一つずつ解決していくしかなかろう。
とりあえず、結構頑張ってると思う。

367:デフォルトの名無しさん
09/07/26 18:08:18
C++/CLI のスレから誘導されてきた。よろしくお願いしたい。

----------

おしえて。

フォームアプリのテキストボックスとかにデータバインディングで、
DataTable の要素を関連づけて入力値を管理したい。

ここで、テーブル中のレコードが１つの場合はいいんだが、複数あって
かつ、バインドするレコードを動的に変更したい場合ってのはどうすれば
いいのだろうか？

よくわからなかったので、

・バインド用に同じ構造のテーブルを用意して
・そこにレコードをひとつだけ作り
・そのレコードに元テーブルの任意のレコードの値をコピーする
・フォーム終了後にもとのテーブルのレコードに値をコピーし直す

方法で使おうとも思ったのだけど、もっと直接的な方法がありそうな気がする。
いかがだろうか。教示いただけると嬉しい。

368:デフォルトの名無しさん
09/07/26 19:14:08
何を言いたいのかがハッキリわからないけど
DataTableに複数レコードつっこんで
あるときは1レコード目、あるときは2レコード目をバインドすればいいんじゃないの

369:デフォルトの名無しさん
09/07/26 19:37:11
返信をありがとう。

>あるときは1レコード目、あるときは2レコード目をバインドすればいいんじゃないの

その２レコード目をバインドする方法がわからなかったんだ。。。

370:デフォルトの名無しさん
09/07/26 19:38:54
何言ってるんだろ？次のレコードに進めるだけだろ。

371:デフォルトの名無しさん
09/07/26 23:37:42
ああ。そう言う方法があるんだね。
ごめん。まだこれの経験が浅くてそれ自体がわかってないんだ。
その方向で調べ直すよ。ありがとう。

372:デフォルトの名無しさん
09/07/27 00:35:25
BindingManagerBase::Position のことか。
気がつかなかったよ。お騒がせしました。

373:デフォルトの名無しさん
09/07/27 14:13:58
非ジェネリックのIDictionaryをジェネリックのIDictionary<TKey,　TValue>に
変換するスマートな方法があったら教えてください。
foreachで別のDictionayに１つずつ追加するのはやれてます。

374:デフォルトの名無しさん
09/07/27 14:30:54
それが一番だと思うけど。
dic.Cast<DictionaryEntry>().ToDictionary(entry => (TKey)entry.Key, entry => (TValue)entry.Value);
がスマートとは思えない。

375:デフォルトの名無しさん
09/07/27 14:34:42
C# 2.0
で質問です

System.Threading.ManualResetEvent
のインスタンスを使用して1ミリ秒のウェイト処理をループ中にかけようとしているのですが
　・Vista環境だと上手く1mSec 程度停止するのに
　・XP環境だと15mSec程度まで跳ね上がる時があります。
　OSの分解能ということで1mSecは諦めるしかないのでしょうか？

　用途は最高速で常時まわしたい処理を以下のソースのWhileの中に組み込んでHOGEの処理をしているのですが
可能であれば10mSec以下で1ループを終わらせたいのです。（中の処理は2～3mSec程度）
　ただしこのままでは別スレッドで実行しているにもかかわらずCPU負荷率が高すぎるために
最低レベルでのスレッド停止処理を行いたいのです。
ちなみにSystem.Threding.Thred.Sleep(1); を行うとVista環境でも1mSecより大きく停止してしまいます。

System.Threading.ManualResetEvent mre = new System.Threading.ManualResetEvent(false);
While(True)
{

　　　　HOGE();//処理

　　　　//ストップウォッチ計測開始
　　　　mre.WaitOne(1);
　　　　//ストップウォッチ計測終了
　　　　
　　　　if(exitFlag == true) break;
}

何とか最速でまわしつつ負荷を上げずにWhile文を回し続ける方法はないでしょうか？

376:デフォルトの名無しさん
09/07/27 17:19:40
1msの分解能が欲しかったらCPU負荷率は諦めるしかないと思うけどな
スレッド切り替えるのに1ms以上かかりそうだし

377:デフォルトの名無しさん
09/07/27 17:55:33
>>376
そうですか・・・
まぁヂュアルCPUなんで負荷率は50％なので構わないと言えば構わないのですが・・・
できるだけ使用率を低くして寿命を延ばしてやりたかったのです

378:デフォルトの名無しさん
09/07/27 17:59:39
>>375
Sleepすることが目的ではなく、CPUを使いすぎることを抑えたいだけのように感じる。
もしそうなら、Priorityプロパティでスレッドの優先度を下げるだけというのはどう？

もちろん、優先度を下げるということはCPU使用率を下げることとは違うから、、
ほかにやることがなければCPUを使い尽くすということに変わりはないけど。

379:デフォルトの名無しさん
09/07/27 18:02:17
>>377
何をやりたいのか知らないけど専用マシンを用意すれば？

380:デフォルトの名無しさん
09/07/27 18:32:57
10mSecでTimer回した方が良いように思えてならない。
再入をブロックする必要はあるけど。

381:デフォルトの名無しさん
09/07/27 20:17:27
>>375
よくわかんないけどこういうこと？

Stopwatch sw = new Stopwatch();
long nextTiming = sw.ElapsedMilliseconds + 10;
sw.Start();

while (true)
{
　　while (sw.ElapsedMilliseconds < nextTiming) { Thread.Sleep(0); }
　　nextTiming += 10;
　　Console.WriteLine("Now is {0} ms", sw.ElapsedMilliseconds);
}

Thread.Sleep(1)にしてやればCPU使用率は無駄に上がらない。
その場合、処理のインターバルの精度は落ちるけど、時間あたりの処理回数の精度は
保てるといってよいんじゃないか。

382:デフォルトの名無しさん
09/07/27 23:32:44
マルチメディア系の機能でミリ秒レベルの精度でsleepする方法ってあったりするんだっけ？
普通のSleepって、TimeBeginPeriodで指定した分解能でスレッドの状態変わるんだっけ？

もしSleepの精度にTimeBeginPeriodが効くなら、それやってスレッドの優先度をあげればいいかも。
ただし処理をきちっと終えてちゃんと確実に速やかにSleepしないと死ぬことになるが。

383:デフォルトの名無しさん
09/07/27 23:35:31
各回のインターバルの精度が必要でないなら、10回分繰り返して10回分Sleepとかそういう手もあるが。

384:デフォルトの名無しさん
09/07/27 23:42:24
>>382
timeBeginPeriodは消費電力を増やすと言われているのだから、
寿命を気にする>>377には似つかわしくないと思う。

385:デフォルトの名無しさん
09/07/27 23:54:07
HDDはともかく、CPUはヒートシンクが動作中に外れるとか
余程のことでもなければ「寿命」を縮めるなんてことはないと思うけど。
真空管じゃないんだから

386:デフォルトの名無しさん
09/07/28 00:07:36
まあCPU自体にはあんま関係ないけど、
使用率が高いところを維持するのは全体で見ればあまり望ましいことじゃなかろう。

あと確かに大麻精度あげると電力使用はアップしてしまうのかも知れんが、
CPU使用率が高いままになるよりはましじゃないかと思うがどうだろう。
もちろんそうせずに済むならそれにこしたことはない。

387:デフォルトの名無しさん
09/07/28 00:19:55
結局のところ、何であんな事をやりたいのかハッキリしないと何とも言えん

388:デフォルトの名無しさん
09/07/28 10:43:04
C#では、グラフィック関連のメソッドで、小数の引数はfloat型になってますよね。
floatよりdoubleの方が一般に速いと思うのですが、なぜfloatなんですか？

389:デフォルトの名無しさん
09/07/28 10:49:39
GPUはほぼ単精度までしか扱えなかったぜ
まあGDI+はGPU使わんけどな！

390:デフォルトの名無しさん
09/07/28 10:57:27
計算速度じゃなくて帯域幅の問題。
あとdoubleが速いってのは今のCPUでの話にすぎない。

391:デフォルトの名無しさん
09/07/28 10:58:17
あGPU関係なかったか…

392:デフォルトの名無しさん
09/07/28 11:00:36
>>389
なるほど…。
今まで、座標を保存するための変数x, yをdouble型で宣言して、
描画時にintに変換して使っていたのですが、
これはfloatにしてキャストなしで使った方がいいんでしょうか？
「float同士の演算(座標計算時)」と「double同士の演算(座標計算時)＋intへのキャスト(描画時)」
では、どっちが速いんでしょうか。

393:デフォルトの名無しさん
09/07/28 11:05:11
>>390
> 今のCPUでの話にすぎない。
昔のCPUのことを想定してどうすんだよｗ

394:デフォルトの名無しさん
09/07/28 11:19:55
>>392
自分でベンチ書いて試しなよ
その方が納得できるだろ

395:デフォルトの名無しさん
09/07/28 11:53:38
昔のCPUの話じゃなくて今のGPUの話だよ。
関係なかったけど。

396:デフォルトの名無しさん
09/07/28 12:20:35
レスが遅くなりました。

>>378
おっしゃる通り現在の処理速度を犠牲にせずにCPUの負荷を下げてあげたいということです。
スレッドの優先度は、この処理部分以外にあまり同時に激しい処理をしているわけではないので微妙な感じです

>>379
まぁ専用マシンを用意してもCPU負荷がずっと大きな値に張り付くのは・・・微妙なきがします。
FA系なので安定して長く動作させたいのです。

>>380
やってみた感じスレッドのタイマで１ｍSecで動かしてもどうも間隔はOSに引っ張られるようですorz
例えばですが・・・再入ブロックはこんな感じの処理のことでしたっけ？

タイマコントロール
void tick
{
　タイマ停止
　処理
　タイマ開始
}

スレッドタイマ　（間隔で動かすというか1回だけ動かすのを繰り返す）
void Tick()
{
処理
次回Tickを動かす時に１ｍSec間隔をあけて実行
}

397:デフォルトの名無しさん
09/07/28 12:37:37
>>381->>383, >>387

本当はWhileの中は最速でまわしてあげたいのです。
しかし、CPU負荷率が高くなりすぎるのでそれを防ぐためだけに仕方なく1mSecのスレッド停止を挟んでいるのですが
そのスレッド停止がXPではきっちり１ｍSec止まってくれない
（別に２ｍSecとかでもいいのですが１５ｍSecとか止まってしまうのです。）

結局やりたいことを説明すると

FAの工場内のでラインの制御をおこなうのに１スキャンあたり（１ループ）25mSec以内で処理しなければ処理ヌケが発生する。
→処理ヌケが発生しないようにする処理は現在のループ処理の中では余裕
→だけどCPUがずっと高い使用率に張り付いたまま
→基本的に長期安定動作させたいので使用率は大きいよりは小さいほうがいい
→SleepやManualResetEvent.WaitOneではXP上で停止時間が不安定（これで運用すると少しでもOSの動きに引っ張られると処理時間が延びて処理ヌケしてしまう）
→VISTAはなぜか停止時間が結構安定する
→上に　VISTAにしてくれというと「FAでVISTAとかまじありえね　XPでやれ」　と言われ取り合ってももらえず
→打つ手が思い付かずに　ここへ知恵を借りに
　　　　↑いまここ

そして同じPC内にはコスト削減とかでラインの画像判定を撮って判定するソフトが・・・
（これ自身はCPU負荷はそこまで使いません。　一瞬５～１０％まで上がる程度が５０ｍSec程度の間隔）

こんな状況ですorz
そもそも、Pgを別のPCに分けてもメインのループ部分がCPU使いっぱなしになるので問題の解決はしないという・・・

>>385-386
CPU自体は迷信なのかもれません。
まぁ、ただずっと高しようりつで張り付くと結局温度が上がってしまうので
色々と起きてきそうなのです。

398:デフォルトの名無しさん
09/07/28 12:49:09
CPUのタイムスライスってレジストリでいじれなかったっけ？
そこまでシビアなFAの制御なら専用のCPUボードにやらせて、
OSはサマリーだけ受け取るような仕掛けにしないといかんだろう。

399:デフォルトの名無しさん
09/07/28 12:53:35
>>398
本当はそうなんですよね
せめてPLC使って処理させるとか

でも・・・今回は期限ないうえにコストも落とせという色々無茶な状態が重なってしまいまして…

400: [―{}@{}@{}-] デフォルトの名無しさん
09/07/28 13:11:31
>>399
RTOSが必要なんじゃね？

この辺にも色々書いてあるけど
URLﾘﾝｸ(www.microsoft.com)

401:デフォルトの名無しさん
09/07/28 13:13:02
他のプロセス（サービス含む）が動いたらあっという間に25ミリ秒とか過ぎ去るな

402:デフォルトの名無しさん
09/07/28 13:17:34
>>400
エンベデッド（これで読みはいいのか？）ですよね
そう、せめてそれがあれば最低限のコンポーネント入れていけるとおもうんです
しかし普通のPCに普通のXP PRO
サービスとかはできる限りとめて動かしていますがなんというか・・・がっくりです

>>401
そうなんです！

というか、やる気起きないのでダラダラと

403:デフォルトの名無しさん
09/07/28 13:22:06
連投ばっかですみません

なんとなくですが
>>382
のTimeBeginPeriodでいけそうな気がします。
また詳しいことは微妙ですが
これ使って簡単に1日程度動かして様子を一回見てみようかと

404:デフォルトの名無しさん
09/07/28 17:53:02
>>392
描画メソッドの呼び出し頻度なんか知れてる
呼び出してからの実際の描画処理の方が遥かに時間がかかるからそんな細かい差は全く意味がない

405:デフォルトの名無しさん
09/07/28 19:47:21
>>403
なんか>>397を読んでもやっぱりよく分からないんだけど、
要するにDIOか何かをポーリングしてるのかな？

それでそのDIOのイベントに応答するときのレイテンシの最大許容時間が25ms、
みたいなこと？

406:デフォルトの名無しさん
09/07/28 20:18:16
浮動小数から整数への丸め制御方法によっては、intにキャストする回数が多いと遅くなるかもね

407:デフォルトの名無しさん
09/07/28 20:24:57
そんな差が目に見えるほど描画メソッド呼び出したらそれこそ死亡

408:デフォルトの名無しさん
09/07/28 21:33:20
>>397 >>403
タイマーが15ms間隔でしか発動しないのはWindowsの仕様。
パラメータでは1ms単位の数値が設定できるけど、実際の動作は約15.5ms間隔に切り上げられる。

TimeBeginPeriodを使えば間隔を詰めることはできるけど、実際に試してみると、
最短の間隔がせいぜい2ms程度で、それより長くなることもある。
それにTimeBeginPeriodには副作用があって、他のアプリがたまたまTimeBeginPeriodを再設定してしまうと、
そのマシンで動いているすべてのアプリが影響を受けてしまう。
>>375でVistaは1msてのは、たまたま何かのアプリがTimeBeginPeriodをいじってただけの可能性が高い。

そもそもSleep関数の動作は「少なくとも」指定した時間経過、だから、どれだけオーバーするかは運次第。
ただしこれはVistaまでの話で、Windows7ではタイマー関係がようやく強化される予定なので、
どうしても2ms以下の間隔を死守したいならWindows7を使えばすんなり解決するかもしれない。

409:デフォルトの名無しさん
09/07/28 21:47:44
タイマっていうかタイムスライスの問題だからちょっと話がズレてると思うけど。。

410:デフォルトの名無しさん
09/07/28 21:53:02
>>408
XPしかだめっつうてんだろｗ

XPにPLCと同じことさせようとしても無理。
制御じゃなく監視だよね？
FA屋で制御までさせようとしてるなら職変えたほうが良いよ。

411:デフォルトの名無しさん
09/07/28 22:08:01
Chrome起動中だと高速化するよ（笑い）

412:デフォルトの名無しさん
09/07/28 22:16:54
25msなら、スレッドの優先度上げてやればSleepでも大丈夫かもしれん（実質15msくらいで）。
まあTimeBeginPeriod使った方がいいと思うけど。

優先度を上げない場合、Sleepでの停止自体は短時間でも、実行順が回ってくるまでに
タイムオーバーする危険がある（他のスレッドがある場合）。
優先度を上げると実行可能になった時優先的に処理が回ってくるので、遅れる危険が小さくなる。
ただし、処理を終えたら確実にSleepしないと、下手すればマシンハングアップ状態になるので注意。

ただ、いずれにしてもWindowsではそういうのを本当に確実に処理することはできない。

413:デフォルトの名無しさん
09/07/28 22:21:58
XPのタイムスライスってどんくらいだっけ？15msくらいだっけ？20msくらいだっけかな？
もしフォアグラウンドで何かを動かしたらそいつは3倍になるから処理にもよるけど簡単に死ねる。

414:デフォルトの名無しさん
09/07/28 22:23:41
スレッドの優先順位？
スレッド？

415:デフォルトの名無しさん
09/07/28 22:29:46
>>413
1/64 s

416:デフォルトの名無しさん
09/07/28 22:37:57
あー大きく上げるにはプロセス側で上げとかないと駄目だったか、
言いたかったのは単に最終的なスレッドの優先度を上げるということ。

417:デフォルトの名無しさん
09/07/28 23:23:52
>397の人件費考えたらVISTAなんて安いものだろうに・・・

418:デフォルトの名無しさん
09/07/29 00:05:42
ていうか・・・なんでWindowsでそんなリアルタイムOS的な制御をやろうと企画した
んだろ、発注元。

419:デフォルトの名無しさん
09/07/29 00:17:34
>>397の言葉遣いも怪しいところがあるから、
必ずしも本来の要求仕様を満たすために必要のない手法を>>397自身が
考えているだけかもしれない。

なんかその可能性が高いように思う。

420:デフォルトの名無しさん
09/07/29 00:36:59
リアルタイムにセンシングするとして、データをキューに入れといて別スレッド
で処理したら駄目なのかな・・・いや、そういう話じゃないな。

382の言うとおりマルチメディアタイマ使えばいいんじゃね？

421:デフォルトの名無しさん
09/07/29 00:47:18
>>410
いや、Vistaはカンベンしてくれって話だろ？

422:デフォルトの名無しさん
09/07/29 00:48:14
マルチメディアタイマーも15ms縛りがあったような…

423:デフォルトの名無しさん
09/07/29 00:49:07
要求が「VistaとXP」なんだからそんなところの議論は無駄無駄

424:デフォルトの名無しさん
09/07/29 01:16:39
てか1ms周期で動かしたら大抵CPU時間使いまくるってオチ

425:397
09/07/29 02:13:03
多くのレスありがとうございます。

そもそもなぜXPなのか？
というのはその上役の人間が安定志向でXPで今まで出来てたんだから　という考えのもとに言っているような感じです。
しかし、その実績はせいぜい50～1000mSec程度なのでどのOSでも簡単に実装できるものでした。

新しい機械を開発するにあたり
そこそこ高速で移動するライン状の物の位置をエンコーダで追い、DIOの信号を利用して移動させる　という処理が必要になり
上役の人間が打ち合わせをした際にその程度の処理なら出来る　という憶測で仕事を受け入れてしまいました。

その尻拭い的な感じをいまやっているわけなのです。
多くの皆様意見をいただき本当にありがとうございます。
さすがに限界を感じる感じなので、CPUをフルに使う状態での運用か、それとも設計や方針自体を変更するべきなのかを上の人間にかけあってみます。

ちなみに単純な処理です

→　物の流れる方向
｜----------------目的地　　　　　
センサ　　　　　　　　　　　　↓

センサをＯＮしたタイミングでエンコーダ値を取得・保持し、目的地の位置までパルスが移動したらＤＩＯ信号をＯＮし、流れているものを矢印の方向へ稼働させる機械を動かす。
たったこれだけです。
ＰＬＣでやればどれだけ単純で簡単なレベル　という話 orz

多くの意見、今後のＰＧに生かしていこうと思います。
はぁ・・・月曜日が鬱だｗ

426:デフォルトの名無しさん
09/07/29 03:16:37
しかもC#でとな('A`

427:デフォルトの名無しさん
09/07/29 06:05:48
>>425
それ本当に1msの精度求められてるの？
仕分けでそこまでの速度を要求されるとは思えんのだが。

428:デフォルトの名無しさん
09/07/29 06:47:49
>>393
intよりdoubleが早い環境なんて少数派だぞ

429:デフォルトの名無しさん
09/07/29 06:58:29
PCでそんな制御やるのがそもそも間違えてる
カーネルから優先度の高い命令が割り込んだら何ぼでも処理落ちするぞ

430:デフォルトの名無しさん
09/07/29 08:05:16
動かないと思ったらWindowsUpdateでリブートしてるんですね。わかります。

431:デフォルトの名無しさん
09/07/29 12:06:08
>>427
初めに書いたとおり1mSecまでは求められてはいませんが
自分がWindowsで制御するなかでは初めての精度になります。

まぁごくまれに処理抜けする程度ならリターンしてもう一度処理をすればいいのでそれはそれで何とかなるわけですが
その為、処理負荷をできるだけ下げつつ処理時間間隔を短くするために可能な範囲で試行錯誤してみています。

>>426
>>429
そうなんですよね
何というか・・・GUIがほしいのはわかるんですが・・・

ちなみに現在実機でタイマ精度変更後に一日動作させた感じ1処理は停止含めて15mSecを超えていない（StopWatch調べ）感じです。
CPU負荷も常時高い位置にあったものが時々大きく上がる程度まで抑えることができている感じです。

でもぶっちゃけ実運用になったら・・・ちょっと怖いかも

432:デフォルトの名無しさん
09/07/29 12:17:58
実際のとこ、全力でぶん回してもリスクは変わらないから。

433:デフォルトの名無しさん
09/07/29 12:31:00
全くもってそのとおり
”ずーっと確実に最長1msの周期で観測する”という要件しか聞いていないから，PCの電源が落とされた時点でアウト，
PCの電源落とさないってんなら，たった一日の観測(>>431)くらいで何か分かるわけでもないし．
おとなしくデバイス作ってUSBかシリアルで接続したほうが安心．

GUIはC#でいいだろうが

434: [―{}@{}@{}-] デフォルトの名無しさん
09/07/29 12:39:49
>>433
なんかPC障害でラインが暴走しそうな悪寒もする。
ちょっとした機能追加で制御不能になったりとか

担当者さんのデスマーチが目に浮かぶ

435:デフォルトの名無しさん
09/07/29 12:44:55
今思った

GC時間考慮してねー

436:デフォルトの名無しさん
09/07/29 13:02:29
まあ書かれてた処理内容なら大丈夫だろ。
もち注意して作る必要はあるけど。

437:デフォルトの名無しさん
09/07/29 19:25:38
>>425
その説明だと、そもそも「目的地」のところにセンサをつけ、
その出力を「流れているものを矢印の方向へ稼働させる機械」に直結すれば
PCなんか要らないように思えるけど。

それにどうしてエンコーダが必要になるのか意味がわからない。
わざわざ目的地じゃなくてその手前なんかにセンサを付けるから、
目的地を検出するためだけにエンコーダが必要になるんじゃ？

438:デフォルトの名無しさん
09/07/29 20:39:38
>>425
目的地にセンサつけたらだめだろｗ
目的地はｎ通りあるから事前に振り分ける処理が要る。
FAの機械ってのは大抵が独自のプロトコルで通信する。
だからPCなりPLCなどの中継が必要になる。
ここまでは皆理解していて、その先の精度や耐久性について語ってるのだよ。

次ページ