Win32API質問箱 Build127

■ このスレッドは過去ログ倉庫に格納されています
2021/12/09(木) 21:32:56.60ID:sYLpmj89
Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build126
https://mevius.5ch.net/test/read.cgi/tech/1588339011/
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2020 Part1 https://mevius.5ch.net/test/read.cgi/tech/1634166667/
Visual Studio 2019 Part7 https://mevius.5ch.net/test/read.cgi/tech/1634178709/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/
2023/03/10(金) 15:18:22.32ID:vOYF1isR
ここで報告できると本気で思ってるのか
おめでてーな
2023/03/10(金) 16:23:50.60ID:hFmnRmK3
どう対処していくかは悩ましいところだろうけど
さしあたり見つかってよかったね
2023/03/10(金) 19:20:08.44ID:iHPjFzG+
MoveWindowなんて基本的なAPIのバグを報告したら、幾らか貰えそうな気がする
ここ見た他の誰かが、もう報告してるかもねw
2023/03/10(金) 19:29:59.85ID:M/1mzCJs
それってバグなのか？
LunaやAeroの影響を受けるような前提があるんじゃないか？
2023/03/10(金) 21:41:52.52ID:ErzT9SJ9
>>513
読み取った後に、wcslen() で文字数を数えると良い。
2023/03/10(金) 21:52:37.44ID:ErzT9SJ9
>>513
結論から言うと「無い」ハズ。
また、最後の引数が int* 型のものは存在していないように見える。
引数の説明欄も、以下の用に4種類のみで、その中に、該当のものは存在していない。

*Parameters
-value
Number to be converted.
-buffer
Output buffer that holds the result of the conversion.
-size
Size of buffer in characters or wide characters.
-radix
The radix or numeric base to use to convert value, which must be in the range 2-36.
2023/03/11(土) 17:44:54.81ID:zdIWJF7w
ウインドウサイズの現象どこかで見たな
たしかリンカオプションの/subsystem:windows,X.YとManifestFileの組み合わせで
APIの挙動が変わるんじゃなかったかな
2023/03/12(日) 18:57:18.20ID:6SOWk3dH
>>537>>538
ありがとう、やっぱりないか
ChatGPTって結構間違った答え出してくるな
2023/03/12(日) 22:11:40.77ID:6PqX/PSJ
自分では調べずにAIに聞いて、その確認も掲示板で他人に聞くスタイル
2023/03/13(月) 07:50:35.89ID:M+cw5TbQ
ChatGPTを何だと思ってるのかｗ
2023/03/13(月) 09:19:48.62ID:0cpyMYUG
ChatGPTもBingも知らないことを知らないと言わずしれっと嘘ついてくるし回答が人の目に触れてなくて識者からのコメントもないからこれを信用するやつは頭湧いてる
Qiitaの方がまだマシレベルでこれに比べるとウィキペディアは神レベル
しかしそのどれも公式ドキュメントとは比べ物にならない糞
2023/03/13(月) 11:17:06.85ID:bF2IN6wD
答えの無い物を探すのが圧倒的に苦手
今までの「自称AI」と何ら変わらん野田
2023/03/13(月) 12:16:45.84ID:ap2u+t1x
道具に振り回される人って…ｗ
2023/03/13(月) 14:09:26.73ID:P3estam5
他のプログラミングを出来るとされるAIでも、小学生でも習う円筒の体積すら、
半径の二乗を直径の二乗に間違えた間違いのコードを答えてきた。
2023/03/13(月) 14:38:05.49ID:tDVvLmFE
今のところは汎用対話AIだからね
対話力に重きを置いてる上に汎用型なので正確性に関してはかなり犠牲にされてる
結局人間もそうだけど専門型が出てきてこそだな
AIアート分野はローカルで各々が専門的に学習させられるからその辺一歩リードしてる
2023/03/13(月) 15:38:27.48ID:4eztEhWJ
>>546
どのAIにどう質問したの？
2023/03/14(火) 12:02:53.79ID:5+uIhtUh
プロセス間で同じファイルを読んだり書いたりしたいのですが、
一方が開いているときにはオープンに失敗させるのではなく、排他制御で待つようにしたいです。
Linuxとかだとflockという関数があるようですが、
Windowsで同じことをやるにはどういう方法になるのでしょうか？
ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。
2023/03/14(火) 14:53:13.19ID:tgsDNUzh
>>549
https://learn.microsoft.com/ja-jp/windows/win32/api/fileapi/nf-fileapi-lockfileex
2023/03/14(火) 15:49:06.52ID:5+uIhtUh
>>550
これって、書き込むときはファイルのサイズは事前にはわからないのですが、
計算してからでないとロックはできないということなのでしょうか。
ファイルの任意の領域というよりは、ファイルそのものをロックしたいのですけど。
2023/03/14(火) 15:55:53.14ID:+K74J7cv
＞ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。

