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

2019/03/20(水) 18:57:36.47

!extend:checked:vvvvv:1000:512
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part93
http://mevius.5ch.net/test/read.cgi/tech/1492818720/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2021/04/17(土) 16:58:25.17

>>518
そもそもプロジェクトの規模に比例してVSが重くなったりしないと思うよ。
少なくとも「ちまちまやってる」程度なら絶対にありえないと断言できる。
重くなってる理由は他にあるんじゃないのかな

必要性もないのにアセンブリを分ける（dllにする）ことには反対。

2021/04/17(土) 17:43:26.21

皆さんレスありがとうございます

ソリューション内にプロジェクト分けてそれぞれ書き出したDLLをメインのプロジェクトで
読み込ませて使う・・・メインのビルド（動作テストなど）は軽くなるという理解であってますか？
修正があれば、そのプロジェクトだけビルドし直す、
最終的な製品にするインストーラー生成時はかわらないと

>>521
かれこれ2年近く機能拡張続けていて、Form画面だけで300くらいで
それとほぼ同数のサードパーティ製の表形式コントロールやら帳票やらもある感じです
vsフォルダ作り直したり、VisualStudioの軽量化はいろいろ試して
多少は軽くなってますが、ファイル数が多ければビルドに時間がかかるし
InteliSenseやエラーの出力など、プロジェクト内のファイル数が多ければ多いほど
そのための処理が入るのかなと思ったのですが違うんでしょうか

何分素人レベルなので、デバック→エラー→修正→デバック→の繰り返しでなんとかやってるので
ビルドの速さが結構切実だったりします

2021/04/17(土) 18:00:16.57

そりゃ必要ないソースもビルドされるから遅くなるわな
まずは処理単位でプロジェクトを分割することオススメするよ

2021/04/18(日) 00:26:44.62

こうやって情報を後出しすると話がなかなか進まないのです

2021/04/18(日) 12:09:57.65

普通にソース書いてデバックするだけのプロジェクトなら差分ビルドでそんなに時間がかかるイメージないけどな
別の要因が色々出てきそうだけど、まあ分割して解決したらいいね

2021/04/18(日) 13:43:19.23

makefileとかだと依存関係が正しくなくて差分ビルドのつもりでも全ソース
フルビルドになっていたとかあるけど
あと、サードパーティーのコントロールとかって話なので、パッケージが
なんでも無条件にフルビルドするので、自分の修正とは関係ないところで
ガンガンビルドがはしっているとか

2021/04/19(月) 08:49:19.92

デバックってなんだよデバグだろw

2021/04/20(火) 08:44:29.47

DEBUG
DEBUGGER

2021/04/20(火) 16:04:11.65

BUGGER = 肛門性交する奴

2021/04/21(水) 20:50:02.04

enbug 修正などよって新たなバグを作り込む

2021/04/23(金) 13:10:42.79

VisualStudio2019のクエリビルダー使ってFillを生成してるんですが、
クエリビルダーの「クエリの実行」ではパラメータに「%」使って目的のデータを取得出来るのに
生成したFillの「データのプレビュー」でパラメータに「%」使うと何もヒットしないという現象が起きてて途方に暮れてます
ちなみにアンダースコアは任意の1文字で検索してくれるので初心者女子高生の私には
もう原因さっぱり判りませんの(´・ω・｀)

2021/04/23(金) 13:16:05.78

Fillを生成？

2021/04/23(金) 13:36:44.61

>>532
作成かな。メンゴメンゴ

2021/04/23(金) 14:56:28.43

RDBMSのクエリログで内容確認すれば

2021/05/03(月) 23:04:24.90

自力で簡易なセキュリティソフトを作りたいと思っています。
動きは単純で、登録されていない実行ファイルが勝手に外部に通信しようとしたらブロックするだけのものです。
AVASTがやってる動きです。
何らかのAPIをフックするのだろうという事は想像できますが、取っ掛かりが分かりません。
どのAPIを見れば良いのかご存じの方いらっしゃいますでしょうか？

2021/05/04(火) 10:07:10.31

npcap使うのが定番かな今は

2021/05/04(火) 10:36:28.73

Windowsの話だったらWindows Filtering Platformとか

2021/05/13(木) 18:58:32.33

