Win32API質問箱 Build81
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/08/02(日) 00:20:49やさしいお兄さんやお姉さんたちが答えてくれるかも。
「知らないならレスしないで下さい。ウザイだけです。 」なんて言わないでねっ！
過去スレ、関連リンクは>>2-10くらい。
■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで
- Win32API質問箱 wiki
http://wiki.livedoor.jp/program1/d/FrontPage
Win32API質問箱 Build80
http://pc12.2ch.net/test/read.cgi/tech/1244057140/l50
0446デフォルトの名無しさん
2009/08/25(火) 23:23:06文字列を受け取る処理を書くときって
TCHAR szBuffer[256];
sizeof(szBuffer) / sizeof(szBuffer[0])
ってやらないと駄目だよね？
UNICODEだと、szBufferはwchar_tだから、sizeof(szBuffer)だと512になるから
文字列を受け取るバッファサイズは512になるから、問題出てくるよね？
0447デフォルトの名無しさん
2009/08/25(火) 23:26:16開放したアドレスの参照を持ち続けているほうが問題。
shared_ptrを使えばアドレスをオブジェクトを区別するユニークなIDとして使える。
0448デフォルトの名無しさん
2009/08/25(火) 23:29:360449デフォルトの名無しさん
2009/08/26(水) 11:01:26ShowWindow
SetForegroundWindow
SetFocus
を利用して表示してるんだが
中途半端な表示されてるのか
一度画面をクリックして完全にアクティブにしないと
フォーカスがセットされない
何かいい解決策ないかな？
0450デフォルトの名無しさん
2009/08/26(水) 11:44:28悪い方法1
SPI_SETFOREGROUNDLOCKTIMEOUT
悪い方法2
グローバルフックなどのコードインジェクションでアクティブスレッドから無理矢理変更
0451デフォルトの名無しさん
2009/08/26(水) 11:54:48AttachThreadInput
0452デフォルトの名無しさん
2009/08/26(水) 12:00:10悪い方法しかないのかw
一応一通り試してみるよ
有難う！
0453デフォルトの名無しさん
2009/08/26(水) 13:03:08いや、だって、普通に操作してるとき、唐突に他のウインドウがフォーカス奪ったら嫌じゃね？
しかも奪いっぱなしだったらさらに嫌じゃね？
だからできないようにできてるんだって。
0454デフォルトの名無しさん
2009/08/26(水) 13:07:540455デフォルトの名無しさん
2009/08/26(水) 14:26:580456デフォルトの名無しさん
2009/08/26(水) 14:32:050457デフォルトの名無しさん
2009/08/26(水) 14:52:21ttp://msdn.microsoft.com/en-us/library/bb773397(VS.85,loband).aspx
FirefoxどころかIEでもおかしいので困ってる。
0458デフォルトの名無しさん
2009/08/26(水) 14:54:240459デフォルトの名無しさん
2009/08/26(水) 15:36:01div.libCScode { clear: none !important; }
IE8で互換表示をオンにすると崩れないのがワロスｗ
なんでIE6/7向けのCSSをIE8や火狐に送ってんだよｗｗｗ
0460デフォルトの名無しさん
2009/08/27(木) 12:23:42ga
0461デフォルトの名無しさん
2009/08/27(木) 21:51:29Web上でのコードなどはGetDC(hwnd)などとして描画していて、wParamの値を使っていませんが
メッセージのwParamで渡されるハンドルは一体何に使えるんでしょうか
0462デフォルトの名無しさん
2009/08/27(木) 22:16:37いったい何が聞きたいんだ？
0463デフォルトの名無しさん
2009/08/27(木) 22:29:00どういった領域をあらわしてるんでしょうか
0464デフォルトの名無しさん
2009/08/27(木) 22:31:250465デフォルトの名無しさん
2009/08/27(木) 22:43:250466デフォルトの名無しさん
2009/08/27(木) 22:49:510467デフォルトの名無しさん
2009/08/27(木) 23:46:000468デフォルトの名無しさん
2009/08/28(金) 09:22:380469デフォルトの名無しさん
2009/08/28(金) 11:29:5198の関数ってUnicode版は定義してあるだけの奴が多い
中身も実装されてるのはほとんど描画関係
0470デフォルトの名無しさん
2009/08/28(金) 11:37:13じゃあ一つのバイナリでANSIとUNICODEへの切替は無理か…
0471デフォルトの名無しさん
2009/08/28(金) 11:41:210472デフォルトの名無しさん
2009/08/28(金) 12:27:24CreateFile(L"\\\\.\\pipe\\pipename", GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
とアクセスしたところ，アクセス拒否が帰ってきてCreateFileに失敗してしまいます
プロセスを管理者権限で起動すると，上記のCreateFileは成功します．
なんとか管理者権限で起動することなく，サービスのパイプに接続する方法はないでしょうか？
環境はVista SP2です．
0473デフォルトの名無しさん
2009/08/28(金) 12:34:080474デフォルトの名無しさん
2009/08/28(金) 12:57:300475デフォルトの名無しさん
2009/08/28(金) 15:48:46DrawText関数はRECT構造体をあさんでいるため、浮動小数点での渡し方がわかりません。
どうすればよいのでしょうか？RECT構造体のメンバ(座標を表すLeft, Top, Right, Bottom)がintで定義されてしまっています。
0476デフォルトの名無しさん
2009/08/28(金) 15:54:280.以下のピクセルを指定したいならTextOutで一時ビットマップに出力してから、手動で欲しい出力を計算する
0477デフォルトの名無しさん
2009/08/28(金) 16:04:55TextOut関数は使おうとは思っていません。
DrawText関数は引数でRECT構造体を指定する必要があるので、RECT構造体の
座標が適用されます。しかしそれらのメンバはすべてintで定義されています。
intでメンバが定義されているとどうやってもdoubleを使うことはできないんですか？
0478デフォルトの名無しさん
2009/08/28(金) 16:08:02intしか受け取らないと表明している関数は、intしか受け取りません
0479デフォルトの名無しさん
2009/08/28(金) 16:10:27単純にソースの順序がおかしかっただけでした。すいません。
0480デフォルトの名無しさん
2009/08/28(金) 16:14:24環境はUNICODEを想定していますが、TCHAR型も渡したいです。
0481デフォルトの名無しさん
2009/08/28(金) 16:44:51_tcschr
_tcsrchr
0482デフォルトの名無しさん
2009/08/28(金) 17:06:520483デフォルトの名無しさん
2009/08/28(金) 18:08:09参考になるページをご存じないでしょうか？
0484デフォルトの名無しさん
2009/08/28(金) 18:11:36StrStrを呼びまくれば実現できるからでは？
0485デフォルトの名無しさん
2009/08/28(金) 18:14:010486デフォルトの名無しさん
2009/08/28(金) 18:15:49文字コード判定がめんどいけど
0487デフォルトの名無しさん
2009/08/28(金) 18:23:280488デフォルトの名無しさん
2009/08/28(金) 18:25:140489デフォルトの名無しさん
2009/08/28(金) 18:26:050490デフォルトの名無しさん
2009/08/28(金) 19:07:43つhttp://eternalwindows.jp/#security
0491デフォルトの名無しさん
2009/08/28(金) 19:43:36ありがとうございます．
無事解決しました．
0492デフォルトの名無しさん
2009/08/28(金) 20:26:06普通にできたけど
めんどくせえ…
0493デフォルトの名無しさん
2009/08/28(金) 23:29:10空実装ではあるが関数はあるので、わざわざLoadLibraryを使う必要はない。
処理を振り分けさえすれば動く。それでも面倒だが。
>>470
手軽に済ませるならunicows
ただし過度な期待は禁物。
0494デフォルトの名無しさん
2009/08/28(金) 23:30:03Unicodeがいいらしいけど、目に見えてメモリの使用量や軽さって分かる？
マルチバイトにすると、NT系のOSは常にUnicodeで保持しつるから
マルチバイトに変換するオーバーヘッドがかかるらしいが
0495デフォルトの名無しさん
2009/08/29(土) 00:24:10シングルバイト圏で作ったソフトが、マルチバイト圏で文字化けしたり、最悪セキュリティホールになったら困るでしょ
0496デフォルトの名無しさん
2009/08/29(土) 00:50:40OutputDebugStringWのような例外もあるから注意な。
0497dye kkmzqlm
2009/08/29(土) 00:52:04ge
r>>189
> >>1o88. mshw
> SATAgケーブル 電源ケーブル ポートを変えてやってみる
v> ae
> rIDEモードでF6指示無しは正常だろう
>
> マザーかHDDが壊れてるんじゃ
なpzいの
0498ddye kkmzqlm
2009/08/29(土) 00:53:25> >>4c90
> ありがとうございます．
> 無事解決しました．
0499ddye kgkkmqqzlqClmgdhgai
2009/08/29(土) 00:56:240500ncbddyie kgfwikkmqqzlqClm vgdhgtai
2009/08/29(土) 00:58:100501デフォルトの名無しさん
2009/08/29(土) 01:41:03鬼のような最適化がかかっていそうだ。
0502デフォルトの名無しさん
2009/08/29(土) 02:32:13吐き出すファイルがShiftJISになっちゃわない？
とてもこまる。
0503デフォルトの名無しさん
2009/08/29(土) 02:52:21だからUnicodeな文字が化けちゃうし、
OutputDebugStringWよりOutputDebugStringAの方がオーバーヘッドが小さいというｗ
0504デフォルトの名無しさん
2009/08/30(日) 20:59:160505デフォルトの名無しさん
2009/09/01(火) 06:40:04STATICコントロールなら分かりますが…
別の疑問で、ツールチップに使用するTOOLINFO構造体がありますが、
typedef struct tagTOOLINFO {
UINT cbSize;
UINT uFlags;
...中略...
#if (_WIN32_WINNT >= 0x0501)
void *lpReserved;
#endif
} TOOLINFO, NEAR *PTOOLINFO, *LPTOOLINFO;
最後のメンバlpReservedをわざわざ追加しているのはなぜでしょうか。
必要になった時に追加すればいいように思うのですが。
0506デフォルトの名無しさん
2009/09/01(火) 06:57:45常に追加しておかないと、構造体のサイズが変わってしまう。
変わっちゃうと、cbSizeの値を見てバージョンを判断しているようなコードが困る。
0507デフォルトの名無しさん
2009/09/01(火) 07:03:35コモンコントロールで、ツリービューやリストビュー、ページャー等
TreeView_*やListView_*、Pager_*といったマクロがヘッダで定義されているものと、
トラックバーやアップダウン等こういったマクロが定義されていないものがありますが、
なぜ全てのコントロールでマクロを定義しないのでしょうか。
0508デフォルトの名無しさん
2009/09/01(火) 07:08:050509デフォルトの名無しさん
2009/09/01(火) 07:14:30早速お答え頂いてありがとうございます。
>常に追加しておかないと、構造体のサイズが変わってしまう。
というのはどういうことでしょうか。追加するとサイズが変わると思うのですが。
また、
>cbSizeの値を見てバージョンを判断しているようなコードが困る。
とありますが、何のプログラムが、何のバージョンを、何のために判断するのでしょうか。
0510デフォルトの名無しさん
2009/09/01(火) 07:20:430511デフォルトの名無しさん
2009/09/01(火) 07:22:57何のプログラムが - Windows。
何のバージョンを - どのOSバージョンを対象にしたビルドか。
何のために - 以前のOSとの互換性をとるため。微妙に挙動が違っている可能性がある。
0512デフォルトの名無しさん
2009/09/01(火) 08:20:190513デフォルトの名無しさん
2009/09/01(火) 08:20:47プログラムがどのOSを対象にしたビルドであるかはmanifestで指定する仕組みなのではないかと思うのですが。
また、過去のOSとの互換性をとるために以下のように記述している場合も多いと思います。
TOOLINFO ti;
ti.cbSize=TTTOOLINFO_V2_SIZE;
このことから、プログラムがどのOSを対象にしているのか判断するのは無理ではないでしょうか。
それに、もしそうならOSのバージョンアップ毎にメンバを追加しなければならないはずですがそうではありませんし、
他の構造体はこのような余計のメンバが追加されてはいません。
0514デフォルトの名無しさん
2009/09/01(火) 08:32:42>STATICコントロールなら分かりますが…
これはもういいのか
0515デフォルトの名無しさん
2009/09/01(火) 08:34:51manifestが無かった時代を知らないのか？ｗｗｗ
0516デフォルトの名無しさん
2009/09/01(火) 08:38:43どうでもいいだろが
0517デフォルトの名無しさん
2009/09/01(火) 09:01:20それが一番聞きたかったです。
>>515
このメンバはWindowsXPで追加されており、manifestが無かった時代を考慮に入れる必要はないと思います。
>>516
困ることはあります。
このようにメンバを追加されると、それに気付かずに互換性に問題が出ることがあります。
例えばTOOLINFO構造体のメンバに値を設定するのに以下のようなコードを書いていたとします。
TOOLINFO ti;
ti.cbSize=sizeof(ti);
ti.uFlags=TTF_SUBCLASS;
...他のメンバを設定。しかし、lpReservedは設定していない...
SendMessage(hwnd,TTM_ADDTOOL,0,(LPARAM)&ti);
この場合lpReservedが不定値になり、このメンバに実際に何か意味を持たされた時にプログラムが正常に動作しなくなる可能性があります。
また、構造体のサイズが変わっているので過去のバージョンのOSで動作しなくなってしまいます。
TVITEMやLVITEM等の構造体にはcbSizeのような構造体のサイズを設定するメンバは存在せず、
maskでどのメンバが有効であるかを指定するようになっています。
そのようにすれば上記の問題は起こりませんが、なぜかTOOLINFO構造体はそうなっていません。
0518デフォルトの名無しさん
2009/09/01(火) 09:07:210519デフォルトの名無しさん
2009/09/01(火) 09:21:07とMSDNで書かれてるのにNULLを設定しないお前の糞コーディングを改めろ
0520デフォルトの名無しさん
2009/09/01(火) 09:29:28OSが機能を追加したりするとき、構造体を拡張することはよくあることなのです。
そういう場合、新しいコードが古いものを適切に判断できるように、
cbSizeメンバを持たせることは、windowsAPIの一種のセオリーになっています。
ユーザーがそれを気に入ろうが入るまいが無関係です。
そういうルールなのだから、API利用者はそれを遵守するだけです。
なお、大抵のreservedメンバは０またはNULLで初期化します。must be となっているはずなので
そうしなければなりません。
0521デフォルトの名無しさん
2009/09/01(火) 09:35:540522デフォルトの名無しさん
2009/09/01(火) 09:45:35何のために_WIN32_IEや_WIN32_WINNTがあると思ってんだよ
0523デフォルトの名無しさん
2009/09/01(火) 09:48:08過去にサイズが変わったことのある構造体では気をつけますが、そうでない場合
WNDCLASSEX wcex;
wcex.cbSize=CCSIZEOF_STRUCT(WNDCLASSEX,hIconSm);
などとわざわざ書いている人は見たことがありません。
(SDKにも "Set this member to sizeof(WNDCLASSEX)." と書いてある)
>>520
だんだん質問の意図と変わっていますが、この場合は機能を追加していないのにメンバが増えているのが不思議だったのです。
0524デフォルトの名無しさん
2009/09/01(火) 09:49:510525デフォルトの名無しさん
2009/09/01(火) 09:51:01「よやく」って読むんだけど
辞書引いてみて
引いたらもう二度と戻ってこなくていいよ
0526デフォルトの名無しさん
2009/09/01(火) 10:01:58古いOSに無いAPI関数はDLLから動的に取得して利用したりしますが、
そういう場合その関数で使用する構造体や定数の定義を利用したいということはあると思います。
単純な関数ならまだしも、COMインターフェース等はもっと面倒ですし。
また、ある構造体を「新しいOSにも古いOSにも対応しているつもり」で書いたとしても、
実は他の構造体でもメンバが増やされていて気付かないという場合もあります。
変な流れになって申し訳ないですが、
これよりグループボックスがなぜBUTTONコントロールなのかの方が知りたかったり…
0527デフォルトの名無しさん
2009/09/01(火) 10:03:520528デフォルトの名無しさん
2009/09/01(火) 10:06:07コイツどこまで馬鹿なんだ？
0529デフォルトの名無しさん
2009/09/01(火) 10:06:420530デフォルトの名無しさん
2009/09/01(火) 10:08:210531デフォルトの名無しさん
2009/09/01(火) 10:20:190532デフォルトの名無しさん
2009/09/01(火) 10:22:110533デフォルトの名無しさん
2009/09/01(火) 10:25:570534デフォルトの名無しさん
2009/09/01(火) 10:26:380535デフォルトの名無しさん
2009/09/01(火) 10:30:180536デフォルトの名無しさん
2009/09/01(火) 10:33:38古いOS向けに定義すると、新しいOSに追加された機能を利用したい時にわざわざ
構造体等の定義をコピーしなければいけなくなります。
新しいOSではその機能を利用したい、でも古いOSでも動作するようにしたい、
という場合(この例の場合は逆ですが…)以下のようなコードを書くことがありますが、
OPENFILENAME ofn;
OSVERSIONINFO osvi;
ZeroMemory(&ofn,sizeof(ofn));
osvi.dwOSVersionInfoSize=sizeof(osvi);
GetVersionEx(&osvi);
if (osvi.dwMajorVersion>4 || (osvi.dwMajorVersion==4 && osvi.dwMinorVersion>=90)) {
ofn.lStructSize=OPENFILENAME_SIZE_VERSION_400;
} else {
ofn.lStructSize=sizeof(OPENFILENAME);
ofn.FlagsEx=OFN_EX_NOPLACEBAR;
}
この部分は問題ないが実は別の構造体のサイズも変わっていた…、ということがあると思います。
また、ここで出したOSVERSIONINFO構造体はdwOSVersionInfoSizeというサイズを指定するメンバがありますが、
構造体のメンバを増やした際にOSVERSIONINFOEXという別の構造体が定義されました。
それは dwOSVersionInfoSize=sizeof(OSVERSIONINFO); というコードを書いているプログラムが
過去のOSで動作しなくなるからでしょう。
0537デフォルトの名無しさん
2009/09/01(火) 10:37:000538デフォルトの名無しさん
2009/09/01(火) 10:45:070539デフォルトの名無しさん
2009/09/01(火) 10:46:00ボタンは歴史的経緯。そもそもラジオボタンをまとめるためのものだったし
0540デフォルトの名無しさん
2009/09/01(火) 11:04:56そうできれば楽ですが…
>>539
私がライブラリを作る場合は、構造体と一緒にサイズを表す定数を定義しておいて、
typedef struct Hoge_tag {
size_t Size;
int Member;
} Hoge;
#define HOGE_SIZE sizeof(Hoge)
ドキュメントで「sizeof(Hoge) ではなくて HOGE_SIZE を使ってください」のように書いています。
メンバを追加した時は、
#define HOGE_SIZE CCSIZEOF_STRUCT(Hoge,Member)
#define HOGE_SIZE_V2 sizeof(Hoge)
のように定義し直しています。
ボタンに関しては歴史的経緯ですか。元々はラジオボタンにしか使用していなかったのでしょうか?
ちょっと調べてみます。
0541デフォルトの名無しさん
2009/09/01(火) 11:15:44その程度を面倒がって手抜きするとこういう間抜けな結果になるんだよ
ttp://d.hatena.ne.jp/NyaRuRu/20080303/p1
0542デフォルトの名無しさん
2009/09/01(火) 11:29:360543デフォルトの名無しさん
2009/09/01(火) 11:43:49ガッ
0544デフォルトの名無しさん
2009/09/01(火) 11:52:21そのリンク先では要点として、
>サイズ拡張によるバージョニングが行われる構造体では，CCSIZEOF_STRUCT マクロを活用する．
と書かれており、私の書いている事と同じだと思うのですが。
「WINVERの定義を古いものにして、新しいOS向けの機能を利用したい場合は構造体等の定義をコピーする」か、
「WINVERの定義を新しいものにして、構造体のサイズが変わっていないか確認する」か、
いずれかの不便を選ばなければならないのが問題だと思っています。
構造体のサイズを表す定数は、構造体のサイズが変わった時ではなく、構造体を定義した時に同時に定義すべきだと思います。
しかし、Windowsの場合はドキュメントにも "Set this member to sizeof(WNDCLASSEX)." 等と書かれていて、
互換性の問題を誘発しています。
0545デフォルトの名無しさん
2009/09/01(火) 12:03:04古いOSに対応するのがどういう事なのか全く分かってないようだな
■ このスレッドは過去ログ倉庫に格納されています