別にそんな必要はないでしょ
ユニーク名＋ファイル名でミューテックスを使えばいい
（※ユニーク名ってのは自分しか使わない名前のことね、例えばGUIDとかだけどそこまでがっちりやる必要もないとは思う）
2023/03/14(火) 16:03:43.56ID:+K74J7cv
>>551
指定できる最大値を設定しておけばいい

＞ ファイルの現在の終了位置を超える領域をロックすることは、エラーではありません。
とあるから事実上ファイルそのものをロックしたのと同じ
2023/03/14(火) 16:27:54.12ID:gMQMDZBf
>プロセス間で同じファイルを読んだり書いたりしたい
問題を無闇に複雑にしてると思わないか
2023/03/14(火) 17:01:38.94ID:iLShrRcK
クライアント・サーバーモデルで、
サーバーだけが書き込めるとか言った制約があった方が良いかも知れません。
556549
垢版 |
2023/03/14(火) 18:23:18.32ID:5+uIhtUh
アドバイスありがとうございます。
あるアプリから別のアプリを起動する際、
コマンドラインでは収まらないような長い情報を渡す必要があり、
ファイルに必要な情報を書いてやりとりするようにしています。
(コマンドラインにはそのファイルのパス名を渡している)

なので、ファイルを作成するアプリと、そのファイルを読み込むアプリがあり、
多重起動などのタイミングによってはアクセスがぶつかる可能性があるので、
このファイルに対する同時アクセスを制御したいという質問でした。
ミューテックスとLockFileExとどちらで実装するか、検討させていただきます。
2023/03/14(火) 18:25:17.73ID:xPBygAZk
>>554
コンパイラとリンカで同じファイルを読んだり書いたりするのも
問題を無闇に複雑にしているのか？
2023/03/14(火) 19:27:43.09ID:LjCdhfB4
>>556
パイプを使えばええんちゃうかな？
2023/03/14(火) 19:36:39.98ID:1SjvDtDO
>>556
それはやり方が違うだろ
GetTempFileNameとか使って一時ファイルを作成すればすむ話
2023/03/14(火) 19:54:35.88ID:5+uIhtUh
>>559
それもやってみたのですが、多重起動などのタイミングによっては、
どうやっても、読み込まれずに放置されるゴミファイルができてしまいます。
テンポラリフォルダなんて気にしなければよいといえばよいのですが。
2023/03/14(火) 21:32:45.60ID:M7rmtaeA
Tempなんか使わずとも末尾PIDの名前でファイルなりを作れば重複起動その時においては名前は被らないし
引数の受け渡しとか程度の話ならオープン失敗したら数秒待って開き直せばいつか開けるだろ
書いてる間はどうせ読めても無意味なんだし
2023/03/14(火) 22:38:01.69ID:rESGMqzG
WM_COPYDATAとかメモリマップドファイルとか
2023/03/14(火) 23:24:45.28ID:u95pjcpT
>>556
>>558と被るけど名前付きパイプがお勧め。
2023/03/15(水) 00:41:23.71ID:q5LCzWGQ
>>560
いや、ゴミファイルが出来る事があり得ないけどね…
その多重起動というのがどういうものか知らんけど、GetTempFileNameで上手く行かないのは、プログラムが悪いと断言できる
ま、これで駄目なら何やっても上手く行かないだろうね
2023/03/15(水) 00:54:04.79ID:mWvoI7Tn
>>548
twitterで流行ってたものを誰かが試した結果を見て気付いた。
2023/03/15(水) 01:02:47.82ID:fvrt0a3X
>>565
それで遊んでみようと思ったのだけど何を使用していたのかわからないなら遊べないな残念
567デフォルトの名無しさん
垢版 |
2023/03/23(木) 01:09:16.30ID:Ao+X9Xng
>>490
正確にはMFCはMS-DOSの開発ライブラリ