wpf でtabcontroleで複数タブにrediobutton配置支店ですけど
これを全部一つのグループにすることってできないんですかね？
groupname指定しても駄目だったので仕様的に方法なしなんでしょうか……(´・ω・｀)

2021/05/13(木) 20:02:28.36

GroupNameでは無理
IsCheckedへのバインディングとかでうまいことやって

2021/05/13(木) 23:35:30.68

>>535
明らかにC#の範囲外の質問でOSハックレベルの話だが、例えばWindowsならカーネルドライバを利用した通信フックライブラリはいくつかあったはず
んでTCPやUDPのソースポートから発信元プロセスは特定できるからそれくらいならすぐ作れるだろうけど
想像以上に多くのシステムプロセスが通信してるから登録するのめんどそうだけどな

2021/05/14(金) 19:19:35.19

>>539
バインディングなんてわかるわけ無いだろ！(｀；ω；´)
もう仕方ないからボタンと背景色でタブっぽい見た目作ってラジオボタンをVisibleったりhiddenったりしてそれっぽいの作った……

2021/05/16(日) 04:48:26.69

functorに関する質問です
C++で次のように書いとけば

template<typename Functor>
double Example( Functor func,・・・){

呼出し時に、引数funcに関数へのポインタでも、ラムダ式でも、関数名でも記述できますが、
C#で同じように、引数に、デリゲートでもラムダ式でも関数名でも記述可能にするにはどーすればいいのでしょうか?

2021/05/16(日) 08:50:12.74

> 引数に、デリゲートでもラムダ式でも関数名でも記述可能にするには
デリゲート型を指定すればいい
double Example<T>(Func<T, double> func, T obj) { ... }

double ToDouble(Hoge hoge) { return hoge.Value; }
this.Example(obj => obj.Value, hoge);
this.Example(ToDouble, hoge);
this.Example(new Func<Hoge, double>(ToDouble), hoge);

ただしシグネチャが同じでもデリゲート型が違うと無理なのでラムダ式なりとおす必要がある
delegate TRet Converter<TArg, TRet>(TArg arg);
var conv = new Converter<Hoge, double>(obj => obj.Value);
this.Example(conv, hoge); // エラー
this.Example(obj => conv(obj), hoge); // OK

2021/05/18(火) 04:46:17.76

System.Collections.Generic.List<System.String> hips =
new System.Collections.Generic.List<System.String>(0);
hips.Add(@"尻");
hips.Add(@"ケツ");
hips.Add(@"Buttocks");
hips.Add(@"んまら");
hips.Add(@"臀");
hips.Add(@"ω");
hips.Add(@"Hip");
foreach (System.String hip in hips) {
System.Console.WriteLine(hip);
}

2021/05/22(土) 21:17:48.56

俺のツレの先輩がc#プログラマに酷い目に遭わされたことがある

c#プログラマから金借りて返さんかったら、拉致られて拷問うけた
指の爪全部ペンチで剥がされてその後ペンチで指先を挟んで潰されたらしい
4本目くらいで痛みに耐え切れなくて舌噛み切って死のうとしたけど死ねなかったって
命までは取られなかったけど指先全部駄目になって切断したみたい

2021/05/23(日) 08:27:53.86

改変コピペ？

2021/05/23(日) 13:27:11.50

そうじゃなかったら知的障害かな

2021/06/05(土) 14:12:36.14

メモリ不足での相談です

小さいjpg画像ファイル(1ファイル50KB程度）を10,000ファイル程度
サードパーティ製のGridViewに投げ込んで表示させようとしてます
その前にList<Image>に下のような感じでStreamで投げ込んでいくのですが

var fs = System.IO.File.OpenRead(@filepath);
ListData = new Bitmap(Image.FromStream(fs, false, false));
fs.Dispose();

4000ファイルあたりでメモリ不足に陥ります
VSの診断ツールで見ていると、読み出しはじめて4GBで止まります
メモリが4Gでアウトになっているのは理解できるのですが
ローカル上のファイルの総データ量は800MB程度で、実際に読み込みがとまるあたりでは
せいぜい200MB程度読み込んだ程度と思います
2000ファイル程度にグループごとに都度分けて読み込ますしかないかなと思っていますが
確認すべき点（余計に容量食っている要因）やなにか他に方法があったらご教授ください

2021/06/05(土) 14:18:34.48

>>548
JpegをBitmapに展開してるのだから容量が増えるのは当然では

2021/06/05(土) 15:00:04.47

>>549
レスありがとうございます
同サイズ程度のbmpファイルもあるのでそっちでやってみましたが
4000ファイルが6000ファイルくらいに限界数が若干のびだだけでした

2021/06/05(土) 15:05:40.03

https://docs.microsoft.com/ja-jp/visualstudio/profiling/memory-usage?view=vs-2019

2021/06/05(土) 17:36:11.90

32bit優先が付いてるとか？
ただどっちみちアプリ全体どころか、1つのリストで4Gもメモリに保持とかは筋がめっちゃ悪いぞ。
4000ものフル画像が同時に必要とかあり得ないし。
表示上必要ならメモリ上にもつならすごく小さなサムネイルをダイナミックに並列処理で作りながら持つとか。
今表示に必要なものだけ、ダイナミックにメモリで並列処理でサムネ作るとかでしょ。

2021/06/05(土) 18:00:28.83

今時VirtualMode的なものが無いグリッドコントロールなんてあるのか？

2021/06/05(土) 19:41:37.20

>>552
やっぱり、そうですよね
実際には10000ファイル越える予定だったのでなおさらですよね
スクロール時のスピード感は多少落ちますが
素直にグリッドコントロールが描画する際に都度読み込むようにすることにします

2021/06/06(日) 18:25:06.49

>>554
良い悪いは置いておいて、とりあえずファイル郡をまとめて読み込んでおくのが
目的で、Bitmapで変換するとメモリを消費してしまうのならば、ファイルの内容を
Streamの配列に読み込んでおいて、表示するときにBitmapで変換するとか
そして表示するだけならばBitmap使わなくてもImageでStreamから読んで
DrawImageでよいんじゃないかなとか

2021/06/06(日) 18:34:20.40

無駄

2021/06/08(火) 10:18:44.68

要するにサムネ表示したいんだろ
SSDなら1万ファイルの読み込みにもそんな時間掛からんし
ファイルをインデクス化して画面に出る部分だけ都度読み込んで描画すればいい
グリッドビューなんて必要かね

2021/06/10(木) 16:49:33.11

仮想化すればいいだけの話じゃん
何兆個のファイルがあろうとどうせ表示される項目は多くても数十なんだからスクロール位置などから表示すべきファイルだけサムネ表示すればいい

2021/06/11(金) 13:38:09.74

日本語の変数名使えるのに記号の変数名はダメなのかよ
競馬関係のアプリ開発受注したから予想記号の変数名として分かりやすく記号使いたいのに

2021/06/11(金) 17:10:30.00

記号で分かりやすくとか頭おかしいんじゃないの？

2021/06/11(金) 19:23:13.76

enumの値とかならまあわからなくもないかな

enum 予想記号 {◎, ○, ▲, △, ☆, ☓};
var 予想 = ◎;

https://umasiru.com/wp-content/uploads/2019/03/IMG_4633-2.jpg

2021/06/11(金) 19:36:06.84

var ◎ = △;

2021/06/11(金) 19:51:40.71

何か競馬のあれを連想する

2021/06/29(火) 12:33:01.69

フォームを開いてその画面での処理中に
Form fs = new FormA;
try{
fs.ShowDialog(); ←ここ
}
catch{}

ここのところでハンドルされてないエラーがでて止まります
FormAでの例外処理などには一切ひっかからず
この場合解決の道筋はどこからでしょうか

ちなみにFormAではwebview2でオフィス365のウェブ版エクセルの新規作成を開こうとするとエラーになります
ワードではでないのですが
ここででるエラーは、System.Runtime.interior services.COMEException
0x8007139Fです

2021/06/29(火) 19:49:17.93

>>564
そのエラーコードでggr

2021/06/29(火) 20:27:18.03

>>564
まず意味が分からんけどFormなの？Dialogなの？

2021/06/29(火) 20:55:15.95

>>566
すみません、書き間違いです
Form fs = new FormA();

>>565
ググったのですが、webview2がnullなってるのだろうと考えられるくらいで、同じケースはなかったです
そもそもなんでワードは開くのにエクセルはwebview2がnullになってしまうのかわからず、どこの時点でそうなるのか調べたいのですが、FormA側ではcatchできず、上の位置で停止するんですよね

2021/06/29(火) 21:01:59.16

それ以前の根本的な問題があるのだろう
君には無理とは言わないがしばらく距離を置こう

2021/06/29(火) 21:47:21.44

変な所でフォーム表示しようとしてんじゃね
そのコードだけじゃなくてメソッドごと見せてみ

2021/06/30(水) 00:22:51.11

>>569
FormAにはwebview2を配置していて、ブラウジングさせています
通常のサイト閲覧は何も問題ないのですが、ブラウザ上でエクセルが開けるoffice365を使用中、新規作成で開くときだけ呼び出し元のフォーム（上でこことしたところ）で停止します
既存のエクセルファイルなんかはFormA上のwebview2できちんと開けているのですが
なので、自分で書いた特定のメソッド中のエラーではなく、ページ遷移中に停止し、呼び出し元のShowdialogのところに戻ってハンドルエラーになってしまいます

2021/06/30(水) 00:39:45.90

再現する最小コードを作る
それでも不明ならその最小コードを公開して質問

2021/07/03(土) 03:25:24.72

ゲイツが収入マイナス7兆円ぐらいで苦しんでる。
c# プログラマから金を集めて、ゲイツに寄付するべきだと思う。

損失の一部 5兆円ほどc#プログラマから強制的に集めたい。国内に5万人ぐらいc#プログラマはいるから、1人1億ぐらい払えばいい。

土地とか家を売ればこんぐらい払えると思う。
払えないひとは肝臓とか売ればいい。

2021/07/03(土) 05:01:54.92

>>572
では早速言い出しっぺのあなた様から肝臓を差し出して下さい

2021/07/03(土) 06:04:33.61

では血をとらずに肝臓だけ取り出してください

2021/07/03(土) 09:59:13.80

何そのハムレット

2021/07/03(土) 10:22:53.43

アンキモ以下の脂肪肝なら処分料が欲しいな

2021/07/03(土) 11:22:03.96

ヴェニスの商人では？

2021/07/05(月) 15:24:59.38

DBから取得した重複なしの文字列List (要素数約4000) をComboBoxのDataSourceにセットする処理が、
約900ms～1100msかかり、その間Formが固まるのですが、どうすれば固まるのを回避できるでしょうか。

A5M2でSELECTクエリの所要時間を見ると、だいたい700ms～900ms台で、ここは改善のしようがなさそうです。

2021/07/05(月) 15:45:29.72

ComboBoxで4000の中から選ぶのは大変そうだな
DataSourceに設定する前後にComboBox::BeginUpdate/EndUpdateを呼べば多少は改善すると思う
それ以上はComboBoxじゃ無理じゃないかな　仮想モードもないし

2021/07/05(月) 16:04:21.63

やばそう

2021/07/05(月) 16:35:24.72

>>578
DBからデータ取得する処理は非同期に

2021/07/05(月) 16:53:08.67

>>578
DBから取得する部分を別スレッドで動作するasyncメソッドにするです
UIの更新は別スレッドなのでInvokeで

2021/07/05(月) 17:11:11.76

awaitしとけばUIスレッドに戻ってくるからInvoke要らんだろ

**578** (ﾜｯﾁｮｲ 6f54-SLQ7) · 2021/07/05(月) 17:14:42.74

みなさんありがとうございます。
BeginUpdateとEndUpdateで20～40msほど早くなりました。

現状、DBからの取得部分は別スレッドにしています。
ただし、フォーム表示時に、
①ComboBox の DataSource に List をセット。
②別の個所で設定した値で、ComboBox.SelectedItemを決定。
③ComboBox.SelectedItem に応じて、それに対応するデータを DataGridView に表示。
という処理をしているので、結局ComboBoxへのDataSourceセット待ちになります。

むしろUIと同じスレッドでデータ取得すればスレッド切り替え処理がなくなって微妙に高速化出来るんじゃ？と思ってます。

**578** (ﾜｯﾁｮｲ 6f54-SLQ7) · 2021/07/05(月) 17:33:32.24

データ取得をUIスレッドで行ってみましたが、別スレッドでしたケースと比較して、実行するたびに優劣変わる程度でした。
これ以上の改善は無理そうなのでいったん諦めます。

2021/07/05(月) 17:41:30.27

Formが固まるのを回避したいってのは高速化したいということだったのか・・・
ま、がんばって

2021/07/05(月) 17:41:33.62

>>578
転送時に圧縮かけたら高速化するんじゃね

構成わからんからあてずっぽうでいうけど
DBサーバと近いWEB鯖のPHPでデータ一覧取得してJSONとかで転送（要するにPHPでAPI作成）
サーバの設定等でHTTP圧縮をON
圧縮かかってるから転送そのものが高速化される

どうやって圧縮かけるかは他にも色々やり方あるだろうけどね
LAN内に全てそろってる（例えば同一PC内）としてもかなり速くなるはずだよ

クエリで700msってのが気になるけど時間かかりすぎじゃないかな
Explainみた？

プロファイラはどう？昔はEQATEC Profiler使ってたけど今は何がいいんだろうね
どこにどれぐらいの時間がかかってるかわからないと理論値と比較できない

初見の感想は4000件程度で700msもかかってるのが気になる
応答だけ？それとも結果の羅列まで込みの時間かな
クラサバでそんなにかかる処理ってあまりないと思う

2021/07/05(月) 17:46:44.69

そもそも一瞬で取得すれば固まらないからね
あとはUIに先回りして裏で取得するとか、DB側でキャッシュするとか、小出しにしていくとか・・・

まぁ、一番簡単なのは画面にプログレスバー出してめっちゃ高速に処理してる風を装う事とかだけど

ただ、何も知らずに直観でいうと100msは切るはず

2021/07/05(月) 17:58:05.85

実処理時間と言うより、
取得中に割り込み入れないと固まったように見えるってだけの話では

2021/07/05(月) 18:09:58.95

時間が掛かっているのはデータ取得の部分じゃなくて
取得したデータをコンボボックスに渡す処理(>>584の①)だから
>>579が全てだな

2021/07/05(月) 19:11:56.65

たぶん「犯人」はComboBoxだろうが一応問題の切り分けが必要だと思って
public Form1()
{
　　InitializeComponent();
　　var asm = Assembly.GetAssembly(typeof(Form));
　　var bl = new BindingList<Type>();
　　foreach (var item in asm.GetTypes()) bl.Add(item);

　　var sw = Stopwatch.StartNew();
　　comboBox1.DisplayMember = "Name";
　　comboBox1.DataSource = bl;
　　Console.WriteLine($"Time = {sw.ElapsedMilliseconds} ms, Number of Items = {bl.Count}");
}
こんなコードを書いてみた。10年前のポンコツPCで実行してるが約2400個のアイテムをぶち込むのに
デバッグモードでも10ms程度の時間しか掛からない。

つまり「犯人」はComboBoxじゃないんじゃないの？知らんけど。

2021/07/05(月) 19:44:16.85

>>591
フォームのコンストラクタで測ってるけど、フォームがロードされた後で測るとかなり変わるよ
うちの環境ではデバッグビルドで、コンストラクタ:3msec、Loadイベント時:226msec

2021/07/06(火) 01:07:39.66

DB の実行計画を見れば？
インデックスを使わずに、全件探索でもしてるのでは？

2分探索なら、2 ^ 10 = 1,024
2 ^ 12 = 4,096

つまり、12回探索するだけ

ミックの本でも読んだ方がよい

2021/07/06(火) 07:28:36.60

>>593
その前にソートな

2021/07/06(火) 07:38:26.90

何言ってんだこいつ

2021/07/06(火) 07:47:40.70

インデックス張ったら挿入や更新の度に毎回ソートしてるとでも思ってるんだろ

2021/07/06(火) 08:22:21.59

全件探索なら1回探索するだけ♪

2021/07/06(火) 08:54:22.76

約900ms～1100msの処理のうち
クエリが700ms～900ms台で、改善のしようがないっていってるんだから
それがホントなら速度的なものはどうしようもないと思うんだが

画面が固まる対策ならクエリを非同期に（正確にはUIスレッド以外で、か）しろで終わりだろ

2021/07/06(火) 09:08:47.43

ルビおじに絡むおじさんはルビおじよりさらに無能だからな

2021/07/06(火) 11:25:26.74

やったことないけど、コンボボックスも仮想化できるらしいから試してみたら？
データ取得を非同期に出来てるなら画面が固まることは無くなりそう
https://docs.microsoft.com/ja-jp/dotnet/desktop/wpf/advanced/optimizing-performance-controls?view=netframeworkdesktop-4.8#controls-that-implement-performance-features

2021/07/06(火) 11:36:28.26

>>600
それWPF
>>578はWinFormsみたいだけど

2021/07/06(火) 18:11:30.42

WinFormsのComboBoxに仮想モード追加する例ってありそうで無いな

2021/07/06(火) 21:55:13.16

じゃ俺がWinFormsのComboBoxを仮想化する知恵を貸そうか？

2021/07/06(火) 22:04:24.92

まああてにするな

2021/07/06(火) 22:18:48.94

どうぞどうぞって言おうと準備してたのにw

2021/07/07(水) 02:05:48.56

じゃあ代わりに言うか
「どうぞどうぞ」

**578** (ﾜｯﾁｮｲ 6f54-SLQ7) · 2021/07/07(水) 03:00:22.72

みなさん本当にありがとうございます。

原因は、約4000の要素をDBから取り出す所要時間でした。
約60万レコード内の、文字列カラムのデータを、重複しないように、GROUP BYする処理が時間食ってました。

なので、該当の文字列カラムだけを重複なしで格納するキー一覧テーブルを作り、
データINSERT時に、キー一覧テーブルの既存レコードと一致しない文字列だけをキー一覧テーブルに追加するトリガー処理を作りました。

そして、ComboBox の DataSourceにはそのキー管理テーブルのデータをセットするようにして、表示所要時間を5～6割短縮出来ました。

2021/07/07(水) 06:50:16.04

高々60万レコードの group by に700msって遅くね？
DBMS 何使ってるのかわからんけどインデックス張るだけで良いような気もするが…

2021/07/07(水) 07:38:37.09

マテリアライズドビュー作るとか

2021/07/07(水) 10:41:15.77

GROUP BY自体が遅いもんよ
SQLが悪いとインデックス使っても無視されてFULL検索になってしまう

2021/07/07(水) 12:33:18.92

それより結局ComboBoxは何の関係もなかったってことだよね？

つまりボトルネックがどこにあるのか計測して確認もせず思い込みで
ComboBoxが悪いとミスリードな質問をした。

ここは反省して欲しい。

2021/07/07(水) 12:57:56.68

>>611
やれやれ

2021/07/07(水) 13:00:11.32

最初の質問で問題の処理に約900ms～1100msかかっていてそのうちクエリの所要時間が700ms～900ms台と書いていて、その上でクエリ以外の部分(約200ms)を改善したいという話だったから測ってないわけではないかと
クエリ部分は改善不可能と思い込んでたのはあるが

2021/07/07(水) 13:00:41.99

>>611は毎度お馴染みで皆さんご存知の、
ComboBoxに責のあるマイクロソフトの犬

2021/07/07(水) 15:16:07.20

最初に戻ると結局画面は固まってなかったってことなんだろうな
これが一番のミスリード

2021/07/07(水) 15:26:49.85

FormのLoadで何も表示されないまま1秒以上かかるとかなり固まった感は強い
だからスプラッシュやプログレスバーというのは非常に大事
これがあるだけでクレーム率はかなり下がる

速度最適化というのは実際のレスポンスやスループットだけではなくて
体感速度も最適化するべきなんだ

2021/07/07(水) 15:38:40.22

いや、クエリの間は固まってたんじゃね
そういう意味ではコンボボックスは無関係だな

2021/07/07(水) 19:17:38.62

別スレッドで取得してるって言ってんのに？

2021/07/07(水) 20:02:39.26

別スレッドの処理終了を同期で待ってたら固まるよね

2021/07/07(水) 20:04:38.68

別スレッドでの取得結果を待たずにコンボボックスが表示できるとは知らんかった

2021/07/07(水) 20:05:37.60

空のはできるんじゃないの？