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/ 環境も書いたほうがいいですね、Win7 x64でVC++2010 Expressです、rcファイル作って「BLOCKS BITMAP "block.bmp"」と書いてます
ファイル名は間違えていないですし、リンクしてoファイルは作っていないですけど間違っていますか?
最初は自作のbmpファイルでやっていたんですけど、途中から作られたbmpファイルでやろうとして表示されなくなりました
ここにあるblock.bmpというやつです
https://github.com/DQNEO/CppTetris
動画を見てロジックを理解しながら学習したいのですが、なかなか捗らないです
>>460
ごめんなさい、何行目のことかわからないです
>>461
修正しました!
>>462
ありがとうございます 用意されてたbmpでは動く。自作bmpでは動かない。ってことかよ。だとしたら原因ひとつじゃん >>463
imgurにでも自分で作ったbmp上げてみてよ >>463
たぶん表示されてるんだと思う
WM_CREATE内の//debugの下の行を
BitBlt(hMemDC, 0, 0, 24, 24, hBlockDC, 0, 24, SRCCOPY);
にするとどうなる? ちょっと見てみたよ
bmpのIDだけど、BLOCKS と "BLOCKS" は別だからね
BLOCKSは数値に置き換えられてるけどLoadBitmapは文字列の"BLOCKS"で読もうとしてる
初心者の頃はやりがちなやつだな >>469
ありがとうございます、これで表示されました
でもhttp://dqn.sakusakutto.jp/2012/11/cpp_tetris.htmlこの動画とは別の画像が表示されます
動画上では灰色ブロックが出てきているのに、自分の環境では赤色のブロックが出てきている状況です
>>470
動画では「"BLOCKS"」と定義されていたので自分は「TEXT("BLOCKS")」と定義したんですが両者は違うものなのでしょうか? USBメモリなどUSB機器の接続検知をおこないたいのですが、WM_DEVICECHANGEを使用すると
https://qanda.rakuten.ne.jp/qa5211631.html
のようにUSBメモリによってはDBT_DEVICEARRIVALが何度か来てしまいます。
↑のQ&Aにあるように、正常に認識されたときを検出するにはどうすればよいでしょうか? >>472
rcのほうが間違えているということですか?
では「"BLOCKS" BITMAP "block.bmp"」ってことですか? >>473
((PDEV_BROADCAST_HDR)lParam)->dbch_devicetype が全部同じなの? SHAppBarMessage(ABM_QUERYPOS, &abd);が正しい値を取得できない場合どうすればいいですか?
Windows10の設定:システム:ディスプレイ:ディプレイカスタマイズ画面
テキスト、アプリ、その他の項目サイズを変更する
で100%から175%までいろいろ変化させてみると表示位置のずれが発生します。 >>473
デバイスイベントが来たら、タイマーで少し時間が経ってからデバイスをチェックする。
時間が経つ前に次のデバイスイベントが来たら、タイマーをセットしなおしてまた少し時間が経つまで待つ。 タスクトレイの自動的に隠すになっているかを調べる場合どうすればよいですか? 自己解決・・
APPBARDATA appbardata;
appbardata.cbSize = sizeof(APPBARDATA);
appbardata.hWnd = FindWindow(L"Shell_TrayWnd", 0);
if(SHAppBarMessage(ABM_GETSTATE, &appbardata))
{
// 自動的に隠れている
} 最近、win32 はいつまで残るんだろうな、とふと不安になる
.net とか妙なものが蔓延ってるけど。 MS32bitOSが居る限りはなくならないだろ
.netだって内部的にWin32API呼び出しているし ここまで来て過去の莫大な資産を捨てることなんてあるの?
過去のwindowsアプリが新しいwindowsで動かなくなる日が来たら、それはもうwindowsじゃないと思う .NetですらFormsもWPFも放置でUWPに移行させようとしてるし、本音では過去のを全て捨ててUWPに一本化したいんだろう。
現実的には自らの強み(過去の資産)を手放すことになるから、やりたくてもやれないのだろうけど。 > FormsもWPFも放置でUWPに移行
MSって過去にも色々出しては無かったことにしてきたよな・・・
UWPすらどうなることか 新しいものを出してきても、古いOSに対応させないから状況的に使えなくて、
使ってもいいかなと思える状況になった頃には古い技術になっているという悪循環 >>485
windowsが無くなるまでは残るだろうと思ってたが
windowsが無くなりそうだしな Win32APIは過去の莫大な資産であり、過去の莫大な負債でもある WindowsRuntimeを使わないといけなくなって
c++でコーディングし始めたけどかなり面倒くさい。
c++/cx使えっていうことだろうけど。
windows runtimeがwin32apiの代わりになるのかな? しっかし、なんで win32 はあんなに作るのが面倒くさいんだろうな・・・
1〜10まで教える感じではなく、1、10、100、1000まで教えてやっと動く感じ。
その分痒い所に手が届くが。。。
だんだん倦厭されているということは、今の納期!納期!の文化とは合わないんだろうな。 工程の短縮というのもあるけど
「どのアプリケーションでも同じことをしたければ同じ操作をすればいい」と言うのを求めると
同じ操作(同じ動作)をひとつの部品として提供するほうが良い
そういう開発者独自の機能より、一般化された機能や操作性が重要視されるようになったのも一因だと思う >>495
これってまだいろいろ未完成じゃないん?
sdkにも含まれてないし扱いが不鮮明なんだよな。 https://msdn.microsoft.com/en-us/magazine/mt745094
https://msdn.microsoft.com/en-us/magazine/mt745090
C++/CXを置き換えてくのか平行してくのか知らんけど言語プロジェクションを
純C++のヘッダのみで提供するコンセプトなのかしら
ただ肝心の.winmdからヘッダを生成するコンパイラが(まだ)未提供だから
Win2Dみたいな標準に含まれてないランタイムコンポーネントは使えん感じ
ちょっと試してみた感じ/ZWも不要で既存のC++ライブラリとマージしやすそうだし
VS2017+CUの時点で使い物になってて欲しいなあ でも結局どの言語でもAPIインポートするんだよな
意味ないな 痒いところをかくといけないのでかけないようになってます ショートカットの.lnkとかあと特殊なフォルダとかに出る
アイコン右下のやつってなんて名前なんでしょうか? 矢印は左下だろ
アイコンオーバーレイって名称のことかな。ま、どうでもいいや コンピュータの進歩がかなり鈍化してきているし
物理的な限界に直面しつつあるから
128bitは俺の生きている間に来るかどうか
今の段階では個人用途でそれだけのメモリ空間が必要になる使い道が思い浮かばん
それはPCの性能がまだそこに全然達していないから全く思い浮かばんってことなんだけど
そこへ至るまでに何段階もの紆余曲折あるだろうから今の段階で考えるだけ無駄だけどね
世の中も全然変わってるだろうし
それはともかく256テラバイト以上のメモリともなると
それを処理するCPUも相当速くないと意味ないからね
今の状態ですらどちらかというとメモリは余り気味でCPUがボトルネックになってる感じだし
メモリは余ってるけど、データ積んだところでCPUが現実的な時間で処理しきれないっていう
まぁ1万コアぐらいないと256テラバイト以上のメモリは生かしきれないんじゃないかな
その場合メモリ帯域は足りるのかとか考えると、コアごとにキャッシュを山のように積むか
コヒーレンシとか考えるともはやそれも難しく
PS3のCellみたいなプログラミングを強いられるかもしれないな
生きてないと思うけど そういうことを考えると128bitはあまり現実味がないというか
ムーアの法則通りに半導体の性能が上がり続けたとしても
あくまで実時間に対して2倍2倍に増えていくってオーダーだけども
bit数の増え方はもっと激しくて、1bit増えるたびに2倍の空間になるのに
そのbit数自体が2倍2倍に増えて行くわけだから、オーダーが全然違う
8bit→16bit、16bit→32bit、32bit→64bitのように順調にはいかない
どんどん間が長くなっていく
128bitは遠い遠い未来か、もしくは訪れないってことになる >>519
そのころはAIがプログラム書くようになるから心配無いよ >>520
>8bit→16bit、16bit→32bit、32bit→64bitのように順調にはいかない
それはマイクロプロセッサしか見てないだろ。
メインフレームの世界だと、トランジスタ機になったときには
32bitや36bitがすでにできていたから、そこから全く進化してない
ともいえる。 >PS3のCellみたいなプログラミングを強いられるかもしれないな
中国のスパコン1位がそんなアーキティクチャで2位以下にトリプルスコアの圧勝だったな。
この先、性能を追求したらそうならざるを得ないかも。 そんな下の層の違いは上には影響しないから俺には関係ないな ボトルネックといえばフロントサイドバスとストレージ 一桁二桁の加減乗除なら良いが、128ビットフルに使う計算だと、紙の幅越えないかなw SSE2使ってるとどうやって128bit使おうかばかり考える なに見栄張ってるんだよ
お前のは a bit (=ちょっと) だろ >>531
そりゃcharを16個詰め込んだりするだろ 質問お願いします。
QueryPerformanceFrequency
で得た値は実行ごとに変わったりするから毎回計測しないと駄目ですか? どんな理由から毎回計測しないようにしたいんだ?それによる QueryPerformanceFrequencyの値がプログラムを終了するまで一定なら
1回しかこれを実行したくないし変わるなら一回時間を計測するごとにこれを実行したいです ハイバーネーションみたいなのとかVMとか組み合わさるとどうなるかわかんないけどそういうことになってるね 俺は使うたびに毎回読んでるわ
あえてそうしない意味もないから すみません、教えてください。
Borland BCC でC/Cppを勉強しているのですが、
CreateWindow( "EDIT", "あああああ", ....
にすると、あああああ の部分が文字化けして ,,,, と表示されてしまいます。
CreateWindow( "STATIC", "あああああ", ...
だと問題なく表示されます。
どうか教えてください、宜しくお願いします。 >>544
BCCはよくわかんけど、パラメーターが変とかじゃね?あと考えられるのはUNICODEとか?
このコードは RAD Studio10.1 BerlinとVS2015/2017で動くことは確認済み
HINSTANCE hInst;HWND hEdit,hStatic;
HWND hWnd= Handle; // BCBとか用
hInst=GetModuleHandle(0);
hEdit = CreateWindow(TEXT("EDIT") , TEXT("あああ") ,WS_CHILD | WS_VISIBLE | ES_LEFT,0 , 0 , 400 , 20 , hWnd , 0 ,hInst , NULL);
hStatic = CreateWindow(TEXT("STATIC") , TEXT("あああ") ,WS_CHILD | WS_VISIBLE | ES_LEFT ,0 , 20 , 400 , 20 ,hWnd , 0 ,hInst , NULL); すみません、お手数をおかけします。
// あああああ が表示される
CreateWindow( "STATIC",
"あああああ", WS_CHILD | WS_VISIBLE | SS_CENTER,
x, y, w, h,
hGrp1, (HMENU)ID_TEXT1, hInst, NULL );
// あああああ が表示されず ,,,,, となる
CreateWindow( "EDIT",
"あああああ", WS_CHILD | WS_VISIBLE | SS_CENTER,
x, y+50, w, h,
hGrp1, (HMENU)ID_TEXT2, hInst, NULL );
hGrp1 はグループボックスです。 "EDIT"にはSS_CENTERは使えないよ。EDITにはES_...スタイルを使う。 >>547
とりあえずコントロール毎に指定フラグが違う事を指摘しておく >>547
マルチバイト文字列が上手くいかないなら"AAAA"のようにシングルバイト文字列で試してみればいいじゃないか。 >>547
WM_SETFONTを使って、フォントを関連付けしてみたらどうだい? SS_CENTERがES_ENDELIPSISとして解釈されたんだろうな。
【今日の教訓】
EDITコントロールには、ES_で始まるスタイルを使え。SS_はEDITには使うな。 ごめん、ES_ENDELIPSISというスタイルはなかった。SS_CENTERの代わりにES_CENTERを指定すればいい。 そりゃ特定のコントロールに対するものだからさ。
あとSS_CENTERもES_CENTERも winuser.h で 0x01L と定義されている。
例えば共通の定義 XX_CENTER 0x01L としていた場合、
EDITコントロールの仕様変更でXX_CENTER 0x02L としたくても
STATICコントロールで同じ意義を使っているため変えることが出来ないだろ。
もし定義を変えた場合、STATICコントロールで0x02L というのは別の意味を持っている(かもしれない)ので動作がおかしくなる。
だから意味は同じでも“値”としては別のものとして扱う(定義する)。 じゃー将来SS_CENTERが別の値に変更されても安心だね 変えたらひどいことになるけどなw
本音と建前みたいなもんでCの欠点だな。後発言語はそういうとこカバーされてる(のもある) モーダルダイアログをメインの親とし、その後動的にサブメニューを表示する仕組みがあります。
サブメニュー表示中も親側の操作を可能とするため、サブメニューはモードレスとしていますが、
TABなどのキー入力が効きません。
辛うじて、初期フォーカスがあるボタンのみスペースキーを受け付けます。
マウス操作は問題ありません。
原因としてはサブメニューのキー処理をする IsDialogMessage を含むメッセージループが必要
なんだろうと思いますが、こういう場合の定石というのはあるのでしょうか?
思い付く実装は以下2パターンです。
その1
親もモードレスとし、親のメッセージループ中にサブメニューのメッセージも処理する仕組みを入れる。
その2
サブメニュー表示後に別スレッドを立ち上げ、そこでサブメニューのメッセージループを回す。
普通はこうだよ。とか他の方法などありましたらお願いします。 ちょっと語弊がありましたので訂正です。
ここで言う「サブメニュー」とは、CreateMenu などで作られる一般的に言うメニューではなく、
単なるポップアップスタイルのタイトルなしダイアログのことです。
CreateDialog で画面を作っています。
勝手に言葉を作ってすみません。 2つウインドウがあって、1つはメインウインドウ、もう1つはメニューウインドウ
メインウインドウにキーフォーカスがあるとメニューウインドウでキー操作できず、メニューウインドウにフォーカスがあるとメインウインドウでキー操作できない
メッセージを適宜流せばいいんじゃないか? フォーカスはそれがあるウィンドウで処理できるようなUIを考えています。
ユーザーがメインウィンドウにフォーカスを(マウスなどで)移せば、
以降はそのウィンドウでキーボード操作ができればいいです。その逆も然り。
適宜メッセージを流すにしても、結局どこでメッセージループを回すかという
話になるのではと思うのですが、違うのでしょうか? ■ このスレッドは過去ログ倉庫に格納されています