だからGUIのWindowsとうまく噛み合わなかった
2023/03/23(木) 06:12:16.80ID:5IP8ya+9
Ruby では普通、外部コマンド・子プロセスの終了を待つから、実行順序は書いた順。
Process.#wait

一方、Kernel.#spawn は、終了を待たない。起動しっ放し

IO にはパイプ、ブロッキング/ノンブロッキング、同期/非同期もある
2023/03/23(木) 07:28:24.76ID:auHr228t
>>567
うそおっしゃい
2023/03/23(木) 08:33:51.91ID:ffpb/acK
>>567
コマンドベースの開発ライブラリならSDKだろ
MFCはGUIが前提のクラスライブラリとアプリケーション構築のプラットフォームをセットにしてWin32APIをラップしたもの
571デフォルトの名無しさん
垢版 |
2023/03/23(木) 11:05:08.93ID:AQHpwrnP
>>567
これはひどい

そんなの関係ねぇ
GUIのWindowsとうまく噛み合わなかったのは
MSVCの開発陣がC++への理解が足りなかったから
2023/03/23(木) 11:15:29.65ID:jVJKu0vi
>>567
お前MFC知らんだろ
2023/03/23(木) 23:45:58.18ID:9ub38u60
久々に清々しい嘘を見た
2023/03/24(金) 01:24:11.23ID:gu0zjHdj
インストーラーの無い野良EXEのAUMID(Application User Model ID)をOSに登録する方法教えてください
575デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:17:49.75ID:ZOqVhNfC
>>570
Microsoft Cがいつからあるのか知らないのか。

MFCにはGUI限定などという定義はない。

そもそもMFCはCUIのライブラリから始まっている。
576デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:20:45.40ID:ZOqVhNfC
>>570
SDKの意味すらわかってねえのか？

あんたのいうMFCは、Windows SDKが扱うWin32APIをさらにラッピングしたMFCのことだ。

あんたの言っていることは滅茶苦茶だ。
577デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:34:38.52ID:ZOqVhNfC
>>571
どうでもいいけど、マイクロソフト内でC言語とC++の混在そのものに悩んでいたのも知らないようだな

マイクロソフトはC言語派、C++派、Windowsを普及させるためにVB流用派と、試行錯誤を繰り返していた時代にMFCが誕生したと思っているなら、時期がずれていてリアルタイムでは知らなかったと言っているようなもの
2023/04/03(月) 15:01:56.44ID:amgtJnTb
MS-DOS の頃ってMSのコンパイラは統合環境だった？
C++ どころか Cコンパイラで コマンドライン上から nmake 叩いてわ
2023/04/03(月) 15:07:52.75ID:lsCbs8KW
B:\>msc hello.c
580デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:10:57.50ID:ZOqVhNfC
ウィキペディアの説明が、Microsoft C 7.0以前の話がないせいで、Microsoft CとVisual C++の区別がついていないのね。

Windows 95、98の時代は、MS-DOS 6.2とWindows 95・98(内部MS-DOS 7.0・7.1)の併存期間で、MFCはMS-DOS 6.2をターゲットとしたものと、Windows 95をターゲットとしたものがある。

まず俗称「MSVC」と呼ばれるものは、Windows 95アプリケーションの開発を意識したもので、マイクロソフト「VC」と言っているあたりからわかるようにC言語でのWindows 95アプリケーションの開発を主としている。

ここでC言語からC++の移行をマイクロソフトはやろうとして、Windows APIがオブジェクト指向ではないところで無理が生じた。

そこでMFCを大幅に強化することでC++でのアプリケーション開発をしてもらおうとしたが、すでにWindows SDKの開発の知識がある開発者は、Windows SDKでのCでもC++よいというのに慣れていて、MFCを使えというのは、それまでの知識と違っており、無駄なクラスライブラリとしか思えなかった。

MFCはWindows 3.1でも影が薄い。マルチタスクではないと言えてしまうWindowsでは、MFCのメリットなどなく、無駄にサイズが大きくて重いコードが作られるため、性能、スペックの低いパソコンではMFCを使う理由がなかった。

MFCはGUIだけで使われるものではないため、CUI環境の開発でも使われている。

MFCどころかWindows 32APIでも、画面がある前提になっているコードを書かないといけないが、実際には画面がないものを作るのにも使われる。

MFC、Visual C++、Windows SDKの話がごっちゃになって、MFCを使うにはVisual C++でMFCを利用して、MFCがWindows SDKとセットだと認識できない点は理解できる。

