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/ ハードウェア描画前提ならdirectXじゃないかなー
wikiでgdiを調べると詳しく書いてあるかもよ。
好きなライブラリー使えばいいよ。 最終的にはメモリDCに書き込んだのをBitBlt()するのが組みやすい
フォーマット変換だけならwicやOpenCV メモリDCで作業してるのに、スレッド排他ロックでアプリ側のマルチスレッド実装を台無しにしてくれるgdiplus jpgだとJpegTurboってのがあって、それなりに速かった
jpgで画像を連続で送ってくるカメラがあって、それで試しに使ったことがある >>62
表示だけならライブラリ探さなくてもOleLoadPicture()で読み込んでDCにIPicture::Renderするだけでいいんじゃないか？ メモリDCへの拡大縮小画像のレンダリングを高速に実現する最適な方法ってなんなのだろう？
ちなみにGDI+ gdiplusは論外。GraphicクラスでメモリDC渡してレンダリングすると、GDI+がスレッドロックするので並列化による省時間はできない。 最適ならDirectX一択だろ
最速になると描画よりも拡大縮小アルゴリズムの話になりそう >>67 の方が教えてくれた IPicture::Render はWindows2000時代からあるレンダリングAPIという認識。
わざわざVista時代にDirect2dをリリースした意味は何なのか、という疑問がありまして、その辺どうなの、と。 32bitARGB画像ならDirect2Dだな、小数点座標指定できるし。
Direct2DのAPIではピクセルフォーマット変換とかHeight方向反転とかできなかったと思うので
異なる場合には渡す前に変換しておく必要がある せめて有名Webブラウザ並みの描画速度で複数画像を一覧表示できてほしいんだけど、その点、gdiplusはダメダメ。
Wikipediaなどの情報によると有名WebブラウザはDirect2Dによる描画らしいので、Direct2Dがいいのかな。 今作ってるソフトの遅い部分が「描画」でそこを改善したいんじゃなくて、たぶんこれから作るソフトの計画だよな
ある程度形になってからどこに時間食ってるか調べてそこを潰したほうが開発時間も動作速度もいいと思うな >Direct2DのAPIではピクセルフォーマット変換とかHeight方向反転とかできなかったと思うので
当然SetTransformはあるしなんなら自分で書いたシェーダを挿入できるエフェクトグラフもあるでよ？ >>76
SetTransformで鏡像反転できるのか
マトリクス係数考えてみるわ 低レベルな話ですみません。
ダイアログアプリケーション（calc.exe と同様）
を win32api/C で書いています。
希望：ベースのダイアログの色を起動後に変えたい。
したこと： WM_CTLCOLORSTATICを捕らえて、
SetBkColor((HDC)wp, BackGroundColorG); および
return HBRUSH ／ HBRUSH を DefWindowProc() に渡さずに返す
以上で、スタティックコントロールの背景色およびエディットコントロールのディスエイブル時の背景色は変わりました。
しかし、ベースダイアログの色は変わりません。
頭で、RegisterClass() にわたす前に設定する WNDCLASS の hbrBackground の値が、ダイアログのCreateWindow() の後も反映されています。
後から
SetClassLongPtr((HWND)lp, GCL_HBRBACKGROUND, (LONG)hbrBackGroundS)
しても反映されないことを確認しています。
起動後にダイアログの色を変えるにはどうすればいいでしょうか？
明日には再現コードをお見せできると思います。
アドバイスいただきたくよろしくお願いいたします。
＃WINDCLASS.hbrBackground = NULL にすると、透けてデスクトップが移りこみ、これはこれで面白いです…もう寝ます >>80
WM_CTLCOLORDLG でブラシを返す >>81
コメントいただき感謝しています。
試してみたのですが、よくありません。やはりダイアログは WNDCLASS.hbrBackground の指定が優先されています。
現象を再現させたコード次のとおりです。こちらでは cygwin/mingw 32 ビットでコンパイルしています。
test.c https://ideone.com/pch378
test.h https://ideone.com/1iKq2z
test.rc https://ideone.com/kZH3Uf
makefile https://ideone.com/9MDXT0 >>81, >>83-84
コメントありがとうございます。
状況が変わりました。すなわち、
1. DefWindowProc() ではなく、DefDialogProc() にする
2. (>>81) WM_CTLCOLORDLG メッセージ処理（ブラシを返す）
によりダイアログのベースの色が変わりました。
現在典拠を探しています。
遅いところ皆様ありがとうございました。勇気がでてきました！
https://ideone.com/ZBuhbz
>>84
StackOverflow のプログラム例は、（通常）ウィンドウがあって、そこから CreateDialog で新しくモードレスダイアログを作るときの作法ですね。
IsDailogMessage() が必要かどうかは、まだよくわかりません。 大雑把に言うと WindowProc に来る前 DefDlgProc が
値を返しちゃうので色が変わらないわけです (多分)。
他にも DefDlgProc が反応するメッセージについては WindowProc ではなく DlgProc で処理する必要があります。
どれがそうか一覧等あるのかは知りませんが。 フルスクリーンでも、色の取得ができるAPIは存在しないのでしょうか？
GetPixelを試みましたが、何故かフルスクリーン対象にすると 常に0を返されます
フルスク色取得が可能なapi、もしくはGetPixelでも出来るのでしたらやり方を教えてください 質問です。
あるソフトがしたUSBの出力を、コンピュータの外部ではなくそのコンピュータ内の他のソフトへリダイレクトすることはできますでしょうか？ >>90
方法１ (「あるソフト」にパッチが可能なら)
CreateFile()/WriteFile()などをフックする。
ただし、これらはKernel32.dllにあるAPIなので通常の方法ではフックできない。
「あるソフト」内のByte列"Kernel32.dll"を(例えば)"Xernel32.dll"に書き換え、
Xernel32.dllを作成・フックする。
方法２
対象デバイス用デバイスドライバと同じAPIを持ち、かつその入出力を「他のソフト」
へ受け渡すAPIを持つデバイスドライバを作成する。
方法３ (本物のUSBデバイスも生かしておくなら)
フィルタードライバーを作成し、そこで「あるソフト」の出力を盗み見る。 kernelにあっても普通にインジェクトでフックできるような・・・ と、書き込んでからプロキシ思い出した。あれ64bitのは作るの面倒すぎだけど32だったらありだな USBハブで物理的にteeすることって可能なんだろうか Window API Hook で検索すればすぐ出てくるけど API のフックはかなり簡単にできる
DLL インジェクション併用で CreateFile / WriteFile をフックするのがいいかもね > ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
テンプレのこれいるか？ってほど簡単にできるしな
1つのページを見るだけではできなくても
いくつかのページの情報を自分なりにまとめたらできるようになる 皆さまありがとうございました
APIフックを試します うーむ、やっとコンパイルできた…
32ビットコードは 32ビットのODBCデータソースしかみないし
64ビットコードは 64ビットのODBCデータソースしかみないのか…
手持ちの excel は 32ビットで、見に行くODBC テーブルは 32 ビット用であったことが混迷に拍車をかけてしまっていた
cigwin の odbcライブラリとしては -lodbc32 でコンパイルしているが、32ビットなのか 64 ビットなのか、いったいどうなっているんだ？！ shell32.dll とか kernel32.dll とかもそうだし、
32→64 ビットではモジュールの名前変わらなかったからね >-lodbc32 でコンパイル
これで実行時に見に行くのが 32 になるか 64 になるかは決まらない
いわんか wow64 を見るのか system32 を見るのかをや WS_POPUPの子ウィンドウって、
親ウィンドウからはGetNextWindow()などのループで辿っていけないものですか？
GW_ENABLEDPOPUPだと、見えているものしか出てこないようです。 見えてる＝enabled popup
ってことなんだな。普通にGW_CHILD使えばいいじゃん >>104
GW_CHILDだとWS_POPUPのやつは出てこないようです 人間は見えるものしか見ない
馬鹿は観たいものしか見ない EnumWindows、EnumChildWindows推奨。 ためしたらまじでgw_childだめなんだなｗ
全ウインドウの親見てくのか >>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セクションにコピーするなりすれば良いんじゃね？ それするとデバイスコンテキストに書き込んだ時に、フォントがビットマップ描画になるから嫌ってんでしょ
そもそもプリンタ自体の解像度とかあるから、ビットマップやめたとこでそれ意味あんのって感じだけどｗ >>161
解像度の高いプリンタではTrueType中のVectorデータ、解像度の低い画面ではTrueType
中のビットマップデータが使われることで、文字幅(→結果的に文字位置)が微妙に違って
しまうのを嫌っているんじゃないかとエスパーした ■ このスレッドは過去ログ倉庫に格納されています
