Win32API質問箱 Build124
■ このスレッドは過去ログ倉庫に格納されています
Win32APIについての質問はこちらへどうぞ。
■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで
■過去スレ
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/
■関連スレ
Visual Studio 2017 Part4
http://mevius.2ch.net/test/read.cgi/tech/1509244956/
【C++】 DirectX初心者質問スレ Part40 【C】
http://mevius.2ch.net/test/read.cgi/tech/1474782237/ >-lodbc32 でコンパイル
これで実行時に見に行くのが 32 になるか 64 になるかは決まらない
いわんか wow64 を見るのか system32 を見るのかをや WS_POPUPの子ウィンドウって、
親ウィンドウからはGetNextWindow()などのループで辿っていけないものですか?
GW_ENABLEDPOPUPだと、見えているものしか出てこないようです。 見えてる=enabled popup
ってことなんだな。普通にGW_CHILD使えばいいじゃん >>104
GW_CHILDだとWS_POPUPのやつは出てこないようです 人間は見えるものしか見ない
馬鹿は観たいものしか見ない EnumWindows、EnumChildWindows推奨。 ためしたらまじでgw_childだめなんだなw
全ウインドウの親見てくのか >>107
デスクトップの子ウィンドウを巡っていって、
片っ端からその親を調べていくしかないってことですか? >>99
引き続き ODBC まわりを触っている
コンパイラの警告を黙らせるために、いい加減に適当にキャストしていたのが、バグ(c++ delete が失敗する)のもとになっていた
ああ、ダウンキャスト/アップキャストの区別がつかない、こまったこまった ODBC を完全に把握した
しかし、面倒なので jdbc を使うことにした… IsWindows10OrGreater関数を、
Windows10最新版(build16299)で使用すると、
Windows10にも関わらずfalseが返ってきます。
原因に心当たりのある聡明なお方はいらっしゃいませんか…? GetVersionExはウソつきだが、OSのバージョン番号に依存するアプリは地獄へ行かねばならぬ。 それapiじゃなくてVersionHelpers.hにある関数じゃないか?デバッグして何かえってるか見ろ VersionHelpers.hの実装はVerifyVersionInfoだけどどのみちマニフェストでの指定は必要ってだけやね GetCursorPos ってマルチモニタに対応してるんですかね? >>120
している。仮想スクリーンの座標系になる。 >>121
ウソを書いてしまった。ごめんなさい。
仮想スクリーンではなく、プライマリーなスクリーン座標になる。
https://msdn.microsoft.com/en-us/library/windows/desktop/dd145136.aspx
これとSM_XVIRTUALSCREENとSM_YVIRTUALSCREENを使って座標値をずらすと仮想スクリーン座標が得られる。 モバイルカテゴリの人がWindows関連スレを覗きに来るか? win32api の記述を C から C++ に移行中です
CreateWindow() が hwnd を返すタイミングより先に、ウィンドウプロシージャに WM が流れ始めることを特定するのに時間がかかりました… >>129
20年前位にやったなあ
WindowProc
DialogProc
ThreadProc
****Callback
この辺を包んでクラス化
ウィンドウの場合
CreateWindowのパラメータでクラスのポインタを渡し
WM_CREATEで受け取るって感じ >>130
そうです、それです!WNDCLASS.cbWndExtra を使うのがミソです!
CreateWindow(..... 最後 (Derived)this);
extern "C" long CALLBACK WindProc(...) {
if (msg == WM_CREATE) {
p = (Derived*)((LPCREATESTRUCT)lp)->lpCreateParams;
SetWindowLong(hwnd, 0, (LONG)p);
p->hwnd = hwnd // これを見つけるのが大変だった
.
} else {
p = GetWindowLong(hwnd, 0)
return p->WindowProc() // goto Derived::WindowProc()
}
Derived::WindowProc() {
this->Base::WindowProc()
virtual Base::WindowProc() {
HWND hwnd // member instance variable
return ::DefWindowProc(this->hwnd, mwg, wp, lp);
温故知新… 厳密にはWM_CREATEの前にもいくつかメッセージ飛んでくるけどね >>132
了解!そういうのは全部まとめて ::DefWindowProc() に流しちゃっているのでダイジョブです! この行いらね
HWND hwnd // member instance variable >>134
ごめんなさい >>131 ははおって書いたので、内容が今一つはっきりしなかったこと謝罪いたします。
その行は、自作 Window クラスのメンバとして書いたつもり、Window クラスに hwnd を持たせたいと考えているのです cbWndExtra == 0なウィンドウには使えないから、結局、設計思想が間違っている。 GWLP_USERDATAをライブラリ側で潰してる時点で同レベルだな しかし、ハンドルマップにしたら、コストがかかるんだよな。 他人に設計思想が間違ってると宣いつつ自分は即座に言い訳
さすがカス山 MSゴシックやMS明朝のフォントで描画するとき、
小さいときはビットマップフォントが使われることは知っているのですが、
常にビットマップフォントを使わないように
CreateFontなどで指定することはできませんか? 使われることも知らなかったが、小さいとドットが出てくるからビットマップをやめるメリットがなく逆に処理が多くなるデメリットが大きくなるんじゃないか? DirectWriteだと強制的にヒンティング切れるからそれでイケる
GDIはGetGlyphOutlineでAA付きで書き出すくらいしか知らん 24dot x 24dot とかで truetype 描画とかしたいの? ワイは大きめのビットマップメモリ領域に一度描画してから、縮小表示という無駄オブ無駄処理しとるやで MZC4、ハンドルマップに切り替えできるようになったよ。
https://github.com/katahiromz/MZC4
#define MZC4_HANDLE_MAP IPアドレスコントロールのEDIT子ウィンドウがGWLP_USERDATAを使っているみたい。。。 GWLP_USERDATAを使うのは低コストな選択肢としてアリ。ただし、IPアドレスコントロール内部やユーザー側のコントロールに触れる場合は、
問題が生じる可能性がある、という結論でファイナルアンサー。 extradataはチェインにして使うもんじゃね? >>154
問題が生じる可能性があるけど選択肢としてアリなら
なぜ他人の実装には間違ってるなんてケチつけたんだ? >>147-150
ありがとうございます。
やっぱり簡単にはいかないんですかね。
印刷の処理は今のままでよく、画面上をその印刷イメージに近づけたいので、
DirectWriteの勉強をしてみたいと思います。 印刷物をモニターに等倍表示したいんだ!ってわけじゃないだろ?
モニター上に拡大表示すりゃいいじゃん わざわざ小さいときはビットマップフォントを使うのは、
その方が綺麗だからなんだけど >>157
>印刷の処理は今のままでよく、画面上をその印刷イメージに近づけたいので
やったことないけど・・・
CreateDC(プリンタドライバ名・・・)
CreateCompatibleDC()
CreateCompatibleBitmap()
でプリンタ互換のメモリデバイスコンテキストを作成し、これに印刷と同じ描画を行った後、
BitBltで画面にコピーするなり、DIBセクションにコピーするなりすれば良いんじゃね? それするとデバイスコンテキストに書き込んだ時に、フォントがビットマップ描画になるから嫌ってんでしょ
そもそもプリンタ自体の解像度とかあるから、ビットマップやめたとこでそれ意味あんのって感じだけどw >>161
解像度の高いプリンタではTrueType中のVectorデータ、解像度の低い画面ではTrueType
中のビットマップデータが使われることで、文字幅(→結果的に文字位置)が微妙に違って
しまうのを嫌っているんじゃないかとエスパーした Acrobat Readerは、MSゴシックやMS明朝で画面上の表示が小さいときも
ビットマップフォントは使われないようですし、
やはりビットマップフォントよりも綺麗に見えるので、
これと同じような描画ができないかと思った次第です。
もちろん、AdobeがGDIだけで描いているとは思ってませんが。 Instructs the font mapper to choose from only TrueType fonts. win32api直接叩いてるんですけど、タブオーダーってどうやって設定されるんですか?
多分 CreateWindow 呼んでコントロールを作った順番そのままだと思うんですが、
なんかTABキー押してもフォーカスが移動しないんです モードレスの場合は、メッセージループにIsDialogMessage呼び出しが必要。 ああー
助かりました
IsDialogMessage でうまくいきました。
余談ですが CreateWindow の呼び出し順とは逆に移動するんですね。
Z手前から奥に向かって移動する感じですかね。
とりあえず後はどうにかなりそうです プリプロセッサマクロ値 "_MSC_VER" を知る方法はありませんか?
cuda 9.1 提供のヘッダの #error が反応してしまいます dll間でデータを共有するのはdata_segでできるけど
dllAで動的確保したデータ(クラスでメンバ関数有り)をdllBでも使えるようにするには
マッピング以外に何がある? ふつうにポインタ渡せばいいんじゃね?もちろんクラスの定義は一致している前提だけど。 ごめんdllA, dllBって書いたけど間違い
正しくはexeAとexeBが同じdllを使ってる状況で
exeAで動的確保して初期化もしたクラス(メンバ関数有り)をexeBのdllでも使いたいんだ プロセス間で共有したいんだろ?
共有メモリでもなんでも使ってデータ本体を保管
データ本体にアクセスするクラスを作ってそれはプロセス内でのみ利用すりゃいい
要はクラスそのものはプロセス間で利用しようと考えない >>182
それだとメンバ関数実行でexeBのdllが異常終了する
>>183
やっぱそういうのしかないんかな
ありがとう クラスにnew と new[] 定義すればエラーにならないでしょ? Windowsがシャットダウンした時刻を記録したいんだけど、
1秒おきにファイルに時刻を書き込み続けるしかないかね? カーネルエラーで落ちたのでなければイベントログにシャットダウン時刻が書いてあるはずだが VS2015とVS2017のsplitpathがMBCS対応してないんだけどどういうこと? >>186
イベントログの他には
WM_QUERYENDSESSION
WM_ENDSESSION
WM_POWERBROADCAST 初歩的な内容で申し訳ないのですが、、、
親ウィンドウと子ウィンドウがあります。
子ウィンドウは自分でCreateWindow()を使い、親のウィンドウハンドルを指定して作っています。
そこで質問ですが、親ウィンドウでWM_DESTROYを処理する際に、子ウィンドウに対して
明示的にDestroyWindow()を一々実行する必要はありますか?
自分としては子ウィンドウは親の破棄に伴って暗黙のうちに破棄されると勝手に解釈しているのですが、
間違いがあればご指摘ください。 確認不足でした。
DestroyWindowをしなくてもちゃんと破棄されていましたね。
WM_DESTROYが来ていました。
すみませんでした。 ウィンドウサイズが変更禁止されているウィンドウを強制的にサイズ変更する方法を教えてください 聞く前にとりあえずあっちのスレの>>134をやったらどうだ? >>195
チョコもらわないで、何作ってんだよ、ヒマジン。
ネトウヨ超きも。 ■ このスレッドは過去ログ倉庫に格納されています