まあ、ウィキペディアの記事は、根拠不明の創作が多いとわかってないとだまされるよな。
2023/04/03(月) 15:18:50.66ID:lsCbs8KW
Win32がオブジェクト指向ではないって？
ハンドルを使う関数（つまり大半）はオブジェクト指向だと思うが

もしかしてオブジェクト指向とはC++やSmalltalkを使うことだと思ってるのか？
582デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:19:55.66ID:ZOqVhNfC
>>578
統合開発環境と何の関係があるのか？

Windows 95アプリケーションでも、統合開発環境は必須ではない。

画面のデザインのときだけ利用するという使い方が多かった。

Direct Xが普通に使われるようになってからは、統合開発環境は画面ごと吹っ飛ぶので、統合開発環境そのものも動かないこともあるし、統合開発環境を自分が作ったもので壊すことがあるから、Windows 95、98系では、Visual製品に期待しても、Visual統合開発環境とWindows OSのポンコツコンボは、いま思っているより意味をなしていなかったんだよ。
2023/04/03(月) 15:25:54.31ID:amgtJnTb
>>582
MFC=マクロ出力とセットになった統合環境前提って印象だったものでね
リソース周辺のアレ
2023/04/03(月) 15:26:39.12ID:p7oapVPk
>>581
そこで使われるオブジェクトとオブジェクト指向とは関係ない
アセンブラのオブジェクトファイルと同様だ
585デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:28:25.60ID:ZOqVhNfC
>>581
オブジェクト指向設計ではなかったんだよ。

C言語とC++は書き方が少し異なるだけだったので、Windows SDKではC++で書くとオブジェクト指向っぽくなり、C言語で書くとこれでいいのかという書き方で、Windows 95のアプリケーションが作れた。

ここはWindows SDKがオブジェクト指向ではないという理由がある。

APIそのものはオブジェクト指向ではなかったので、オブジェクト指向にするにはMFCを挟むという変なことをすることをしていた人間もいる。

たった数年で変わった話なので、過渡期を知らないと誤解が生じるのはわかる。　
2023/04/03(月) 15:37:01.22ID:lsCbs8KW
>>584
GetObject()なんか多相そのものやん
2023/04/03(月) 15:39:17.90ID:lsCbs8KW
すまん関数名間違えた
SelectObject()だ

GetObject()はオブジェクト指向と手続き型の切り替えだね
2023/04/03(月) 15:56:54.48ID:ORXHufFt
Win32APIの基本構造そのものがイベントドリブンのメッセージ駆動なのでオブジェクト指向を土台にしている
Windowsのマルチタスクはオブジェクト指向で成り立っているだろ
2023/04/03(月) 16:40:18.30ID:lsCbs8KW
そうそう
ウインドウプロシージャのcaseなんか典型的だな
590デフォルトの名無しさん
垢版 |
2023/04/03(月) 16:48:57.33ID:WoF7SnyS
>>575
>そもそもMFCはCUIのライブラリから始まっている。

doubt
2023/04/03(月) 16:51:01.36ID:WoF7SnyS
>>577
でたらめ言うなよ
ボケが始まってるんだな爺さん
ばあさんかも試練が
2023/04/03(月) 16:53:48.85ID:WoF7SnyS
>>580
おまいは Windows 3.1 の知識が抜け落ちておるな
2023/04/03(月) 16:57:17.99ID:WoF7SnyS
>>584
しね
2023/04/03(月) 16:58:53.51ID:WoF7SnyS
>>585
むしろ Win(32以前も)API / Win32API がオブジェクト指向で
MFC の方がオブジェクト指向出来ていなかったんだよ
だから判ってる香具師はみんな MFC は使わなかった
使ってたのは馬鹿だけ
2023/04/03(月) 17:23:19.13ID:aHgelLEB
>>594
APIについてはその通りだが
MFCがOOPでないという主張には
賛成しかねる

下手なところがあるのは俺も認めるが
原理主義者の言いなりである必要はない
2023/04/03(月) 18:20:11.47ID:6F7Nd+C2
MFCとかけて、C＋＋と解きます
その心は、オブジェクト指向ではあるけど、なりきれていない

