Win32API質問箱 Build127
>>33 Shell_NotifyIconGetRect CreateFileで返ってきたファイルハンドルを使って、CreateFileでGENERIC_READ/GENERIC_WRITEの どちら(もしくは両方)のアクセスモードが指定されていたかを調べる方法はないでしょうか? 質問を撤回変更します 特定のファイルへの書き込みの際、同タイミングで別プロセスから同じファイルへの書き込みを防ぐため ファイルのロックを行なおうとしましたが、下記のようなコードは間違っていますでしょうか? 実際にはWriteFileでエラーになります HANDLE file; BOOL ret; DWORD wrote; OVERLAPPED ov = {0}; file = CreateFile("test.dat", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); ret = LockFileEx(file, 0, 0, 0xffffffff, 0xffffffff, &ov); ret = WriteFile(file, "aaa", 3, &wrote, 0); ret = UnlockFileEx(file, 0, 0xffffffff, 0xffffffff, &ov); CloseHandle(file); よろしくお願いします 補足します >>103 は複数プロセスで実行しての結果ではなく、単一プロセスで実行した結果です 自プロセスでファイルに書き込むけど、その間は他プロセスで書き込んで欲しくない ということをしたいですですが、競合しているわけでもないの人>>103 ではエラーになってしまいます >>104 FILE_SHARE_*を見てみるといいよ。 やりたいことが伝わっていないようですが、要するにWEBサーバーでよくある アクセスカウンターや掲示板でファイルの読み書きをするにあたって衝突を防ぎたいということです ファイルオープン時にエラーにしてしまうのは本意ではなく、あくまでファイルのロックで制御したいのです ということで、書き込み時はこのようにすれば解決できました。 ret = LockFileEx(file, LOCKFILE_EXCLUSIVE_LOCK, 0, 0xffffffff, 0xffffffff, &ov); 読み込み時は元の ret = LockFileEx(file, 0, 0, 0xffffffff, 0xffffffff, &ov); このようにすれば、複数プロセスで読み込みが競合しても同時アクセスが可能で、書き込みプロセスが発生したときは 意図した通りに排他処理され、後から実行されたプロセスはLockFileExで待機されるようになりました Webサーバの排他処理を、このような実装で提案してくるレベルの会社に仕事を頼むのは危険、とは思った CreateFileが先だとどのみちエラーになる可能性が残るから ミューテックスやイベントオブジェクトで排他制御するなあ Lockなんちゃらは使ったことないわ 俺なら迷わずDBMS使うわ SQLite3 とかならサーバーもいらんし >>109 shareが付いてるからエラーにはならないのでは? WritePrivateProfileString で ini ファイルに書き込むと、たまに「他のプロセスが使用中です。」という例外が発生します。 防止するにはどすればいいでしょうか? 大体にして開いてるのエクスプローラー、アンチウイルス、常駐系だったりするしな MS-DOSでも使うしか 他のプロセスでiniファイルを使っていたとしてもWritePrivateProfileStringで例外なんか出るか? ぐぐった感じ APIそのものは例外を発行しないものの C#のプラットフォーム側がだしてるくさい リストビューを範囲選択しているときの四角形、7や10などでは青い半透明で描画されますが、 APIでこれと同じものを描画することはできるのでしょうか? だから自前で同じものを描画できるかって質問だろ 俺か?俺は知らん! >>119 自分で色などを調べて、直値で半透明の四角形を描いたということですか。 XP以降のエクスプローラーに載っている描画のようなので、 UxThemeのテーマ描画関数にでも含まれているのかと思ったのですが、 外からは呼べないものなのですかね。 >>120 自前じゃなくてAPIでって書いてるやん >>121 正攻法は分からないので、それっぽい色で直接描画した 参考にならなくてスマン ワイもいい方法知りたい DrawThemeBackgroundでリストビュー関係のパーツで描画をすればかなり近そうなんだけど、 本当にそれでいいのか分からなくて面倒でスルーした https://docs.microsoft.com/en-us/windows/win32/controls/parts-and-states こちらのツールも参考にさせてもらってた ttp://dev.onionsoft.net/seed/info.ax?id=1201 で、結局描画そのものは自前になるわなということでやめた >>122 詳しい情報ありがとうございます。 テーマに沿った範囲選択の描画は、提供されていないものなんですかね。 DrawDragRectのような名前のAPIが用意されてよかったのですが。 NamedPipeにおけるPIPE_TYPE_BYTEとPIPE_TYPE_MESSAGEの違いは何なのでしょうか? PIPE_TYPE_BYTEでは書き込み側がWriteFileを何回行ったとしても読み手側はReadFile1度で済み、 PIPE_TYPE_MESSAGEでは書き込み側が行ったWriteFile回数分、読み手側もReadFileがヒットするという理解であってますか? 参考書を一冊読み終わった程度のガチガチの初心者です。 初めて何か簡単なものを作ろうと思ったのですが、ウィンドウのサイズの指定の仕方が良くわかりませんでした。 VisualStudio2022でテンプレートはユニバーサルWindows-C++/Cxです。 どなたかwinndowの大きさの指定の仕方を教えていただければ幸いです。 そもそもどこからプログラムが始まるのかもよくわかっていません。 ・・・質問する場所が間違ってたらすみません。 Win32APIなら MoveWindow あたりかな。 UWPのことは↓の方がいいかもね。 https://mevius.5ch.net/test/read.cgi/tech/1627556967/ なお蛇足だけど 「UWP 将来性」 でGoogle検索してみると、UWPに関しては微妙な評価も少なくなく。 初心者が、あえてUWPを選んで、これから勉強していく・・・というのはどうなんだろう? という気はしないでもない CreateWindow(Ex)のwidth,height引数だろ ウィンドウのサイズの指定の仕方すら載ってない参考書って何なの ウィンドウのサイズはWindowsのプログラムじゃないんだよ うまく言えないけど、それは違うんだよ 自分で制御できてこそプログラミングなのでは ちなUWP ウィンドウサイズでぐぐったら出てくるでしょ UWPなんて儲からないのが決定づいたからMSの投資対象じゃないでしょ 将来性とかじゃないんだよ 終わったの >>126 ありがとうございます。 なんか記事めっちゃ少ないなって思ったんですよ。 c++始めたてで「よし、c++でサーバー作るぞ!!」って思って探したとき以上に 記事がないんですよ。 そもそも将来性が危ぶまれていたのですね。 本当にありがとうございます。 テンプレート何使うのかから考え直します。 Visual studio のテンプレート選びのことなら、最初だけね。 慣れてくると、テンプレートはかえって邪魔だったりするので、空のソリューションから始めるようになるよ。 C++でいくなら(初心者なら、最初はC++よりもCの方がいいかもしれないかな、覚えることが少ないので・・・とは思うけど) (MFC等のクラスライブラリを使わずに)Win32APIだけでゴリゴリ動かすプログラム作成からトライするのがよろしいかと。 いずれにせよWindowsアプリの場合、Win32APIは避けて通れないので、勉強するなら順番的に最初で。 それで不満があったり、学校や仕事なら必要に応じて、趣味なら好みで、他の手法に手を出していくような順番で考えるといいと思われます。 困ったら Google 先生に聞いてみてね、いくらでもサンプルが入手できるから、理解も早まるはず 承知しました。 templateの作成から始めます。 ありがとうございます。 いやー、普通にc#から入っていいとおもうがねぇ。 まっさらな人がこれからcharとwcharとutf8とutf16を ちゃんとデフォルトで言語の標準ライブラリで変換出来ない世界から入るのは遠回り過ぎて、 結局は目的にまったく近づけず挫折するかと。 何でrustの悪口言うの? Microsoftがいつかライブラリを作って提供してくれるはずだよ? >>140 もう使えますよ tps://store.steampowered.com/app/252490/Rust/ >>138 どうも、134です。 インターネットとc++は相性悪いからやめとけって言う話は自分でも どことなくわかっているはずなのになぜかc++に執着してしまっています。 はじめて3か月くらいでしょうか・・・。 boostのサーバーのサンプルコードの一つの中身を片っ端から読んでみようかと思いましたが、 なんかOSどれか調べてるなぁとか、c++のバージョンチェックしてるなぁとか、 このヘッダインクルードしてたらこっちはインクルードしないよーとか、 この関数ちゃんと動くの?とか 実際に知りたかったことにたどり着く前にboostには挫折してしまいましたが、 c++には”まだ”挫折してないです。 ・・・”まだ”なんだよなぁ そんなわけで、DialogBoxの引数なんですが、LRESULTだったり、INT_PTRだったりします。 long以上の整数ポインタだったら何でもよいのでしょうか? ごめんなさい、全然違いました。 DialogBoxの第四引数につかうウィンドウプロシージャの DialogProcの型はlong以上の整数型ポインタなのでしょうか? また、ウィンドウプロシージャって関数であってますよね? 実はクラスでしたとか言わないですよね? DialogBox の第4引数はダイアログプロシージャー(関数)のアドレス値(ポインタ)だね。 Type: DLGPROC A pointer to the dialog box procedure. なお、ダイアログボックスの場合は「ダイアログボックスプロシージャー」といって。 ウィンドウプロシージャーとの共通点は多いけど、同じものではないから、区別して理解する必要があるよ。 DLGPROC と WNDPROC の違いについて調べてみてね >>145 補足含めて有難うございます。 WNDPROCも調べます。 20年以上前まではWin32APIに関する本は山ほどあったけどもうそういう時代じゃないから今すぐ辞めたほうがいいよ 一応20年以上前の知識が今でも通用はするけど知ってたらちょっと得する程度で今は他にもっといい手段があるからね 生まれてくる時代が遅すぎたね 日本語ではね 英語ならPavel Yosifovich氏のWindows 10 System Programming, Part 1 と 2 が有る Pavel Yosifovich氏はインサイドWindowsやWindowsカーネルドライバプログラミングの原著の人だ 誰か翻訳してくれればいいけど、今更Win32本を翻訳したいと思う酔狂な人は居ないだろう… バカ言うなよ Win32APIはずっとこの先生きのこる >>148 おまえは英語を読めないのか?読めたとしてもマイクロソフトは解釈が難しい表現ばかりだから、日本マイクロソフトでもわからないことばかり。 WIN32APIの本なんか読んだ覚えがない Win32.hlpとグーグル検索だけでマスターした もう20年も使ってるが一番長生きでコスパ最強の言語だわ Advanced Windowsだけは読んでたな 15年くらい前から1に書いてあるよね 思えば遠くに来たな… >>150 英語を読めないなんて一言も書いてないだろ >>1 > ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。 これ古いよな APIフックもネット上の情報を組み合わせるだけでできる Advancedと言いつつペゾルト本よりよほどプリミティブな部分を網羅してくれてる書籍よね 邦訳版はもはや入手性悪いけど c++やるんだったら英語は必須なのでしょうか。 マイクロソフトのサイトに載っている説明もほぼほぼ英語ですし・・・、 自分は英語読めないんですけど、なんかもう、最近少しなら読めるようになってきました。 頭痛くなりますけど・・・。 >>156 うん、必須 IEEE14882の規格票が英語だから JIS X3014はバージョンがもはや化石レベルだし アホミスしちまったw - IEEE + ISO/IEC >>155 そもそも原題はAdvancedじゃないしな >>157 やっぱ必須ですかぁ すらすら読めないときついレベルですか? 辞書使ったり、グーグル翻訳使わないときついです。 >>160 俺もそんなもんだよ 決して英語が得意なわけではないので 自分が誤訳してないかのチェックにグーグル翻訳使ってる グーグル翻訳のほうがおかしいこともあるので相互補完だ エディットボックスの中のテキストをGetDlgItemTextでもらってきたのですが(TCHAR*)、 PCSTRに変換する方法がわかりません、便利な関数は用意されていなくて、自分で作ったほうが良いのでしょうか? char*をwchar_t*に変換するのは見つかったのですが、その逆が出来ません。 >>164 GetDlgItemTextA? GetDlgItemTextW? A ならそのまま使えるのでは?W なら https://mevius.5ch.net/test/read.cgi/tech/1434079972/53 ::WideCharToMultiByte DeepL の方が、Google 翻訳よりも高品質 でも最近、Googleも向上した。 DeepLを真似たのかも >>163 DEEPLは翻訳できる回数に制限があると思って使ってなかったです・・・。 使うだけなら制限なかったのですね。 >>165 ありがとうございます。 Aの方使ったら出きるっぽいです。 なんですけど・・・今それを確認しようとしてmbstowcs_sを使ってみたけれど 文字化けが・・・どっかがミスッてるはずなんですけど、しばらくかかりそう。 とりあえずローカルウィンドウで見たらchar変数の中にバッチしがいってたので 当初の目的を解決できました。 こんなことで3時間くらい使ってしまいました。 頭痛い・・・。 文字コードについてはMSがもっとも時間かけて多言語対応してるからMSのルールを守るのが吉。 DeepLをMSが買収して、ドキュメントを全部高品質な日本語で提供してくれ いらんことはせずに昔のMSDNライブラリのように人に翻訳させろ。 文字列を入出力するAPIは末尾Wを使うよう心掛けよ 情報通信研究機構(NICT)も翻訳バンクを運用して、 「みんなの自動翻訳」を、Linux に技術提供している みんなの自動翻訳@TexTra® https://mt-auto-minhon-mlt.ucri.jgn-x.jp/ 漏れは使った事ないけど 文字や文字列の記述は TCHAR(_TCHAR) 系統のマクロで統一するのが旧来からの作法だわね。 最近の Visual Studio の C/C++ はデフォルトで UNICODE,_UNICODE が定義されているので。 APIの末尾にWを付けるというルールは忘れていい気もする。 必要時のみA(やW)を付けて、あとは WideCharToMultiByte、MultiByteToWideChar を使う程度かな TCHARなんかもう10年近く見かけてない。 普通にLとだけ書く。 マルチバイトにする意味ないんだし。 マクロの結果で分岐させるコードだと インテリセンスとかに負荷かかる印象しかないから 気づくとW系のコードで埋まっている UTF8になったら、またマルチバイトに戻るわけではいの? サロゲートペア対応とかで、特定のWin32APIの仕様が混乱してたりして、メリットが無くなってきてるからね。 将来的に ANSI/UTF8 がデフォルトになる可能性も完全には否定できず >>181 1バイト配列だった場合どっちで処理されるかの部分がチーム環境や実行環境に左右されたのて 十数年前から wchar_t で持つようにした 忘れてはいないからこそ忘れてる(OR 分かっていない)人が混ざった時の問題が怖いのよ プラットフォームによってはワイド版のPOSIX関数がなかったりするから微妙だなあ >>172 その「人」が確保出来ないから、放置されてんだよな MSは金は余ってるが、翻訳に関しては全く予算を割くことは無くなった 日本のMSが、無能だらけになったのと関連してるのは間違いない ダイヤルボックスで指定したIPアドレスとポートで作ったソケットからちょっとした文字列を 送ろうとしたんですけどLNK2019エラーが出てしまいます。 VisualStudio2022、c++14、サブシステムはWindows (/SUBSYSTEM:WINDOWS)です。 エラー2019は何となくサブシステムが違うようなイメージで間違っていないでしょうか。 >>188 すみません、前回別の事で同じエラーが出たときに読んだんですけどよくわからなくて マイクロソフト見てもわからないと思ったのですけど、もう一度読み直してみると、 何か忘れてるのかなぁって思ったので、もう少し頑張ってみます。 クリティカルセクションで質問です EnterCriticalSectionでスレッドの排他制御を行うとき、 作成したスレッド間では排他制御できています これを、作成したスレッドではなく呼び出し元のプロセス側で EnterCriticalSectionを実行しても、その間はスレッドの動作は 排他制御されて停止する(待つ)という認識で間違いないでしょうか? 質問の意図が正しく理解できてない可能性がありますが。 A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used only by the threads of a single process. Critical section objects cannot be shared across processes. 要約: 「クリティカル セクション」 オブジェクトはミューテックス オブジェクトと同様な同期を実現しますが、 クリティカル セクション オブジェクトは1つのプロセス内のスレッド間でだけ使えます。 クリティカルセクションオブジェクトは、プロセス間で共有できません。 >>189 "何故" LNK2019が起きているかをぐぐったり他人に投げる前に確認しないと遠回りになりそう >>177 自分で勝手に W つけちゃだめだと思うよ… ちゃんと「windows.h をインクルードする前に」 #define UNICODE しているか確認してね C++11 or later になってからずいぶんと楽になりました… https://mevius.5ch.net/test/read.cgi/tech/1434079972/53 >>191 ありがとうございます > クリティカル セクション オブジェクトは1つのプロセス内のスレッド間でだけ使えます。 > クリティカルセクションオブジェクトは、プロセス間で共有できません。 これは認識しているのですが、この文面を借りれば 「クリティカル セクション オブジェクトは1つのプロセス(メインプロセス・スレッド呼び出し側)と スレッド(メインプロセスから呼び出されたスレッド)間で使えるのかどうか」 ということです よろしくお願いします >>195 複数のスレッドで使えると思いますよ、というか、そのためのクリティカルセクションでしょう? ただ、私もクリティカルセクションの使い方がまずいのか、スタベーションに悩まされたまま放置しているので、断言はできないけど なおちゃんとハンドルを static かヒープに置いていますか?スタック上にハンドルを置いていたら無意味ですよ… >>195 使えます(正しくコーディングされていれば 念のため補足すると、プロセスというのはスレッドの集合であり。 プロセス生成と同時にスタートするスレッドのことを「メインスレッド」と言います。 なので、より正しい言い方としては以下のようになると思われます。 ・メインスレッド ・(メインスレッドと同じプロセスに属する、メインスレッド等で生成された)メインスレッド以外のスレッド これらのスレッド間でクリティカルセクションオブジェクトを共有することができます(排他制御可能です) >>196 ありがとうございます 何か不具合が起きていると言うことではなくて、クリティカルセクションの 仕様について確認しようと思って質問しました 結局、そういうコードを書いて確認しましたが、メインプロセスではEnterCriticalSection が効きませんでした メインプロセスでEnterCriticalSectionを実行すれば、その間スレッドが止まる(その逆もある) ということがもしかして可能なのかなと思った訳です どうも失礼しました >>197 入れ違いになってすみません 使えるとレス頂いたのでプログラムを確認しましたが、これは書き方が 悪かったようで確認になってませんでした レス頂いた内容でとても分かりやすく理解できました どうもありがとうございました >>197 >念のため補足すると、プロセスというのはスレッドの集合であり。 全然説明になってませんよ… 次の質問にちゃんと答えられますか? 「プロレスごとに固有に持つ値はなにでしょうか、最重要な二つ答えなさい」 read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる