Win32API質問箱 Build123©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Win32APIについての質問はこちらへどうぞ。
■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで
■過去スレ
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/ >>98
IsDialogMessage使ったか？ >>101
スタックに作ったとしても処理は止まらんだろ。
スタック解放されたらメモリリーク等になるだけだ。 イベントループまわしてない糞アプリは結構あるけどな WindowsServerの共有フォルダに対して
一台のPCで複数のセッションを
張りたいのですが
そういうことは可能でしょうか?
セッション枯渇をシュミレーション
したいのですが、数十台の
クライアントを用意するのが厳しいので、
よろしくお願いします 98です。
残念ながら本当にわかっていなくて、
なにがひどいのかもわかりません。
一瞬で終わっているのは事実です。
IsDialogMessageは使っています。
原因を調べています。 >>111
ダイアログはメインスレッドで作った方がいいんじゃないか？
そうじゃなきゃ、作成したスレッドでイベント処理が必要になる。 メッセージキューはスレッドごとに用意されていて、ウィンドウのメッセージは
ウィンドウ作成元のスレッドのメッセージキューにたまる。 シュミーズとスリップとキャミソールの違いってなに？ >>114
その程度も想像できない人の意見なんてどうでもいいです その想像力を駆使して趣味レーションすればいいんじゃね？
Win32APIには関係ない話だし。 win32apiに関係なくてもいいんじゃなかったけ？ >>112
ありがとうございます。
試してみます。 IDないときにID導入で言い争いなくなってたのに
久しぶりにここ来たらIDありでも構わず言い争いしててワロタ
ついでに次スレはﾜｯﾁｮｲでもつけよう 何を付けても言い争いが発生するんだから、
IDくらいがちょうどいいんじゃないの。
どこのスレ見ても、荒らす奴はなにやっても荒らすし。 IDとかﾜｯﾁｮｲとか何の意味もないのに付けたがるよね
今の２ちゃんなんか人少なくて気にするほどの書き込みもないのに >>123みたいな奴が色んなスレで終盤になって現れる
その後不自然にﾜｯﾁｮｲの話題で加速
付けてもいいけど伸びた方を使う ﾜｯﾁｮｲは争いの火種
最初からないほうがまし
別にIDもいらない 急激に過疎ったスレとして資料価値がある
一番勢いあったのがIDなかった時代だというのが興味深い 単にWin32から.NETへの移行が進んだだけでしょう 回顧モード中ですが、ちょっと教えてくだされ。
スケーリング対応ってどの辺のAPIを使うといいの？
もしくは、どの辺のAPIを見直せばいいのか。 うろ覚えだけど
SetWindowOrgEx
SetViewportOrgEx
辺りじゃないの @AoA = (
[ "fred", "barney" ],
[ "george", "jane", "elroy" ],
[ "homer", "marge", "bart" ],
);
を関数に渡したいんですが、どうすればいいの？ EnableMenuItem
https://msdn.microsoft.com/ja-jp/library/cc410786.aspx
>MF_DISABLED メニュー項目を無効化します。淡色表示にはしませんが、そのメニュー項目は使用不可能であり、選択できません。
>MF_GRAYED メニュー項目を淡色表示にします。そのメニュー項目は使用不可能であり、選択できません。
となっており、MF_DISABLEDはグレー表示されないように書かれていますが、
Win7で使ってみたところ、グレー表示され、MF_GRAYEDとまったく同じになりました。
MSDNが更新されていないだけで、MF_DISABLEDとMF_GRAYEDは同一挙動になったのでしょうか？
それとも、何か微妙に違いがあったりするのでしょうか？ >>146
俺はGetWindowRectがまともに動かない時点でスケーリング対応は諦めたわ。なんなのこのクソOS TrackPopupMenu()でポップアップメニューを表示できますが、
ポップアップメニューが表示されたことを検知できるウィンドウメッセージ等はないのでしょうか？
また、ポップアップメニュー以外のところをクリックするとポップアップメニューが非表示になりますが、
これも同様に、どのように検知すればよいでしょうか？ ポップアップメニューが表示されようとしたときはWM_INITMENUPOPUPが送られてくることが分かりました。 非表示はWM_UNINITMENUPOPUP
MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ >>152
ありがとうございました！
助かりました！ リストビューを一番下までスクロールさせるプログラムは？ ListView_EnsureVisible()マクロないしは
ListView_Scroll()マクロ > MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ
xpはどちら？ WS_EX_TOOLWINDOWに関して質問です。
タイトルバーに関してです。
普通のタイトルバーより小さいタイトルバーを持つ旨説明がありますが、
小さくなりません。
通常のスタイルも色々試しましたが、通常のタイトルバーと変わりません。
変える方法を教えてください。 win8辺りからタイトルバーが小さくならなくなったべ。
理由は知らんけど、エアログラス廃止→モダンUIの流れの一環で何か変わったのかもね。 > MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ
7で非エアロ + 視覚効果を無効にした場合はどちらになりますか >>165
なるほど、そういうことだったんですか。
ありがとうございます。 Windows3.1 って 標準で１画面に16色しか使えなかった時代の名残だから忘れていい sscanf(buffer, "%4s", &data)の4の部分に変数を使いたい場合ってどうしたらいいんでしょう？ >>175
int space = 4;
sscanf(buffer, "%*s", space, "t") >>175
"t"は編集ミスだから気にしないで
*の所にspaceの値が指定される windows8.1 環境下、imm にて ImmSetCompositionString で漢字変換したい文字列を設定し、
ImmNotifyIME で CPS_CONVERT、NI_OPENCANDIDATE を投げて
変換候補リストを表示したいのですが、MS-IME 系では問題なく使えていますが、
GoogleIME では変換候補リストが表示されません。
変換したい文字列が入力された状態にはなっていますが、変換候補リストが表示されない
だけでなく、キーボードで変換キーを押しても変換自体ができません。
（GoogleIME ではキー入力でただちに予測変換一覧が表示される仕組みだからか？）
これを実現するには、imm ではなく tsf に移行するしかないのでしょうか？
imm を使わず keybd_event でキー入力をエミュレートすればある程度実現できたのですが、
（文字入力→変換キー→変換候補一覧表示）
変換候補一覧を表示するための変換キーを押す回数が、MS-IME と GoogleIME では異なる
のが困ります。
ImmGetDescription で動作を切り分けることも考えましたが、そもそも ImmGetDescription が
廃止されてしまってこの手が使えません。 Watashi no Namae wa Nakano desu Watashi ni Namae wa Nakattano desu 分かる方、教えて下さい。
プログラムの処理時間を計っているのですが、
GetThreadTimes()で取得した時間をもとに計算した処理時間（ＣＰＵ時間）が
timeGetTime()で取得した時間をもとに計算した処理時間（実時間）より長くなりました。
スレッドが複数のコアを同時に使うことはないので
こういうことは起こらないはずだと思うのですが、
どういう場合に起こるのでしょうか。
なお、1/16秒くらいの精度しかないことは、認識しています。
その上でループを何度も回して十分な時間動作させた上で、
前者が後者の２倍くらいになってしまうのです。 GetThreadTimesで計算したのは処理時間でなくスレッド生成オーバーヘッドとかも含んでるからとか？ >>186
そうでもないです。
スレッド生成終了は含まない部分を計っています。
チェックポイントで各関数で時刻を取り、差を計算して、
チェックポイント間にかかった時間を出しています。
>>185
1/16は1/64の誤りです。 >>185
思いつくのはこのあたり
・単位は合っているか。GetThreadTimes()は１００ナノ秒単位、timeGetTime()は1ミリ秒単位
・GetThreadTimes()の計算方法は、作成時刻から終了時刻までの差なのか、カーネル・ユーザモードの実行時間の合計なのか
・timeGetTime()はいつどのタイミング、またどの場所で呼び出しているのか
・timeGetTime()が計測スレッド内部で実行されているなら
GetThreadTimes()の“作成時刻”からtimeGetTime()が実行されるまでの時間が含まれていない
・timeGetTime()が計測スレッド内部で実行されているなら
終了時のtimeGetTime()の呼び出しからGetThreadTimes()の“終了時刻”までの時間が含まれていない
・カーネル・ユーザモードの合計なら他のスレッドの“実行時間”が含まれていない >>187
GetThreadTimes()がtimeGetTime()の２倍なんでしょ？
ただ２倍と言っても１ミリ秒が２ミリ秒になったってのと１分が２分になったというのではかなり違う
平均して何ミリ秒が何ミリ秒になったの？
timeGetTime() チェックポイントA
スレッド作成 ポイントα
timeGetTime() チェックポイントB
いろいろ実行
timeGetTime() チェックポイントC
スレッド終了 ポイントβ
timeGetTime() チェックポイントD
GetThreadTimes()はαやβの時刻であって、timeGetTime()でA〜Dのいずれかで計測しても誤差は生じる。
「スレッドが複数のコアを〜」からすると計測スレッドでチェックポイントを設けているように見受けられるので
B、C間とするとαからBまでの差が含まれていないと思うけど。
ポイントαの時刻って言うのも「スレッドの作成を開始した時刻」なのか「スレッドの作成が完了した時刻」なのかでも誤差は生じる。 >>188
・timeGetTime()とGetThreadTimes()の単位の違いは認識しています。
・GetThreadTimes()による時間の計り方ですが、
CreationTimeとExitTimeは一切使用せず、
KernelTimeとUserTimeだけを使用して、チェックポイント間の差を取り、
ユーザーモード時間とカーネルモード時間を個別に出しています。
・スレッドの開始及び終了は、チェックポイント間に入っていません。
>>189のイメージでいう所のBとCの間のいろいろ実行の部分だけを計っている感じです。
>>189
・今動かしてみたら、
500回ほど回して平均を取った上での数字として、
B-C間の測定結果が、
timeGetTime()の場合で9msec
カーネルモード時間が429usec
ユーザモード時間が14037usec
になりました。
2倍までいってませんが、2倍くらいになることもあります。
・スレッド生成及び終了の処理部分は計っていません。 GetThreadTimesが必ずしも正確な時間を返さない可能性もある
スレッドの切り替えは可能な限り超早業で行う必要があるので
細かな正確な時間など、二の次かもしれない
もっと長い時間のかかる処理(10秒とか)を走らせてみて
実時間とスレッド時間を比較してみては？
もしそれで上手くいくのなら、スレッド時間の精度の問題という
可能性が濃厚になる >>191
volatile変数をひたすらインクリメントするコードを書いて、
試してみました。
timeGetTime()で計った時間：10560msec
カーネルモード時間：280801usec
ユーザモード時間：10296066usec
4個のコアを食いつぶさせるために5個同時に動かすと、
timeGetTime()で計った時間：12sec〜18sec
カーネルモード時間：343msec〜608msec
ユーザモード時間：11902msec〜12729msec
1プロセスから2スレッド起動するのもやってみましたが、
timeGetTime()で計った時間：11869msec
スレッド１
カーネルモード時間：312msec
ユーザモード時間：11403msec
スレッド２
カーネルモード時間：390msec
ユーザモード時間：11528msec
プロセス
カーネルモード時間：1092msec
ユーザモード時間：22776msec
ほぼ期待通り（本来あるべき）の結果となりました。 もう一つの可能性として
timeGetTimeの方の精度があまりよくない可能性もある
>Windows NT：timeGetTime 関数の既定の精度は、マシンによっては 5 ミリ秒以上になる場合があります。
とMSDNにも書いてあるしな
君が最初に測ろうとしていた処理の時間は
>timeGetTime()の場合で9msec
であるから、timeGetTime の「デフォルト」の精度の「5ミリ秒以上になる」は無視できない誤差だね >>193
十msec規模の誤差がありうることや、
9msecに対して5msecが無視できないことは理解します。
ただ、>>190に書いた9msecは
500回動かして平均を取っ（て整数にまるめ）た数字です。
誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので、
スレッドのＣＰＵ時間が実時間の1.5〜2倍になることについては、
誤差以外の原因があるのではないかとかんぐっています。 >>194
> 誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので
誤差が均等にバラつくなんていう保証はないだろ 時間取得のオーバーヘッドじゃないか？
>>195
誤差の定義てか確率論の考え方を真っ向から否定してるなｗｗ いや、、、誤差の平均取るなら複数の環境でやらんと
同じ環境ならプラスばっかりとかマイナスばっかりとかあるべ 環境というか仕組み上プラスしかないとかマイナスしかないということもある 新たな発見がありました。
スレッドのＣＰＵ時間が実時間よりだいぶ長くなるコードの時間測定ですが、
該当コードを2回実行するコードと3回実行するコードも計ってみました。
（いずれも500回平均です。）
1回
timeGetTime()による時間：7msec
カーネルモード時間：1060usec
ユーザモード時間：13540usec
2回
timeGetTime()による時間：14msec
カーネルモード時間：2246usec
ユーザモード時間：13291usec
3回
timeGetTime()による時間：21msec
カーネルモード時間：2527usec
ユーザモード時間：19468usec
このデータから、
timeGetTime()はかなり正確であり、
GetThreadTimes()が真値より随分大きな値を返していることが強く疑われます。
クロックの誤差は、通常は、クロック更新粒度に起因する誤差であり、
それは一様な分布であるため、平均処理で抑えられます。
しかし、明らかにプラス方向の誤差が生じており、
クロック精度とは別の何らかの原因があるはずなのですが、
現在、原因の特定に至っていません。 >>200
「クロック更新粒度」がいわゆるtickのことなら常に一方向に偏るはず。
timeGetTimeはtick単位の値を返すから、より正確な値を返すGetThreadTimesより
短い時間を返す、ということじゃないの？ ■ このスレッドは過去ログ倉庫に格納されています