これでどうでっしゃろ
2023/04/03(月) 18:32:53.99ID:hrmFy8ir
MFCには良い思い出が無いのである
2023/04/03(月) 21:17:54.58ID:NUuZ0KjY
>>580
すげぇ、「ゲームの歴史」？
2023/04/03(月) 21:57:09.76ID:pspdaLIR
GUIの無い単純なアプリならまだしも、それなりのGUIを持つアプリは
MFCを使ったほうが楽にアプリを作れるし、出来たコードも読み易い

確かに最初はMFCは取っ付き難いから、そこで挫折した人が
>>590-594みたいな事を言い出すんだろうなあ
2023/04/03(月) 23:21:42.85ID:6c3bFFXO
>>599
そんなことは無いと思うが
Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし
MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ
実際当時Windowsアプリの仕事を結構やったけどMFCを採用していた所は少なかった
たまたまそういう場所ばかり行ってた可能性はあるがMFC何て使うなよって当時から思ってたよｗ
2023/04/03(月) 23:43:57.61ID:hWVK11qf
でも世の中的に勝利したのはMFCだよね
俺もATL/WTLでいいじゃんとは思ったけど
でかいライブラリも整備されてりゃそれなりに便利だからね仕方ないね

>>578
PersonalWorkBenchってのでFortranやったような気がするんだが
今ググっても全然出てこないな
2023/04/04(火) 00:40:08.89ID:3PHQjkjE
VB→.NET の流れがGUI開発の勝ち組というなら分からなくもないが
MFCは・・・
2023/04/04(火) 06:32:29.81ID:sHU2LbpJ
>>600
＞Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし
WindowProcに case WM_… をだらだら書かなくても済むだけでも大きな利点
＞MFC関連のDLL何かも入れないといけない
ユーザー層やアプリの配布形態に応じて、必要ならMFCをStaticLibraryでリンクしてしまえば良い

>>602
＞VB→.NET の流れ
社内ツールとかならともかく、それこそユーザーにVＢ入れさせるなんて問題外でしょ
大量のデータ処置を行うようなアプリでは処理速度も遅いし
一般販売されてるアプリでVBで作られてるものなんてある？
2023/04/04(火) 07:27:41.42ID:w5B314gc
DLL hell, OCX hell とかVB案件の負の遺産なんじゃなかろうか
2023/04/04(火) 07:35:33.06ID:GxsMOWHT
>>600
>MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ

昔Win32+CだけでDLLの追加が要らないよう頑張ってみたこともあるけど辛かったね。
C++の機能使ってしまうと結局CランタイムDLLが必要になるし。
2023/04/04(火) 10:14:15.35ID:OZYsYc62
>>601
だよな
8086しかりwindowsしかりMFCしかり
技術的に劣っていてもデファクトになると
好むと好まざるに依らずそれ関係の仕事が来る

元々BSD使いだった俺がwindowsに転向したのもメシのため
2023/04/04(火) 11:34:31.40ID:7A3Dl4jZ
DLL便利じゃん
プラグインで機能後付けもこれのおかげだし
2023/04/05(水) 08:56:03.63ID:PNvz4EJs
>>603
BtoCよりBtoBの方が物は多いと思うが
2023/04/05(水) 10:12:22.16ID:xBlgsSX7
金融界隈では未だにVB6が現役だし
MSにしては大成果だったと言える
2023/04/05(水) 15:23:21.24ID:MSpbiXL9
ANAのシステムもミズポと同じ所が造ったんかねぇ
2023/04/05(水) 20:05:04.25ID:WIXvpPAe
C++/WinRTを使ってあげて…
2023/04/18(火) 08:15:18.90ID:F395+kgU
Windows API インデックス
https://learn.microsoft.com/ja-jp/windows/win32/apiindex/windows-api-list

Windows API を使用すると、各バージョンに固有の機能を利用しながら、すべてのバージョンの Windows で正常に実行されるアプリケーションを開発できます。
(これは以前は Win32 API と呼ばれていたことに注意してください。
Windows API という名前は、16 ビット Windows でのルートと 64 ビット Windows でのサポートをより正確に反映しています)。
2023/04/18(火) 08:32:02.79ID:hm8pjCa5
日本語たけど日本語じゃないの
614デフォルトの名無しさん
垢版 |
2023/04/26(水) 20:51:37.42ID:A/LukVPn
Windows11でPrintDlg使って印刷すると1度目は印刷できるけど
2度目はPrintDlg()呼ぶと反応無しになるのはなんか間違ってるのかな
レジストリ弄ってLegacyなダイアログにしとくと印刷できる、あと管理者権限でプログラム実行して
印刷も勝手にLegacyなダイアログになるので印刷できるんだけど

試しに、VC2022で新規プロジェクトで雛形ちょっと弄って試してもやっぱり
2度目のPrintDlg()呼び出しで無反応になっちゃうんだっけど
debuggerで見てもPrintDlg()呼び出しでエラーも何も出てこなくてわからない
2023/04/28(金) 08:28:43.45ID:dRuFEUWm
10で平気なら11のバグだな
窓板の11バグ多すぎワロタスレに報告しとけよ
616デフォルトの名無しさん
垢版 |
2023/04/28(金) 10:51:05.85ID:pksuSfee
閉じてから印刷
2023/04/30(日) 17:14:32.74ID:dQsz62eN
PrintDlgってcomdlg32.dllだよな
comdlg32.dllはバグで有名なやつじゃないか
2023/04/30(日) 19:59:15.10ID:Aup++SJD
Microsoftの直接的な関係者ではなく、TSF (Text Services Framework)の仕組みを知り尽くしている人を募集中。成功報酬あり。
katayama.hirofumi.mz@gmail.com
619デフォルトの名無しさん
垢版 |
2023/04/30(日) 20:06:36.85ID:/hwg+Moy
Firefoxのにゃるるにコンタクトすれば？
あと成功報酬ではなく労働報酬あるいはコンサルタント報酬であるべきだよ
2023/04/30(日) 21:05:43.46ID:Aup++SJD
にゃるるってダレ？
検索しても見つからないよ
621デフォルトの名無しさん
垢版 |
2023/04/30(日) 21:19:58.80ID:8kv4t+8E
書き込めなかった、ローマ字で検索して
にゃるる が地球にいたころ

って言うか自分で勉強検索してたら最も頻繁に出てくる
2023/04/30(日) 21:52:27.43ID:Aup++SJD
ありがと
2023/04/30(日) 21:55:44.21ID:9BNVTRHB
地球にいないのでは無理では？
2023/04/30(日) 22:05:27.13ID:AaWD86jI
報酬が相場より2桁くらい少なそう。
2023/05/02(火) 21:18:50.29ID:koHs32mY
WaitOnAddressってアドレスの値が比較対象と違う値に変化したら自動的に起きるっていう魔法みたいなものではないんだね
呼んだ瞬間に比較対象と違ったら即返る、同じだったら後ほど変わったとしてもWakeByAddress系で通知しなきゃ起きないっていう原始的なイベントと言うほど変わらない感じか
2023/05/03(水) 14:28:28.65ID:wz1HqF7D
directoryなら監視してくれるけど
https://www.youtube.com/watch?v=hKLBPXg8oik
呼んだ瞬間に比較対象と違ったら即返る
同じだったら返らない
っていうのを期待してる？
2023/05/03(水) 20:05:13.46ID:v7V26Uwz
>>626
その挙動は既にWaitOnAddressに組み込まれてる訳だけど
対象アドレスの値が変わったら通知とか無しに自動的に戻ることを期待していた
そうじゃなくてマニュアルでWakeByAddress呼ばなきゃいけないからイベントとそこまで変わらんなぁと
まあハンドル作らずに済む点で手軽ではあるけど
2023/05/03(水) 20:45:04.91ID:Kv12u2jn
8で追加されたAPIは頭悪い
OSが頭悪ければAPIも頭悪いという当然の帰着
2023/05/03(水) 21:24:23.86ID:+bgC2i5O
APIを使うだけならWin32よりWinRTの方が簡単でしょ
2023/05/03(水) 21:27:08.93ID:XU1+7Xhm
本当にそうか？
2023/05/03(水) 21:36:14.09ID:+bgC2i5O
>>630
ウィンドウ表示するコードはこれだけ

#include <windows.h>
#include <winrt/Microsoft.UI.Xaml.h>

using namespace winrt;
using namespace Microsoft::UI::Xaml;

int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)
{
init_apartment();
Application::Start([](auto&&) { Application(); Window window; window.Activate(); });
return 0;
}
2023/05/04(木) 00:16:09.16ID:4Uvo6CUb
ラッパー系は手をつけにくいなあ、MFCやOWLの悪夢が蘇る
便利そうに見えて、覚えることが増えるだけだったり
見えざる制約が足枷になったり、バージョン管理が面倒だったりと
やむを得ない場合は仕方ないけど
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。