Win32API質問箱 Build125
レス数が1000を超えています。これ以上書き込みはできません。
このテンプレって誰かが作ったのかスレでまとめられたのかどっちだろ。
>>2-4がスレ番変わってないくらい進行遅いか過疎ってるんで、要らない気もする。（更新チェック面倒） 特に関連性ないスレばかりだな
これくらい興味もてよっていうチョイスなの？ｗ ねた
【セキュリティ】Intel製CPUに見つかった新たな脆弱性「SPOILER」はまたもシリコンレベルでの再設計による修正が必要
https://asahi.5ch.net/test/read.cgi/newsplus/1551833609/ マウスエミュレートなどを使わずにドラッグ&ドロップを実現するにはどうしたらよいでしょうか。
具体的には、ユーザーはマウス操作を邪魔されることなく、バックグラウンド・アプリでドラッグ&ドロップしたいです。 >>13
DROPFILES構造体とHGLOBALとPostMessage(WM_DROPFILES)を使えばできるはず。 >>14
確かにその方法で、メモ帳やサクラエディタにはでドロップできるのですが、Visual Studio 2017やMozilla Firefoxにはドロップできないようです。
トップウィンドウのウィンドウハンドルを指定しているのですが、WM_DROPFILEを送るウィンドウハンドルの問題なのか、それとも違う要因なのか。 >>15
WS_EX_ACCEPTFILES拡張スタイルをチェックしながら、WindowFromPoint、GetParent、EnumChildWindowsなどでたどっていく。
ウィンドウの構造は、Spy++で分かるはず。 >>16
何をたどるのですか？
もう少し汎用的な例に変えます。
エクスプローラーで開かれたフォルダにファイルをドロップするにはどうすればいいでしょうか。
Windows10で試しているのですが、どなたかドロップ出来た方いらっしゃいますか？ たどるは、ウィンドウハンドル。ハンドルなくば話にならぬ。
FindWindow, FindWindowEx、EnumWindowsでまずはターゲットのウィンドウハンドルを取得する。 >>18
たびたび回答していただくのは有難いのですが、失礼ながら徒労に思えます。
フォルダへのファイルドロップの成功事例はご存知でしょうか？ ちなみに徒労について書いておくと、
Visual Studio 2017とexplorer.exe をSpy++で調べたところ、WS_EX_ACCEPTFILESを持つウィンドウはひとつもなし。 >>22
マウスエミュレートなしでどうかひとつ m(_ _)m そういうのはソフトによってできるできないどうしてもあるよ
ひとことでD&Dいっても実装方法色々あるからね
汎用的なの考えずにターゲット絞れ CreateProcessをUTF-8で実行したいんですが何か良い方法ありませんでしょうか >>26
呼び出し側がコードページを変えるなどしようとも、実行される側のプログラムは引数を規定コードページで受け取るので無意味。 utf8ってかunicode使いたいってだけでしょ
CreateProcessWで >>26
文字コード変換を挟んだラッパー関数を作るんではダメかな >>27
cp932が返ってきました
>>28
調べてみます(_ _)
>>29
パイプして出力を読んでそれをcp932からutf8に変換するということですよね 932から変換したらその分おちるから意味ないでしょ
SetConsoleOutputCPの話か？ >>26
何をUTF-8にしたいの？
CreateProcessに関連する文字列は
(1) 実行ファイルのPath
(2) コマンドラインパラメータ
(3) 環境変数
(4) カレントディレクトリ
(1)(3)(4)はCreateProcessA/CreatePeocessWでMBCSかUNICODEで渡す
必要があり、UTF-8では渡せない。(UTF8をUNICODEに変換して渡す)
(2)は受け取る側(実行されるアプリ側)しだいだねえ。 shell lightweight library, 略してshlwapiには便利な関数がたくさん詰まってるよ。のぞいてみてね。 CP_UTF8とMultiByteToWideChar関数を使う。 >>33
CreateProcessにPythonとスクリプトを渡して実行、その出力をUTF-8で得たいんですが
例えば
python hoge.py
というコマンドラインを実行させるということなんですが
hoge.pyの出力はUTF-8になっているんですがCreateProcessを通すと出力がcp932になってしまうんです setdefaultencoding
http://www.wakayama-u.ac.jp/~kazama/lab/python/i18n.html すみません、Pythonのスクリプトに
sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')
を追加したら期待する出力を得られました
Win32API 関連の問題ではなかったみたいです
sys.stdout.encoding が cp932 になっていたのが原因だったみたいです
Windows環境のPythonだと標準で cp932 になるんですね
>>38-39
無事解決できました
ありがとうございました 漏れは、Ruby から、Powershell のGet-Clipboard, Set-Clipboard や、
clip コマンドを呼び出して、処理する
Ruby内では、UTF-8 で処理するから、
CP932から、UTF-8へ変換して処理して、
UTF-8から、CP932へ戻す
入力 : Windows(CP932) → 処理 : Ruby(UTF-8) → 出力 : Windows(CP932)
# クリップボード内の複数行文字列の、各行の先頭・末尾から、
# 連続する空白類を除去して、クリップボードに入れる
str = `powershell Get-Clipboard`
str.encode! Encoding::UTF_8, Encoding::CP932 # UTF_8 へ変換
ary = str.each_line.map( &:strip ) # 連続する空白類を除去する
IO.popen( 'clip', 'w:cp932' ) do | clip | # CP932 へ戻す
clip.print( ary.join "\n" )
end >>41
どこにでも沸いて出てくるんだな。
消えろ。 >>41
処理中にクリップボードが使われたらどうなるの 未だ、Win32apiって使われてるんだな。
自分はこの前古いwince向けソフトの機能追加のために
久しぶりに使った。
ce向けは仕様が若干簡素化されてたりしても少しはまった。後、開発環境(evc++)の軽さにも驚いた 表現が不適切だった。
現在のアプリ開発は.netが主体なので、c言語でwinアプリを書く機会って減ってるのかなと思って。
※.netだと便利なライブラリが準備されてるので、そもそも
win32api を使う機会も減るのかと >>46
便利なのとなんでも出来るかって云うのはイコールではないからね
手段は多く持っていたほうが良い .netの比率増えてきたけど、まだまだ.すくないなー .NET じたいがWin32APIなどライブラリのラッパーですよね？ Win32APIのラッパーはMFCと言うイメージ。
.netは.netと言うVMのAPIかな。
元がDelphiのVCLだからラッパーと言うのもおこがましい、高度に抽象化されたライブラリだし。 .NETは型システムを含めたランタイムそのものを内包しているので単なるライブラリではないだろ 極論かもしれないけど.netは単体のアプリケーションでMSの提供する
APIでWindowsの画面表示を書き換えるための環境なんだよね
なんでロジックと画面の書き換え以外の低レベルアクセスとかしようと
するとどうしてもWin32APIが必須になるのでいまだに「DllImport」みたいな
APIを残しておかないといかないわけで
低レベルはC++で書いてライブラリ化すればってのが本道なんだろうけど
結局「DllImport」するだけなんで、だったら直接Win32API呼んだほうが
早いし簡単だしってことでWin32APIから離れられないってことで
JavaもそうだけどマルチプラットフォームのためのVMで動作する言語は
低レベルアクセスを実装しちゃうとプラットフォームの違いを吸収できない
のでライブラリ参照みたいな仕組みで実装するしかないんだけどね 44だけど、.netやjavaのようなvmが昔から普及してたらと思うよ。昨年からwinceからlinuxへのアプリ移植行ったけど、できるだけ元コードに手をいれたくなかったので、win32apiやmfcと同じ動きをする関数を作って対応した。
今はlinuxで.netも動くようなので、c#で書いてたらこんな開発しなくても済んだのにと思ったりする。
当時のCPUではvmアプリはまともに動かなかったかもしれないけど。 今だって、例えばJavaならJNIゴリゴリだったりして
本気で使うアプリの移植性がいいとは思えないがなあ
安い値段で拾ってこれるプログラマが触る部分にはちょうど良いのだろうが 移植前のの開発者や仕様決める奴の能力次第だな
後々のこと考えてた奴のを移植するのは言語関係なく移植楽 >>56
その通りだと思う。
ただ、vm上で動くアプリはプラットフォーム依存部をvmが吸収してくれるので、そこの部分の移植は不要。 今回残念なのはシステム改修の需要は増えたけど
その場しのぎのパッチみたいな作業だけが増えたこと
どこも次の次の元号やその先の元号変更時に
「今回みたいに一ヶ月も期間置かなくても即日変更可能なシステムにしておこう」
って方向で改修する流れにならなかった
これはせっかくの天皇陛下の御英断と改元リハーサルにも関わらず
将来に禍根を遺す結果となってしまった ウインドウを閉じさせるのは簡単だけど
例えばWin10の「YourPhone.exe」など、プロセスがキモいから終了させたいという場合
スナップショットでプロセスIDまでは掴んでいるのだけど
そこからプロセスを終了させるには、子プロセスを調べたりして面倒そうですか？ ＞天皇陛下の御英断
ちょーキモい野郎だ
あんな寄生虫は即刻処刑すべきだ
特別会計や本来不要な「国債」でどんだけ搾取されてると思ってるんだ >>63
在日特権で寄生してるどっかの民族にそれ言えよ >>62
使わないんだったら最初から起動しなければいい ＞在日特権で寄生してるどっかの民族にそれ言えよ
天皇が同和朝鮮人に治外法権を与えるから
同和朝鮮人は女の子を強姦して臓器を抜き出して病院から２千万円ゲットだ
警察に捕まっても天皇同和だと言えば解放される
問題は朝鮮人天皇にあると思いませんか？ >>66
ほとんどの人はもう免疫が出来てるぜ。あきらめろ。 「IEコンポーネントでダウンロードマネージャを実装したい」 https://t.co/PW5Ew1rmEj #teratail 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01) OSの日付表示を元号表示にしてない非国民なんているの？ 天皇制いらね。
即位したから10連休？恩赦？
バカじゃねーの
どこの後進国だよw ぼくも明日から5/6まで休みますが上級国民にカテゴライズして貰えるのですかね？(純真) >>71
極東の後進国ですよ。文明の到着が一番遅れるんです。 業務でエクスプローラでファイルリストを見る時は、曜日も表示できるようにすると便利だということに最近になって気づいた。
頭を慣らすために西暦ではなく元号の年月日時表示形式にするのは、プロとしての心得でしょ。 頭を慣らすために曜日非表示は最低限だろ。日付非表示までいけよ。プロとしての心構えが足りないぞ 元号＆曜日つきの日付設定の件は、ファイルブラウザ限定の話ではない。メールブラウザとかも。 曜日表示はWin32の守備範囲だぜ。スレ違いではない。 メーラーのThunderbirdだと、OSで元号表示にしたら「西暦2019年4月25日(木) 12:14」のように表示され、
元号表示ってそういう意味じゃないだろ、と静かなツッコミを楽しむことができるぞ。 >>81
日本では「AD」を「西暦」と呼んでいるから違和感があるだけ。「AD」は「アンノドミニ」という名の元号。 EnumDateFormatsExEx() で取得できる書式を使っても、GetDateFormatEx()では「西暦」を含む文字列は出力されない。
となるとMozilla Thunderbirdは書式に含まれるggを独自に「西暦」という文字列に置換していると予想できる。 >>83
紀元前を意識してるんだっけ？
Windowsがそんな昔を想定して作られているとは思えぬ。 >>82
アホか、元号について調べてから出直してこいよ
ちなみに西暦は紀元な SYSTEMTIME structure
https://docs.microsoft.com/en-us/windows/desktop/api/minwinbase/ns-minwinbase-systemtime
The year. The valid values for this member are 1601 through 30827. >>86
西暦はそういう年号なんだよ。まともに調べてものを言えよ！ >>89
元号と年号の区別もつかないアホは黙っとけw ほんとアホばっかｗ
西暦xxxx年って書き方は普通だよ
平成は元号であり年号でもある
西暦は年号だけど元号ではない
>>81は「年号表示」という訳にしとくのがいい 60 名前：名無しさん＠１周年[sage] 投稿日：2019/04/26(金) 17:07:27.22 ID:ZP74hWkE0
access2016は対応済みだな、表示をgee/mm/ddにしてH31/05/01と入力するとR01/05/01と変換してくれる。
ちなみに2007だとR01/05/01と入力するとご丁寧にもH31/05/01と変換してくれるw
そこまでやるならきちんと対応しろと言いたい。 大規模開発の時に役立つ
・モジュール間の結合を下げて、作業分担・デバック・例外処理の範囲を明確化できる
・継承の型指定で、質がピンキリなプログラマーたちの実装を縛れる
・オブジェクト指向の思想は直感的でわかりやすいから、頭の弱いPGにも理解させやすい
特にプログラマーの質が低い時は、javaを使わないと大規模開発できない >>92
まだ改元された訳じゃないからそれで正しい
5/1 以降は動作が変わるはず >>92
運転免許の表記がH35だが、勝手にRに変えられても困る S64年からH1年 と書くようになった時、たぶんあまり違和感を感じなかったと思うが
R１年ってなんか妙だな
R1とか書かれたら国一と勘違いしそう 自作アプリで、他アプリがアクティブなときでもマウスイベントを監視するために、
SetWindowsHookEx(WH_MOUSE_LL, HookProc, hmod, 0);
とすると、確かにHookProcが呼ばれますが、
アクティブな他アプリが管理者特権あり(タスクマネージャとか)だと呼ばれません。
その場合でも、自作アプリが管理者特権ありで実行されていれば、
ちゃんとHookProcが呼ばれます。
自作アプリを管理者特権なしの通常の実行時でも、
タスクマネージャとかがアクティブなときのマウスイベントを監視するには
どうすればいいのでしょうか？
フリーソフトのX-Mouse Button Controlとか、StrokesPlusとか、
ではできているようなので、なにかしら方法はあると思うのですが。
(win10, 64bit) 自分より上位の権限で動作してるプログラムの動作を盗めちゃったら
特権の意味がないじゃん そういう場合setupでSYSTEMで動くサービスをこっそり仕込んどくんだよ フックを仕込むプロセスを管理者権限で起動すればいいだけでは こっそり悪いことをしたいのに、それでは困るんです！！
詳しい人だけレスしてください！！ マウスジェスチャツールの類って、
管理者権限アプリがアクティブな時は動作しません、
ってわけにはいかず、
実際、例示したソフトは管理者権限なくても
ちゃんと動作してて、これって一体どうやって実現してるんだろう？
という純粋な興味と、
できれば管理者権限はあまり濫用したくないのと。 たとえばUACの画面でも動いてるってことは管理者特権で動いてるってことだよ >>103
すでに試しているかもしれないけど、同じようにキーフックとマウスフックする
プログラムで試したら、同じようにタスクマネージャがアクティブウィンドウに
なっていると反応しなくなったので、アプリ自体を管理者権限で起動したら
動作するようになったよ
なので、手作業で管理者権限で実行しなくてもうまく動作するアプリは内部で
権限の取得を行っているんだと思うけど
試していないので分からないけど「"windows10" "管理者権限" 取得 api」
あたりでぐぐるとヒントあるかも エディタボックスの EM_GETFILELINE について教えろ下さい。 指定したファイル（または論理）行のテキストを取得します（テキストの折り返し区切り文字は無視されます）。このマクロを使用するか、EM_GETFILELINEメッセージを明示的に送信することができます。 改元を契機に、OSの日付表示を「和暦」にすることをお勧めしたい。
エクスプローラで日付に曜日をつけられるのは「和暦」だけ。
ファイル一覧の更新日時に曜日が表示されていると便利だよ。 パソコン初心者スレで言ってろよｗ
曜日が欲しいのにないなら自分で表示すればいいだろ そもそも日付設定を西暦にすると短い書式で曜日表示できないWindows10の仕様は不便だと思うけど、どうよ？ タスクバーは非表示にしてるからそいつに頼ることがない >>111
設定→時刻と言語→地域→日付、時刻、地域の追加設定→日付、時刻、または数値の形式の変更→追加の設定→日付タブ→短い形式をyyyy/MM/dd '('ddd')'にする ㍾㍽㍼と比べて
令和の合字は横幅が広く作られているようだ
バグ出るソフト多数 その程度で誤動作するようなソフトはもとからバグまみれなんじゃないか？ これすごいよ。試してみてね。
【ソフト名】vista2xp
【URL】http://github.com/katahiromz/vista2xp
【説明】Vista/7/10向けのアプリをXP向けアプリに変換できるかもしれないソフト >>116
最近気にも留めてかなかったけど
とうとうスパム業者のレベルにまで落ちぶれたんだな片山 archive.2ch-ranking.net/tech/1407006123.html#97
ここにXPで動かしたいという要望があったから書き込んだのに。。。 マニフェストで、uiAccess='true'とし、オレオレ証明書で署名すると、
自アプリに管理者権限がなくても、
管理者権限ありの他アプリがアクティブな時にもマウスのフックが効くようになりました。
(結果的にはスレ違いだったか？) リストコントロールをLVS_OWNERDATAで仮想リストビューとして使う際、
LVS_EX_FULLROWSELECTを付けていないと、
マウスで先頭からガーっと範囲選択を広げながらスクロールさせてるときに
どんどん重くなっていくんだけど、これは防ぎようがないんですかね。
LVS_EX_FULLROWSELECTを付けるとそんなことになはならないです。
確かに、LVS_EX_FULLROWSELECTを付けてないときは、
選択範囲内のY座標に含まれるすべてのアイテムに対して、
先頭カラムの文字の長さを見なければいけないのはわかるんだけど。 やり方かえろ
そんなインターフェースが万一速くなってもだれも喜ばない 元号の構造体が「明治、大正、昭和、平成」の4択しか無かったとかいうアホな仕様もアホかも知れないが（Windows31の頃か？）
改元が決まってから今年に入るまで完全放置プレイだったってのも何だかなあ
↓
その構造体の修正も、その単体パッチに含まれてるのよ >>125
完全に横で関係ない話だけど、仮想リストビューって名称が取っつきにくくて分かりにくいと思ってた。
LVS_OWNERDATAって名前付けてくれてマジありがとうだった思い出。 >>126
ユーザーから指摘された挙動です。
マウスで範囲選択できるリストビューというのは普通だし、
項目が多いから仮想リストにするのも別に間違ってないはずだし、
その二つを組み合わせたら駄目という暗黙ルールなんですかね。 >>129
2個目～5個目を選択するとして
2個目を選択した状態で5個目をShift+クリックじゃダメなん？ Edge、FirefoxなどWebブラウザのJavascriptが新元号の令和に対応してない。
なぜかIE11は令和に対応済み。 >>130
もちろんその操作は理解していますが、回避方法の質問ではなく、
ユーザーが範囲選択しただけで処理が極端に重くなるというのが疑問でした。
処理が遅くならないようにするためのLVS_OWNERDATAだと思ってたので。 LVN_GETDISPINFOの処理にミスはないの？
LVS_OWNERDATAとLVS_EX_FULLROWSELECTどっちも使わないときの
処理速度も遅いんなら仕様だと思うけどね >>133
以下のような、連番を表示するだけの簡単なテストでも発生します。
MFCのコードだけど、結局はAPIなので原理は同じはず。
IDC_LIST1もIDC_LIST2も、ダイアログエディタ上で置いたリストコントロールで、
リスト関連のスタイルはLVS_OWNERDATAを付けただけ。
IDC_LIST1のほうはマウスで選択範囲を広げていくとどんどん遅くなります。
LVS_EX_FULLROWSELECTを付けたIDC_LIST2のほうは全く遅くなりません。
m_list1.SetExtendedStyle(m_list1.GetExtendedStyle() | LVS_EX_DOUBLEBUFFER);
m_list1.InsertColumn(0, _T("カラム"), LVCFMT_LEFT, 100);
m_list1.SetItemCountEx(10000);
m_list2.SetExtendedStyle(m_list2.GetExtendedStyle() | LVS_EX_DOUBLEBUFFER | LVS_EX_FULLROWSELECT);
m_list2.InsertColumn(0, _T("カラム"), LVCFMT_LEFT, 100);
m_list2.SetItemCountEx(10000);
LVN_GETDISPINFOハンドラ
{
NMLVDISPINFO *pDispInfo = reinterpret_cast<NMLVDISPINFO*>(pNMHDR);
LVITEM* pItem = &pDispInfo->item;
if (pItem->mask & LVIF_TEXT) {
CString strItem;
strItem.Format(_T("%d"), pItem->iItem);
_tcsncpy_s(pItem->pszText, pItem->cchTextMax, strItem, _TRUNCATE);
}
*pResult = 0;
} デスクトップで右クリメニューの「ディスプレイ設定」→
ディスプレイ詳細設定→
ディスプレイ1のアダプターのプロパティを表示します→
専用ビデオメモリ: 128MB
↑この値を取得したいんですけど方法分る人居ますか？
Win32APIで無理なら他の方法でもいいので。 誰も消防車を呼んでいない精神に基づいてフィードバックしといたよ コモンコントロールは作りもAPIも割といい加減だよ
不具合の原因がコレだったみたいなの多すぎ >>139
LVM_GETITEMCOUNT を直で使うしかなさそうだな
ラッパー関数がある場合はSendMessageは使うなというくせに無茶ぬかす連中だ ドキュメントが間違っているだけ。
マクロはintを返すように正しく定義されている。
=== CommCtrl.h ===
#define LVM_GETITEMCOUNT (LVM_FIRST + 4)
#define ListView_GetItemCount(hwnd) (int)SNDMSG((hwnd), LVM_GETITEMCOUNT, 0, 0L) >>139
> マクロ関数だと全て無条件で戻り値voidになってるっぽいな
何かで自動生成してるんじゃね
IDEなら>>145の様に内容確認するのも容易だからたいした問題じゃないわな
まあMSしっかりしろよとは思うが >ラッパー関数がある場合はSendMessageは使うなというくせに
言ってることとやってる事が違うっていう意味かと
>>144
アスペか >>147
？？？
だからドキュメントのシグネチャが間違ってるだけで「マクロの方を使えと」いう方針とやってることが違うというわけじゃねえだろ
「LVM_GETITEMCOUNTを使うしかない」とか言ってる時点で実際の定義もそうなってると勘違いしてるからなｗ
ちなみにmsdnのドキュメントは合ってる（https://msdn.microsoft.com/en-us/windows/desktop/bb774957）
MSも雑だしアプリ開発者の方も雑だなってだけの話 SendMessage()でもマクロでもメンバ関数でもどれでもいいけど、「GETITEMCOUNT」で大小文字区別なしでキーワード検索できるようにしておくことが重要でしょ。
各開発環境に付属するメソッド参照だけだと追跡しきれないので結局、原始的なキーワード検索になる。 >>147
> 直で使うしかなさそう
> ラッパー関数
何を言ってるんだ 教祖様に批判的な意見には無差別な敵意にかられる信者がここにはいるようだね >>153
ListView_GetItemCountの返却値がvoidというmsdnの公式発表を批判しているのだが
何がどう的外れとおまえさんはぬかすんだ？
typoなら訂正すべきところ、それすら行われていないんだが
おまえさんとこの自転車操業を自転車操業だから大目に見ろという論法を一般化しようってか？ 横からだけど…
> 何がどう的外れとおまえさんはぬかすんだ？
>>143 > LVM_GETITEMCOUNT を直で使うしかなさそうだな >>155
それがどう的外れなんだ？ msしっかりしろと、あんたが言ったんだが >>154
だから引用してるやん
> LVM_GETITEMCOUNT を直で使うしかなさそうだな
> ラッパー関数がある場合はSendMessageは使うなというくせに
ListView_GetItemCountを使ってもSendMessageにLVM_GETITEMCOUNTを指定しても
全く同じって事が理解できていないから>>143みたいな発言になるんだろ >>156
ドキュメントの話と実際の実装の話の区別もついてないから指摘されてる
>>148がはっきり書いてるだろ
皮肉だと言い訳するならそれでもいいけどw LVM系ってSendMessageで構造体のポインタ渡すマンだから
外部プロセスから弄ろうとすると面倒すぎる >>154
MSのいつもの言い訳「仕様です」
つまりvoidのtypoは仕様だ >>158
>>143 を擁護するつもりは無いが
>ListView_GetItemCountを使ってもSendMessageにLVM_GETITEMCOUNT
同じ機能だということも承知の上で
「LVM_GETITEMCOUNT を直で使うしかなさそうだな」→オレオレ関数を造りたいのにオレには造らせない
「ラッパー関数がある場合はSendMessageは使うなというくせに」→MS自身はSNDMSGを使ってる
論点が違うんだよ
MS自身が用意した(SendMessageを使った)ラッパー関数を使えという主張に納得するかしないかの問題
>>143 は
MS無視して(SendMessageを使った)ラッパー関数を自分で造ったら使ってもいいだろってことで
「ラッパー関数がある場合はSendMessageは使うな」に意味が無いと言いたいんだろ
漏れはエントロピー増やすのは反対 >>163
>>143じゃないならそのエスパーもややこしくしてるだけやん？
論点もそっちがズレてるような
というか「MS自身が用意した(SendMessageを使った)ラッパー関数」とか言ってるし
他人のふりした>>143か、>>147もそうだったのか、とすら思える
どっちが>>143の意図だったにせよ的外れなのには変わりないけどな どっちでもいいな
voidじゃないのにvoidと書かれてるのが問題なんだから >>164 が >>143 である可能性も否定できない 自分で自分を否定するのか
そして>>166が>>143である可能性も
でいいのかな すごいレスが伸びてると思ったら・・・・
人と人をいがみ合わせるMSが巨悪だということで手打ちにしたらいかがだろうか ドキュメントが間違ってたぐらいで鬼の首取ったようにギャアギャア騒ぐことが許されるのは初心者のうちだけでしょ。 >>158
何だおまえさん、MSKKの社員がここでどうたらぬかしてるとでもぬかすのか？
だったら、それを公式見解と断る必要があるんだが 初心者質問です。
VBAからIEで印刷するときにプリンター選択を自由に行いたいです。
プリンタを選択する部分は、syslistview32というクラス名で、hwndまでわかっています。
sendmessageの、LVM_GETITEMCOUNTで、プリンターの数まで取得できることを確認しました。
今は、LVM_SETITEMSTATEで、構造体とテキトーなindexをsetして、sendmessageをしたら、IEが落ちてしまうような状態です。
メモリー書き込みも考慮しなければいけないなど情報も見かけましたが、VBA半年程度しかやっていないので、OSに近い処理は何から調べたらいいのかわかりません
プリンター名が指定の文字列に該当するもののindexをsyslistview32から取得し、syslistview32の選択をそのindexにするような、VBAのコードをお教えいただくことはできないでしょう。(Cなどでも大丈夫です。)
以上、よろしくお願いします。 LVM_GETITEMCOUNT を NG にした
残念だったな LVM_GETITEMCOUNTって書いとけばキチガイ一人避けれるということでしょ >>176
デフォルトのプリンタを取得して保存しとく
デフォルトのプリンタ変更する
IEで印刷開始
デフォルトのプリンタもとに戻す
こんなんじゃだめなのか？ LVM_GETITEMCOUNT スレッドまたぎはNG >>180
ありがとうございます
今はそれで運用しているのですが、デフォルトプリンターを変更しても、IEで現在立ち上げているページのプリンターの選択は変わりませんでした。(新しいタブやページなどは変わる)
ですので、デフォルトプリンターを変更した後タブを複製して、そのタブをアクティブにして、複製されていないhtmlの箇所をコピーして、印刷して、タブを閉じて、デフォルトプリンターを元に戻すような処理にしています。
プリンターを変更しないといけない処理が過去にあったりしたそうなので、その場でプリンター選択を操作できるのであれば、知りたいという感じです LVM_SETITEMSTATEで落ちるのはオレオレ構造体のミスとかじゃないの 別プロセスからメッセージ投げるから、IEが構造体にアクセスできないってことでしょ？
VirtualAllocExでメモリ確保してそこに構造体用意しては
LVM_GETITEMCOUNT >>175
じゃあ何のために158みたいな戯れ言をぬかしたんだ？
アホだからか？ それともバカだからか？ >>185
なんで>>158から社員が出てくるんだよ
理解できていないのは>>143って事だぞ
全く同じって事が(>>143には)理解できていないから>>143みたいな発言になるんだろ
って事だぞ 意味が分からん。
ドキュメントが間違ってるだけで、マクロ関数はintで実装されてるから気にせず使えって話で合ってる? >>184
ありがとうございます。少し調べてやってみます。 WiteProcessMemoryの返り値が0になる(´・ω・｀)
GetSharedMemの返り値 のアドレスが、「-1597046784」 とか返ってくる(´・ω・｀)
Long型（-200万～200万くらい）なのに(´・ω・｀)
助けてください(´・ω・｀)
tid = GetWindowThreadProcessId(lngSysListView32, pid)
hProc = OpenProcess(PROCESS_VM_OPERATION Or PROCESS_VM_READ Or PROCESS_VM_WRITE, _
False, pid)
lpShared1 = GetSharedMem(hProc, LenB(li))
lpShared2 = GetSharedMem(hProc, LenB(lt))
For i = 0 To maxitem - 1
li.mask = LVIF_TEXT
li.iItem = i
li.iSubItem = 0
li.lpszText = lpShared2
li.cchTextMax = LenB(lt)
lngRC = WriteProcessMemory(hProc, ByVal lpShared1, li, LenB(li), lWritten)
lngRC = WriteProcessMemory(hProc, ByVal lpShared2, lt, LenB(lt), lWritten)
Public Function GetSharedMem(ByRef hProc As Long, ByVal memSize As Long) As Long
GetSharedMem = VirtualAllocEx(ByVal hProc, ByVal 0&, ByVal memSize, MEM_RESERVE Or MEM_COMMIT, PAGE_READWRITE)
End Function 176だよな・・・
GetSharedMemなんてAPIあったっけ？と思ったら、MSDNのサンプルまんま使ってるのかな？
lpShared2とかltとか変数の意味が分からん
この辺参考にして作り直したら
ttp://hongliang.seesaa.net/article/7851680.html -1597046784==0xa0cf0000、別におかしくはなさそうな
>Long型（-200万～200万くらい）なのに(´・ω・｀)
VBA（VBS?）のLongって22bitなの？
10bit勘違いしてるだけでは？ ソフト業界でマイクロソフトは邪魔でしかない。
まともなものをよくするならいいが、悪するのがマイクロソフトで
しかも、おかしなものを直さず放置して悪化させる。
マイクロソフトは邪魔な存在でしかない。
マイクロソフトの弱点は仕様通りに作れないのは欠点は
同時に自社のソフトをWindows以外のデバイスへ移植できないことも意味する。
そこ弱点だし、将来性がないのもそのあたり。
Windowsの次のOSの仕組みを作ってもソフトの移植ができない。
来年か再来年あたりに出すわけだが引き継ぎできないだろうね。
昔にアーケードゲームの中途半端な移植のファミコンソフトレベルでしかない。
作っても何か違うって状態になる。 >>194
突然どうした？
この朝鮮臭い駄文は窓板きっての汚物キチガイマカーのコピペと見受けるが >>194
内容はともかく、もうちょっと日本語を頑張れ。 >>194
>マイクロソフトの弱点は仕様通りに作れないのは欠点は
同時に自社のソフトをWindows以外のデバイスへ移植できないことも意味する。
この文章は日本語としておかしい。
>昔にアーケードゲームの中途半端な移植のファミコンソフトレベルでしかない。
この文章も日本語としておかしい >>194
＞悪するのが
＞マイクロソフトの弱点は仕様通りに作れないのは欠点は同時に自社のソフトをWindows以外のデバイスへ移植できないことも意味する。
＞そこ弱点だし
＞そのあたり
＞昔に
以上、日本語としておかしい部分を抽出したので訂正するように ダメだぁ...
WriteProcessMemory がどうしても失敗する(´・ω・｀)
デスクトップのsyslistview32やexplorerのDirectUIHWNDでは成功（返り値1）するんだけど、
メモ帳やIEのプリンター選択のsyslistview32や、メモ帳のEditに対しては失敗（返り値0）する
なんでー？ Err.LastDllError の番号は998で、
メモリ ロケーションへのアクセスが無効です。 >>205
64bit版でコンパイルしたら、32bit版のプロセスに介入することできないから難しいという感じでしょうか(´；Д；`)
64bit版のIEでも返り値は0でした...
Long型を、LongPtrにしてもダメでした... 32bit,x64の実行ファイル２つ作って用途に合わせて切り替えたら？ プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 >>206
自分は一旦それで絶望して
32bitアプリ用のラッパー作って呼んでる
32bit資産使ってる人はみんなこうじゃないかな 既存の Console に代わる Windows Terminal のプレビュー版が公開されたけど
今後コンソールアプリはどういう作りになるんだろう
既存の ConsoleAPI またはその拡張API になるのか
それともConsoleAPI は廃止されて Unix なんかと同様のエスケープシーケンスを制御する
curses ライブラリみたいのが提供されるのか
まぁオープンソースみたいだからソース見ればいいんだろうけど 初歩的な質問ですが、64bitのプロセスにもWin32APIって使えますか？ 使える
ただし、例えばGetWindowLongのようにポインタのビット数を決め打ちしている箇所に注意が必要 >>215
Win64APIではWoW64というシステムがWin32からWin64への互換性レイヤーになる。 32bit OS の場合
System32 = 32bit 用 DLL (Win32API)
64bit OS の場合
System32 = 64bit 用 DLL (64bitWin32API)
SysWOW64 = 32bit 用 DLL (32bitWin32API) ありがとうございます
これで気にせず昔の情報あされます SysListView32のリストビューで、縦スクロールバーが表示されている状態で、
アイテムをクリックして選択し、すぐにホイールを回してそのアイテムを画面外に出すと、
一定時間後にそのアイテムが表示される位置まで飛んでしまいます。
選択されていないアイテムよりも、すでに選択されているアイテムをクリックした方が、
ホイールを回すまでの時間が多少長くてもその現象が起きます。
これWindows自体のバグでしょうか。
内部のタイマー処理でも絡んでいるのでしょうか。 君が発見出来るような程度のバグなら
既に誰かが発見して治してるよ ホイールは3rdパーティーのマウスドライバや常駐もので
余計にメッセージ飛ばしたりすることあるから厄介 Win10の一年位前のビルドでSysListView32がスクロールバーを出してる状態でドラッグすると
画面右端にカーソルがすっ飛ぶバグがあったな
SysListView32使ってるアプリは多いからこれは一般ユーザーもすぐに気付い >>222
ホイールでなくスクロールバーのドラッグでも起きました。
操作が難しくなりますが、アイテムをクリックして選択し、
すぐにスクロールバーをドラッグしてそのアイテムを画面外に出すと、やはり同じ現象が起きます。 全然関係なくて申し訳ないが
シングルクリックとダブルクリックの判定って結構難しいよな
クリックのメッセージが飛んできても
シングルクリックのつもりなのか
ダブルクリックの一回目のクリックのつもりなのか
その時点では判断が付かない
なのでダブルクリックの二回目のクリックが飛んで来るかどうか
少し時間をおいてみるしかない
この間にユーザーが何か操作すると >>226
WM_LBUTTONDBLCLKが飛んで来たらダブルクリック
でも飛んでこないかもしれない(つまりシングルクリック)という事だよ
飛んでくるかどうかは少し待ってみないとわからない
エクスプローラでファイルの名前の変更するとき
少し待たされるあの動作
タイマー使ってWM_LBUTTONDBLCLKが来るか少し待ってみるっていう
でもこの魔の時間にユーザーが操作することがあって
例えばホイール回したりスクロールバー触ったり >>229
コンパネでダブルクリックの間隔を調節できるから
そのへんはユーザーに責任転嫁できる ダブルクリックはシングルボタンのAppleから持ち込まれた悪臭 飛んでくるまでいつまで待てばいいですか
少しっていつですか あれ？シングルクリックってダブルクリックになったら、マージされてダブルクリックで処理されると思っていた。 >>234
マージされるのは二回目のクリック
今言ってるのは一回目のクリックをどう扱うかという話
この一回目のクリックは
シングルクリックのつもりなのか
ダブルクリックの一回目なのか
コンピュータには知る由もない なんでここまで説明しないと分からんのだろ
特にハイコンテクストって訳でもないのに 誰が誰に対して？
1回目の誰が2回目の誰に対してマージされて処理されるのか？
おやすみ GetCursorPosでポインターの場所、GetKeyStateでマウスボタンが押されてるか離されてるか
取得できるから、あとは時間測って適当にクリックとダブルクリック、ドラッグを判別する
SwapMouseButtonで右利き左利きとか、GetDoubleClickTimeでダブルクリック判定する時間とか
そんなのを設定できるようにしとけば完璧
これがおまえらが一番納得する方法だろｗｗｗ クリック動作はダブルクリックの直前に発生しても致命的にならないものであればいんでない？
クリック 選択
ダブルクリック 実行
これを逆にするようなら難しくなるだけかと QueryPerformanceFrequencyが10000000を返してくるようになってた
将来はQPCは常に100ナノ秒単位で表しますよってなっていくんだろうか
今回たまたま自分の環境がそうなってしまっただけなんだろうか 現在、AddFontResourceとRemoveFontResourceを使って
プログラムからフォントを登録して使っています。
でもこの方法だと、RemoveFontResourceを呼んでも
システムを再起動しないと登録されたままになってしまいます。
その間はフォントファイルも削除できないです。
どうにかプログラム使用時だけフォントを有効にする方法はないでしょうか？
プログラム終了すれば登録されたフォントも登録解除されるような方法がいいです。 >>245
ドキュメントを読むとWM_FONTCHANGEをブロードキャストする必要があるらしいけどやってる？
もしくはAddFontResourceExでFR_PRIVATEを指定すると
> When the process terminates, the system will remove all fonts installed by the process with the AddFontResourceEx function
とあるからそれに頼るのもありかも >>246
AddFontResourceExでFR_PRIVATE指定でもしかするといけるかもしれませんね！
試してみます。ありがとうございます。 質問させてください。
日本語の Windows10 で、Windows Explorer のアドレスバーに
日本語で「デスクトップ」とだけ入力してエンターキーを押すとデスクトップに移動できます。
他にも、「ドキュメント」「ピクチャ」「ダウンロード」「3D オブジェクト」「OneDrive」など
いくつかの単語が特定のフォルダーと関連付けられていますが、
この対応をプログラムで調べる方法はありますでしょうか。
例えば SHGetFileInfo を使えばデスクトップのフルパスから
「デスクトップ」という日本語の display name を得ることはできますが、
SHGetFileInfo では上記のような関連付けの有無は判定できませんし、
そもそもフルパスから日本語名を得るのではなくその逆をしたいので、
SHGetFileInfo はあまり役に立たなそうです。
何かお分かりのことがありましたら教えていただけないでしょうか。
どうぞよろしくお願いします。 SHGetLocalizedNameという関数が日本語パス名を返すみたいだが、逆はない。
SHGetSpecialFolderLocation/SHGetSpecialFolderPathで特殊フォルダのパス名を取得し、
SHGetLocalizedNameで日本語パス名を取得する。
それで対応表を作るといいだろう。 それは対応表作るにしても結構苦労するよ
例えば俺のWin10のユーザフォルダの中を見ると
同じフォルダ内にドキュメント、と、ピクチャ、が二つずつあったりする
ディスプレイネームが同じでITEMIDLISTが違うアイテムが
同一フォルダに複数存在してたりする環境もあるって事
俺の場合は片方はOneDriveでもう一つはローカル用
同じ名前で同じフォルダ
だから単にドキュメントといってもどっちの事か分からんwwwという事態に
苦労するよ、それ てか、同じ名前のアイテムを同一フォルダに突っ込むWindowsが糞仕様なんだけど
普通に使う分にもどっちがどっちか分からんでムカつく
OneDriveの方は「ドキュメント(OneDrive)」とか区別付く名前にしとけよ
それかOneDriveっていうフォルダ掘ってその下に配置しろよ
同じ名前のアイテムが同じフォルダにあると混乱することぐらい分かるだろ糞 アクセス履歴見ながら対応表を順次変更すりゃいい
そういうのはアイデア次第でどうとでもなる >>249
レスどうもありがとうございます。
他の方のレスを拝見してみても、やっぱりなかなか難しそうですね。
>>250
大変有用な情報どうもありがとうございます。この方針が一番現実的そうですね。
SHGetSpecialFolderLocation/SHGetSpecialFolderPath は
CSIDL しか受け付けなくて、「3D オブジェクト」のように CSIDL がないフォルダもあるので、
CSIDL の代わりに GUID が使える SHGetKnownFolderIDList を使おうと思います。
ただいずれにしても、どのフォルダの CSIDL/GUID を指定するかは
プログラムの段階で決めないという認識で正しいでしょうか？
その部分を自動で決められれば最高なのですが難しそうですね。
あと、日本語名を取得するのに SHGetLocalizedName を紹介していただきましたが、
SHGetFileInfo を使うのとどちらがいいでしょうか？
SHGetFileInfo なら直接日本語名が得られるのに対して、SHGetLocalizedName だと
'the ID of the localized file name in the resource file' が返ってきますが、
こちらのほうがパフォーマンス的に有利だったりするのでしょうか？
>>251
貴重なご意見どうもありがとうございます。確かになかなか問題の根は深そうです。
エクスプローラーのアドレスバーはそのあたりをいい感じに解決しているようなので
その仕組みをそのまま拝借できたら楽なのですが、そう簡単には行かなさそうですね。 >>252 >>254
レスどうもありがとうございます。
確かに Windows のフォルダ階層の仕組みは少し分かりにくいところがありますが、
今回の件についてはその問題はあまり関係なくて、
ちょっと誤解を与えてしまっている気がするので改めてやりたいことを説明させていただきます。
エクスプローラでは、今どのフォルダを開いているかにかかわらず、
アドレスバーに単に「デスクトップ」とだけ入力してエンターキーを押せばデスクトップに移動できます。
つまり、エクスプローラーの中では「デスクトップ」という単一の単語とデスクトップのフルパスとが
対応付けられているということになります。そして私は、この対応表を取得したいと考えております。 質問です。
ファイルに関連付けされている実行ファイルパスを取得するのに
FindExecutable()やAssocQueryString()を使っているのですが、
一部関連付けが取得できません。
どうやら関連付け先の実行ファイルの種類がWindowsパッケージ（デスクトップ）版と
ストアアプリ版とでは動作が異なるらしく、パッケージ版は上記APIで取得できる
ようですがストアアプリ版は取得できないようです。
仕方がないのでレジストリを直接たどる方法を模索しているのですが、
パッケージ版は分かるのですがストアアプリ版がよく分りません。
自分で調べた限りでは、HKCR\{拡張子}\OpenWithProgidsのREG_NONE型の{名前}
を元に、HKCR\{名前}\ApplicationのApplicationNameまでたどればいいと
いう情報を見つけて実践してみました。が、 （つづき）
実際に.pdfがedgeに関連付けられていて上記APIでは取得できない環境
においてレジストリをたどると
\HKCR\.pdf\OpenWithProgids
のREG_NONE型の名前「AppXd4nrz8ff68srnhf9t5a8sbjyar1cr723」を元に
\HKCR\AppXd4nrz8ff68srnhf9t5a8sbjyar1cr723\Application
のApplicationNameまではたどり着きました。
しかしこれに設定されている文字列が
@{Microsoft.MicrosoftEdge_44.18362.329.0_neutral__8wekyb3d8bbwe?ms-resource://Microsoft.MicrosoftEdge/Resources/AppName}
となっています。
どう見ても実行パスではないというか、これをさらにどうにかするのか
たどる方法が間違っているのか分からなくなりました。
正しい方法をよろしくお願いします。 >>256
試しにmspaintと入力してエンター押したらペイントが起動しない？
と言う事は入力が日本語ならC:\Users\<ユーザー名>\この中の対応するフォルダを開く
とか内部でやってるんじゃないかな
英語の場合はLoadLibraryと同じように
Explorer.exeと同じディレクトリ
Explorer.exeのカレントディレクトリ
システムディレクトリ
Windowsディレクトリ
環境変数のPATHに指定されてるディレクトリ
の順で検索されてmspaintが起動とか >>259
レスありがとうございます。お返事が遅くなってしまい申し訳ないです。
> 試しにmspaintと入力してエンター押したらペイントが起動しない？
本当ですね！
しかし一方で、C:\Users\＜ユーザ名＞\AppData というフォルダはあるのに
アドレスバーに AppData と入力してエンターを押しても期待通りの動作はせず、
なかなかルールは複雑みたいです。
また、日本語環境ではアドレスバーに「Desktop」と入力してエンターを押しても
期待される動作にはならず、「デスクトップ」でなければならないようなので、
やはりシステムの言語設定は関係あるように思われます。
SHGetFileInfo で取得できる displayName を調べれば
日本語環境ならデスクトップフォルダから「デスクトップ」という文字列が得られるので
その逆ができればいいかと思ったのですが、実際はそれほど簡単な問題ではないようです。
例えば私の環境では C:\Users\＜ユーザ名＞ の displayName は
ウィンドウズの GUI から設定できる「ユーザ名（アカウント名）」になっていますが、
エクスプローラーのアドレスバーで期待通りの動作になる文字列は
「ユーザ名（アカウント名）」ではなく「フルネーム」でした。
エクスプローラーのアドレスバーの動作を完全に模倣するのは難しそうですが、
ここでいただいたアドバイスを元に、現実的な方法を考えていきたいと思います。 >>261
いくつか気付いた事を報告 その1/2
・ユーザーフォルダ内のフォルダで移動できたもの
アドレス帳
お気に入り
デスクトップ
ドキュメント
ピクチャ
ビデオ
ミュージック
仮説1 ～\<ユーザー名>\(日本語名で表示される一部のフォルダ)って条件なのかもしれない
仮説2 仮説1の一部のフォルダで法則があるとしたらレジストリで保存場所を変更できるフォルダではないか？
試しに「プログラム」「スタートアップ」と入力しても移動できた
レジストリの「HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders」
ここに列挙されてるやつがヒントになるかもしれない
・レジストリをヒントに入力して移動できたもの
プログラム
recent
sendto
スタート メニュー
スタートアップ
・その他で移動できたもの (ツリービューで日本語表記をヒントにした)
パブリック
コンピュータ
ネットワーク
コントロール パネル
ごみ箱 いくつか気付いた事を報告 その2/2
・ここまでの間に気付いた事
アドレスバーに「コ」と入力すると
コントロール パネル
コンピュータ
コンピュータの簡単操作センター
この3つの入力候補が現れたけど
入力候補が表示されるのとされないのもあった
あと日本語・英語混在(sendto recent)でさらに混乱させる事になってしまったかもしれないｗ ドキュメントがDocumentsの表示になった時の直し方で
LocalizedResourceNameが出てくるからそれをヒントにするのもいいかもしれない >>262
コメントどうもありがとうございます。
色々とレジストリにもヒントが隠れてそうなので調べてみたいと思います。
>>263-265
大変有用な情報どうもありがとうございます。
書いていただいた内容を見ながら実験してみて分かったこととして、
問題のアドレスバーの挙動は環境によって相当にブレがあるようです。
私の環境（Windows 10 Pro）では、
>>263 に書いていただいた文字列のうち
「recent」「コンピュータ（ちなみにコンピュータ『ー』もダメ）」は
期待通りの動作にならず、代わりにブラウザ（私の環境では Firefox）で
入力した文字列が検索されてしまいました。
私の環境ではアドレスバーに「Creative Cloud Files」と入力すると
対応する Adobe のソフトが作ったフォルダが開かれるので
ある程度外部ソフト等の影響があるだろうとは思っていたのですが、
「コンピュータ」ですら環境によって結果が異なるとは予想外でした。
ちなみに外部ソフトの影響に関しては、レジストリの
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace
に登録されているものが該当しているような気がするのですが、
確かなことは分かっていません。
ともあれ、非常に興味深い実験結果と考察を読ませていただき
大変勉強になりました。どうもありがとうございます。
また何かお気づきのことがあれば教えていただけると嬉しく思います。 >>266
10の場合はコンピュータがPCに変わったんだと思う デフォルトで用意されている日本語のフォルダ名を英語に戻す
https://laboradian.com/use-en-folder-name/
11個の日本語名になっているフォルダ
日本語名のフォルダには、desktop.ini という隠しファイルがある Win32アプリのバージョンリソースについての質問です。
自作アプリの1.0.0をリリースした後、1.1.0を作成中にベータ版を出す場合、
リソースのFILEVERSIONやPRODUCTVERSIONはどのように記述するのがよいのでしょうか。
1,1,0,0は、1.1.0の正式版に使いたいのですが、これより大きい値を付けるのも変だし、
数字以外の文字は入力できないようなので。 好きにしろよｗｗ
自作アプリなんて俺は1.0も1.1も2.0もみんなβだから1.00から0.01刻みで増やしてる
昔はカスタムビルドステップでビルド番号もつけてたけど今はやってない ちょろめとかふぃれふぉxはメジャーの数字上げ過ぎてひどいことになってるな
ばかなんですかね 1.0.0.01
1.0.0.011
1.0.0.0111
1.0.0.01111 >>271
> 1.0.0.1とかはあかんの？
やっぱりこれが妥当なんですかね。
他のアプリのベータ版も見てみたいとは思うのですが。
秀丸エディタは、ベータ版は4桁目を増やし続けて、リリース版には99を入れてました。
1.1.0.99が1.1.0のリリース版という法則でした。
> 1.1.0.α
> 1.0.0.01
FILEVERSIONやPRODUCTVERSIONには、αや01は入力できないです。
必ず4つの数字を入れないと、勝手に0が入ってしまいますし。 昔、同僚にクラス設計やコメントの書式にやたら拘る奴がいたの思い出した
綺麗なソースコード書いてたけど、まったく動かないゴミですぐ職場から消えたわｗ そういう人って恋人も見た目重視にしてそう
ソースコード(見た目)って意味で >>276
所詮決め事なんで>>272の言うとおり好きにしてくださいって話だけど
良くありがちなのは
メジャーバージョン．マイナーバージョン．ビルドバージョン
みたいな
メジャーバージョンはアーキテクチャとかUIの大きな変更とかユーザから見ても
変更されたことが分かるような場合
マイナーバージョンは単機能追加とかバグ修正などユーザから一見分からない
ような軽微な変更の場合
ビルドバージョンは作業途中の状態を管理するための連番や単一作業の区切りを
管理するための連番とか
みたいな感じで自分で目的を決めて使うしかないよ
他には作業の効率管理のためにさらにビルド回数を最後に付けてコンパイルする
たびに番号加算していくとか
後はOSのバージョンごとにパッキングを変える場合はPRODUCTOVERSIONと
FILEVERSIONを関連性は持たせるけど個別に管理するとか
>>273
あれは企業的に仕事をしてますよアピールなので残念なのは経営層か
投資家かな
バグ修正はマイナーバージョン、それ以外はすべてメジャーバージョンの修正に
することですごくたくさん仕事してますよがアピールできるので >>273 さんはそんなこと言われなくても判ってて書いてるだろ INVALID_HANDLE_VALUEってマジで糞だよな
うっかりしてると失敗したときNULLが返ってくるって勘違いするというか
ボーッとしてるとそういうコード書いちまうことがある
大概のAPIでは失敗したときNULLが返ってくるってのもある
混在いやん あと、なんでINVALID_HANDLE_VALUEが必要になったのか技術的な背景が気になる
普通に0を返しとけばいいじゃん、って思うよね
他のAPIがそうなってるんだから
謎 >>281
どんなAPIでも最低限の仕様確認してから使えよ しかしそれらを超越した次元で総合的に判断してやっぱりINVALID_HANDLE_VALUEは糞
必要ないからな >>284
それは論点が違う
マジで糞かどうかだろうが
285はちゃんと自分なりの見解を言っているし
286は情報提供している
お前だけとかくだらんことしか言わんボーガスとは次元が違う
16bit時代は低コストに拘るあまり
色々とアホなことをしていた
その名残を糞って言えないやつも糞だ ComboBoxはCB_ERRがある
ListBoxはLB_ERRがある
ListViewはただの-1で定義無し
LV_ERRじゃないのはなんで？ >>286読んで思い出したが
そうそうHANDLEのスマポ作るときにウザいんだよな
既定の初期値を何にしておくかって問題があるからな！
ああ糞だ 後HANDLEのスマポのデストラクタでCloseHandleするとき
失敗したり何も入ってなかったり
無効なハンドルの場合はCloseHandleしないようにする場合も嫌らしい
無効なハンドルを表す値が二つ有るからな！！
if( handle && handle != INVALID_HANDLE_VALUE ){ ::CloseHandle( handle ); }
と書いてしまいたいところだが、本当にこれでよいのか？
それかCloseHandleに無効なハンドルを渡したときは何もしないことを期待して
if文なしで単に::CloseHandle( handle );とだけ書くか
しかしCloseHandleに無効なハンドルを渡したときの動作はMSDNには書かれてないんだよな
まぁ何もしないと思うが ああ今調べたら、CloseHandleに無効なハンドル渡したら
GetLastErrorが汚染されるらしいな 初期化と開放とかのインターフェース作って、そのインターフェース派生でAPIアクセスしてるな
その手のはAPI直接叩くソース書くと後からコーディングミスに気付いても修正困難になるしバグの元 >>288
前者2つはOS基本機能、後者はコモンコントロールというオプション
という違いから歴史と立ち位置が違う
ついでに言えば設計から全然違うんで、定義がないのは不思議ではない どれもコモンコントロールだよ
歴史的には昔はリストビューがコモンコントロールじゃなかったかもしれないが分からない 昔のWindowsAPIはHANDLEとポインタが別物だったのを知らん人がいるのか >>288
ポインタが奇数になるはずはない(キリっ
だから奇数の空間を全て別のオブジェクトに
おれ天才じゃね？って糞言語が日本にはある フリーのリソースエディタとAPIでGUIプログラムを作っているけど、
もう時代遅れなのかな。
みなさんは、GUIプログラムはどうやって作っていますか。 リソースエディタなんぞ使わず全部apiからテキストエディタ上で
数値指定で作ってるんでそんな自分よりかは進んでるぞ
まあ今の時代ならvisual studio使うのが普通だろうね >>297
cygwin/mingw64 でコンパイル・リンクできるよう、リソースは手書きですね… 俺は自作のリソーエディタ使ってるけど。MinGWでもVC++でもビルドできるよ。 >>294
コモンかどうか名前はさておき、リストビューは明確にcomctl32を使うような
宣言とリンクがないと使えないでしょ
リストもコンボはこいつの範疇ではない WinUser.h
ComboBox CB_ERR
ListBox LB_ERR
CommCtrl.h
ListView関係のメッセージやマクロ
この違いは歴史関係って事？
LVM_INSERTITEMが失敗した場合は-1が返るけど
LV_ERR(-1)とするのはおかしい？ Windowsで.NET使わずにC/C++とWin32APIでPerl互換の正規表現を使ったプログラムを作る場合、
従来はboost::regexやPCREなど別途ライブラリが必要だったけど、Windows10以降はICUの正規表現を使えるようになった。
ただし、可変長文字列を扱うUnicodeStringクラスがヘッダーファイルicu.hから削除されているので、std::wstringなどで代替する必要がある。 ListViewはWindows95で追加されたコントロール 昔の事は多少は多目に見てやれよ。今みたいにSNSが活発じゃないし、githubで他人のソースも簡単に見れるわけしゎゃない。知見を共有しづらい時代なんだから ハンガリアン記法自体はBug捕り等に有効だったのに Standard Control
Common Control >>309
システムハンガリアンは違うし、なんで過去形なんだ？ unix の execlp だと pid は変化しませんが、
Win32API の execlp とか _execlp とかだと processID は変化してしまうようです。
CreateProcess が呼ばれているからだと思いますが、
Win32API の execlp とか _execlp とかで変わったあとの processID を知る方法はありますか？
(起動された側で getpid() で判るのですが、そっちではなくて元の processID を握ってる方からのリンクが切れて困ってます。) >>297
俺はリソーススクリプト直叩き
MSDNに詳しい情報乗ってるし、英語だけど
プログラマなら大体わかるよ、翻訳サイトを使ってもいいしね
そして、ライブラリ化しといて次から簡単に使えるようにしとく
バージョン情報とかも関数やクラスにして簡単に使えるようまとめとけば便利
GUIは.NETがクラス化の良いお手本になるよ >>314
> Win32API の execlp とか _execlp
そもそもexeclpとかはwin32apiじゃなくて単なるライブラリだよ
とりあえずざっとソース見る限りではpidを返す方法はないみたい（インターフェースもないしね）
自分で実装するしかないと思う >>316
VSは使ってるよ、昔は無料のエディションには
MFCもリソースエディタも付いてなかったからな
趣味でやってるから問題なし
フリーのリソースエディタを入れるか迷ったこともあったけど
直叩きで行けるしまあいいかと それぐらい普通、何でもないよ
俺なんかメニューバーとかスクロールバーとかツールバーとかリストビューとか
こまごましたUIパーツ、全部DirectXで一からフルスクラッチで書いたし
4K画面だとリストビューとか動作がカクカクになるから使い物にならんよ
フォントの描画が重いみたい 結構前からリソースエディタは無料版VSでも入ってたろ 後世のために書いておくが、Visual StudioのリソースコンパイラーはUTF-8の扱いに致命的なバグがあって、最悪の場合、文字化けする。あれはANSIコードページかUTF-16で使うものだ。 >>321
コンパイラーの問題だからエディターは何でもいいんじゃね
って話ではないの？ そもそもリソースファイルにUTF8が使えるなんて知らなかったわ MinGWのwindresというコンパイラーなら、pragmaでコードページ指定すればUTF-8が使える。
Visual Studioのrcは前述の通りUTF-8読み込みにバグがある。 RisohEditorはUTF-8とUTF-16のソースが扱える。UTF-16の入力は、独自のプリプロセッサでUTF-8に変換している。 リソースファイルはBOMつきUTF-16LEでいけるでしょ。 重箱。UTF-16LE/BEと呼ぶ場合はBOMを付けてはならないらしい。 >>331
理解が間違っている。
「BOMつきUTF-16LE」と「UTF-16LE」は別のものであり、どちらも存在する。
「UTF-16LE」にBOMがついていないからこそ「BOMつきUTF-16LE」という表現が成り立つ。
小倉トーストとトーストが別のものであることと同じであり、トーストに小倉餡がついていないからこそ小倉トーストが成り立つ。 粒餡と餡子が別のものであることと同じであり、
餡子に粒が入ってないからこそ粒餡が成り立つ
ってことですね 名古屋のモーニングにゆで卵がついたからといって、モーニングでなくなるわけではないのだ。
無論、ゆで卵がつかないモーニングもある。ゆで卵がつこうがつくまいがモーニングなのだ。 名古屋とか言う異世界の話はやめようぜ
意味が分からん 段ボール入り肉まんが人によってはバレないが、やはり人間的にはエラーが出やすい
そういうことだな Caretの点滅間隔について質問です
自アプリがアクティブの時のみ点灯(点滅間隔にUINT_MAXを指定して擬似的に)
自アプリが起動中はWM_SETFOCUSでON(点灯)に、WM_KILLFOCUSでOFF(元の間隔)にする事はできましたし他のアプリにも影響はありません
ですが自アプリが終了したら他のアプリでもONの状態になってしまいます
メッセージを追ってみると
WM_CLOSEでDestroyWindow
→WM_KILLFOCUSでOFFへ
→プロセスが終了
になっていたので自アプリ内で再度ONになっている事はないです
これはどういう事ですか？ WM_CLOSE
→DestroyWindow (hWnd 失効)
→WM_KILLFOCUSでOFFへ (hWnd 違いで無視)
→プロセスが終了
かな
知らんけど ありがとうございます
引数は間隔のみですが一応DestroyWindow直前でOFFにしてみても同じ結果でした Getで値を見てみるとONの状態になってしまうのではなく
アプリが終了したら間隔が0xfeeefeeeになってしまう
でした
言い直しますと
System設定の500(ミリ秒)からUINT_MAXではなく200へ変更するようにしても
アプリを終了したら間隔が0xfeeefeeeになってしまう
です 方法は何でもいいけど、例えばクリックしたらキャレット処理を終了→その後アプリ終了でどうなるかやってみ
問題が絞り込めるでしょ
WM_CLOSEで終了処理が思ったように動いてないってのはありがち >>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです >>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした 0xfeeeってデバッグの時の初期化されてない奴の値じゃないっけ
終了時に数値の参照先おかしくなってるとかかな 「あなたのアプリがWM_CLOSEで0xfeeefeeeにしてる」のは明白でしょ
0xfeeefeeeって特別な値よ、ググってみそ DEBUGビルドのランタイムで
newからのdelete や malloc からの free の後に 確保領域の内容を0xfeee で埋める
ポインタを開放した後に指し先の内容値を取得し、セットしちゃってるんでないの？ 速度設定するとこにトレース出力でもおいて、まずはほんとに意図しないタイミングで呼ばれてないのかチェックだな >>353
キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
>>354
してもしなくても同じ結果になります
>>355
値の指定をハードコードにしても同じでした
>>356-357
重複した呼び出しなども無かったです 別のとこでメモリ壊してるんかな
その部分だけの最小コード書いてみては
それでもなるなら手に負えない感じが >>352-353, >>355
0xfeee なんてパターンあったっけ？
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)
の４パターンしか知らんかったわ
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260966(v=vs.60)#what-exactly-do-you-mean-by-failure >>358
> キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
> WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
マウスクリックで終了してる「はず」なのに終了してないなら、そもそもキャレット処理を
全く走らせてなくても問題が再現する「はず」
でもその場合は問題ないってなら、やはり終了処理に何かある >>361
new -> delete -> 値が0xfeeefeeeに
もしnewしたクラスのメンバ変数が値を保持して間隔設定してるなら
delete後に0xfeeefeeeなるよ
クラスポインタをdeleteしてからNULLにしたらエラーになるはず
こんな感じじゃないかな
WM_CLOSEで(deleteしてから)DestroyWindow (クラスポインタとメンバ変数の値が0xfeeefeeeに)
→WM_KILLFOCUSでOFFへ (OFFにする時に参照してるメンバ変数が0xfeeefeee)
→プロセスが終了
でもハードコードでもなるみたいだから違うかも？ unix の pipe は双方向だと思うのですが
win32api の pipe (namedpipe ではない方) は一方通行なんでしょうか？
先生なんとかなりませんか？ >>366
間隔設定がよくわからんが
class C { int a; };
auto x = new C();
delete x;
ってやるとxのポイント先が0xddddddddになるんだが…
Visual Studio Express 2017, 15.9.16 >>366
書き忘れたけど当然デバッグビルドな
ついでにライブラリのソース追っかけたけどパターンはバイト単位に設定されてるので0xfeeeなんてパターンは無いと思うよ >>365
どこのgoogle使ってんの？
＞0xfeeefeee を検索するとHeapFree で処分された後のヒープ領域がこの値で埋められている、とわかる。 ということは「処分済みヒープへのポインタを誰かが使っている」ということだ。
なお、正解かどうかは論じてないので悪しからず 解放バッファの埋めパターンは、ライブラリが自力でセットするものなの？ とりあえず>>373の検証
100バイトHeapAllocして適当にa~zの文字書き込んでHeapFreeの前後でダンプ取ったけど、
0xfeeefeeeが入ることはなかったな
debug版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
F0 C6 42 05 88 41 47 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
release版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
78 EF 81 05 F0 54 79 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
free後に何か入ってるけど、実行毎に違う値が入ってる
0xfeeefeeeに関しては、単純に何かのAPIがそういう処理してるんでは APIだからコンパイラ関係ないと思うけどね
OSは8.1だけど
コンパイラというかライブラリが関係するはずのmallocでやってみた
vs2017 - ツールセットvs2013（詳細略）
以下並びは>376と同じだけどダンプの長さはa~zの26+1バイトじゃなく30バイト
allocも100ではなく30バイト
debug
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 CD CD CD
DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD
release
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 00 00 00
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 00 00 00 >>379
環境は？
十数バイトをdeleteしただけでHeapFreeを呼ぶのも考えづらいし、そもそもこっちでも>>376と同じくHeapFreeで0xfeeefeeeが入ることもなかった Win10 Pro(32bit)でHeapFreeやってみた
VS2017(Community Edition)は0xfeeefeeeにならなかったが、
VC2010(Express Edition)でやってみたら0xfeeefeeeになったわ(確保していた領域の先頭8バイトほどに0xfeeefeeeじゃない値が入っていたが)
面倒だからオプションとか生成されたバイナリとか詳しく比較してない >>380
VC++2010Expressだよ
画像こっちの方がよかったね
ttps://i.imgur.com/eDh78Kq.jpg メッセージ処理の
case（msg）
ってなんで
case（msg.message）
じゃないの？
構造体直接評価できるの？ >>384
多分サンプルの読み方を勘違いしている
GetMessage関数なんかで使われるlpMsgとかはMSG構造体なので中でメッセージIDを
確認したいならば「msg.message」を見ることになる
メッセージIDのハンドリング行うサンプルなんかで普通に使われてるWndProc関数の
uMsgはUNIT型の「msg.message」が実体なのでcaseでそのままハンドリングできる
でないか？ 本来ライブラリに任せるべきところをかなりネイティブなwinsockプログラミングをしています。
TCP通信にて最大セグメントを超えてwinsock2.sendを行った場合はどうなってしまうのでしょうか？
エラーとなるためそこも自前で実装する必要があるのか、それともwinsockが勝手に分割を行ってくれるのか、はたまたネットワークアダプタやルーターなどのデバイスが勝手にやってくれるのか、どういう挙動となるのかご伝授お願いします ソケット通信てそんなところ気にしなきゃいけなかったっけ？
アップロード・ダウンロードルーチン組んだけど記憶にない winsock2に限ればエラーが返るんじゃないか？
質問するよりもmasdn見たほうが確実だろ UDPだと知らん間に分割された挙句
場合によっては断片が届く順番まで変わるからな sizeofに括弧付ける
マクロの引数は使用時に必ず括弧付ける >>393
> 場合によっては断片が届く順番まで変わるからな
むしろTCPが頑張って順序を元通りに入れ替えてるんだが… >>392
不要なカッコは付けない派
例外は演算子の優先順位がわかりにくい時に付けるぐらい
理由は間違っててもコンパイルエラーにならないから >>392
俺も無駄な括弧はつけないな
わざわざつける理由がない
単項演算子の優先順位を知らんアホが仲間にいない そのアホがいた・・・驚愕
今 sizeof の話をしているんだが
脈絡が読めないとはな 付ける派
if(...) switch(...)なのにsizeof(...)じゃないのはなんとなく嫌 hoge = malloc(length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * length);
hoge = malloc(*length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * *length);
hoge = malloc(*length * sizeof struct hage **);
hoge = malloc(sizeof struct hage ** * *length);
()付けないとどんどんわかりにくくなっていく >>400
おまえみたいのに読んでもらう必要が皆無 単項演算子とそうでないものの区別がつかないアホが
return にも括弧したがるんだろうな
# K&R 1st世代の人はともかく 書いてから思ったが、排他の否定な書き方が好きじゃない>>406
読みにくい
肯定した書き方だけに統一したい
そういう意味では、好きじゃないという書き方もダメか
嫌いと書くべきか
ということで、
Win32APIの話をしろ
おやすみ
sizeofは計算式絡むことがほとんどなのと、明示的にした方が分かりやすく
馬鹿らしいミスの回避のためにも付けといて損はない >>403
この例からしても括弧つけた方が見やすいが、ID:MP9GBJ11は見やすさ全否定なの？
俺様はインデントもスペースも改行も無くても、優先順位・スコープ範囲が分かってるから無問題って理屈だよな typeidもsizeofも関数じゃなくて演算子なんだけど、typeidは括弧が必須。 >>389
TCPのMSSは相手との関係で決まるので何バイト送り込んでもエラーには
ならないと思うけど
TCPとしては送れたデータ量をSeq番号で管理していてセグメントの分割は
ドライバの仕事なのでアプリケーションレベルでは意識する必要なかったと
思うけど
UDPとかIP直みたいなデータグラムの場合には「WSAEMSGSIZE」が返って
くるみたいだけどTCPは平気なんじゃないかな(転送データの保障がある
わけではない) さすがに return にまで () 付けてるのはうざいわ >>411
仲間に書かれても文句は言わねえな
見た目の問題じゃなく、やろうとしている内容がセンスに欠けるときなら
これ例えばこんな手もあるよなと議論に誘ったりはするし
iocccみたいな実験をTPOを間違えてやる大馬鹿野郎がいたら喧嘩売る
実例として/*/野郎は口汚く罵ってやった （）なんてあってもなくても分かりやすけりゃいいんだよ
逆に>>403なんて（）あってもなくても読みにくい。俺はこんなの絶対書かないな sizeof には、極力変数名側を与えるようにして型名は避けるようにしてるけど
WinAPI とは遠い話だな もうダメ、我慢できないから言っちまおう
>>403は必要な()とそうでないのが解ってねえ
アホｗバカｗｗｗ return (a);
とは書かないけど、
return (a+1);
のときは括弧を付けなくなる GCCではtemplate関数の記述する際に、ある文字列が型であることをコンパイラに教えるtypenameキーワードが必要なので、sizeof に括弧がないと読みづらくなる傾向はある。 >>420
バーカｗｗｗｗｗｗｗｗｗｗ
typenameが必要か否かは規格17.7で明確化されている >>415
規約や仕様の話じゃなくて見た目の話してるんだから、それを分かっててセンスがどうのこうのって言い出すのなら
この話の流れで草を生やしながら馬鹿まき散らすのは、マジでセンスないねって話になるよ おはようさん
スレタイ読めない奴は総じてセンスも才能もないってことですよ >>422
やろうとしている内容がセンスに欠けているときって言ってるのに規格がどうたらとか、いいからまず涙拭けよw ガイジの出身地方ではWin32APIの範囲なんだろ Win32APIがsizeof()推奨なのは
hoge * で済むものをわざわざ
typedef hoge *LPHOGE;
とかやっちゃって
sizeof LPHOGE
とかやって
不都合出て来るからだろ Win32 APIはバージョン差を吸収するのにパラメータ構造体にその大きさをセットするので
わりかし sizeof の頻度は高いかもな 流れを読まず適当にレスすると
win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
こんなん出ました > win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
理由もメチャクチャだし周知とかアホすぎる
> それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
>>430出ましたw sizeofに括弧つけるかどうかなんて
正直どうでも良くね？ 構造体にサイズ入れることが一番多いからあんまつけないな 64bit化してからHOGE_PTRが増えてさらに混乱 sizeof付けるの嫌ならラッパー作ってそっちで呼び出せよ
win32APIの仕様がそーなるんだからしかたねーじゃん。手続き通りに記述するしかない。 perlでWin32APIを使うライブラリWin32::APIを使ってると、
32bitと64bitで異なる構造体のアラインメントを正しく解釈してくれないので、アセンブラ並みに低レベルな記述が必要になることがある。 >>440
世の中には発酵食品が沢山ある。
発酵 腐敗 熟成 の違いを見極めるのは難しい。 質問です。
SetFilePointer()
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointer
を FILE_END で使ったことのある方はおられますか？
第3引数 PLONG lpDistanceToMoveHigh を 0 （そして第 2 引数 LONG lDistanceToMove も 0 ）で使うと、FILE_END であっても当のファイルが 4GB 以上の場合にはポインタがファイルの最後に設定されない現象があるようです
この場合ダミー変数（毎回 0 を投入している）を設けて lpDistanceToMoveHigh にそのアドレスを設定すると FILE_END がその本来の意味を示すようにみえます。
推量形で記述しているのは、私の環境（mingw64-gcc）ではコンパイラのオプティマイザが過剰に効いている可能性があり -O0 でコンパイルしてはじめて、ある程度この現象が確認できたという事情のためです。
これは一般的な話なのでしょうか？ >>444
printf("sizeof(int):%d, sizeof(LONG):%d\n", sizeof(int), sizeof(LONG));
$ ./a.exe
sizeof(int):4, sizeof(LONG):4 lpDistanceToMoveHighがNULLの時のFILE_ENDは単純にファイルサイズも下位32bitだけ見て処理してそう
でかいファイル扱うなら素直にSetFilePointerEx使った方がよさげ >>446
*Ex には気がつきませんでした
昔書いたものをみると
s1 = GetFileSize(f, &s2);
SetFilePointer(f, s1, (PLONG)&s2, FILE_BEGIN);
WriteFile(f, p, strlen(p), &n, 0);
ってやっていましたから、どうも、昔も同じところで嵌ったらしく、お茶を濁す方法まで昔と同じのまま、しかもその記憶が今はない…
もうなにもかも忘れてしまった…
コメントありがとうございました こんな場所でこんなクソ書き込みしてるくせに自身のクソさ加減に気付かないなんて病気だぞ☆ PCが複数のネットワークにつながっています。
IUPnPDeviceFinderで検索するネットワークを指定するのはどうしたらいいのでしょう？ CSPのハンドルであるHCRYPTPROVなんだけど、
これってスレッドセーフ？
具体的には、同じハンドル使って別スレッドで同時にCryptGenRandom()呼んでも大丈夫なものなの？
Goのcrypt/randが排他せずに同じハンドルで呼んでいて気になったんで 7から10にしたらこんな感じで画面外の領域が描画されなくなってしまいました ttps://i.imgur.com/IjNvIme.png
Windows10で画面外の領域を描画させるような関数か方法はありますか？
InvalidateRect、UpdateWindow、RedrawWindow、PrintWindow、DwmGetDxSharedSurfaceは試しましたが無理そうです
ソースです ttps://dotup.org/uploda/dotup.org1975774.cpp.html >>455
CreateDC("DISPLAY", ...)
CAPTUREBLT >>456
CreateDCではディスプレイに表示されてる領域のデバイスコンテキストしか取得できませんでした
ウィンドウの外ではなく、ディスプレイの外に出ている領域を取得したいのです
CAPTUREBLTは単体だと真っ黒、SRCCOPYと一緒に指定してもSRCCOPY単体と変化はありませんでした 455に貼ってるスクショでは単に5chのページが途中までしか描画されないように
見えるだけで、"画面外の領域"の意味がよく分からんが・・・・
それはともかく、実は管理者権限で実行するといけちゃうとか？ >>458
別アプリ（画像ではブラウザ）をSetWindowPosでウィンドウの一部がディスプレイの外に出る位置に移動して
そのウィンドウの内容をBitBltで取得して自分のウィンドウに表示してるんですが
ディスプレイに表示されてないディスプレイの外に出た部分が真っ白になってしまいます
すいません、説明下手なのでソースを見てもらえると助かります まともに説明もできないソースだとそもそも何したいのかわからないほどのバグな気がする 対象となるアプリのスクショを取るようなアプリでOK?
面倒なので試さないけど、単に画面外に描画しても無駄なので描画してない
だけのような気がするが、その理屈なら画面外ではなくその上に別ウィンドウを
表示させるとどうなるんだろうなってことと、対象アプリがブラウザ以外だと
どうなるんだろうなってことなど突き詰めたい項目が（面倒くさくなり以下略 Windows7でaero有効なら画面に見えていないウィンドウからbitbltできるが、10でaero廃止されたのが
関係しているのかな。
10でもタスクバーのウィンドウプレビューは表示されるから7と同じようにできてもいいとは思うが。 10でも取れるぞ。これは確実
ソース見てないから原因はしらね >>461
OKです
デスクトップのデバイスコンテキストから転送すると上にある別ウィンドウの画像込みになりますが
対象アプリのデバイスコンテキストから転送すると対象アプリの画像だけを取得できます
対象はブラウザ以外でも描画されない部分が白か黒かの違いだけです ttps://i.imgur.com/Mm7HOQP.png
>>462
プレビューでも描画されないです ttps://imgur.com/ATYh4ng >>464
早く解決したいのだったらソースを貼らないと そのコードだとキャプチャできないのは確認したけどプレビューまではそんな風にならんな
なんとなくOS自体の省力設定に連動して
OSがクリップしてる or アプリ自身のクリップを引き起こしてる臭いけど
新しめのキャプチャAPIだと↓
https://docs.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture >>465
>>466
>>455 で張ってますが落とせないとかありますか？
別のろだで用意したほうがいいですか？
>>467
うちだと実機でも仮想PCでもプレビュー欠けてるんですよね
仮想PCに新規でWin10入れて確かめてみます
C++のソースありがたいです。試してきます 俺も>>455と同じようなキャプチャソフトを自作してたんで今win10で試してみたが
ウィンドウが画面外にはみ出しているからといってキャプチャできないことはないな。
プレビューが欠けるということもなかったが。
>>464
プレビューが欠けるのが特定のアプリだけならそのアプリの問題だろうから
あきらめるしかないだろうねえ。
どのアプリでも欠けるとしたらwindowsの設定かGPUの問題かなにかかな。 クリーンインストールWin10でも症状変わらず
ScreenCaptureforHWNDも変わりませんでした
>>471
画面内で表示してから画面外に移動してキャプチャしてませんか？
キャプチャはできても更新がされない感じなので
移動してから内容更新するとキャプチャ画像とプレビューがこうなります ttps://imgur.com/9IQYBMH それをedgeとかでやっても同じなん？
動画を表示していもプレビューは随時更新されるが、ふつう。 コンパイラ設定がxp互換だと撮れないってのもあるな こっちで試してる限りでもいまいち挙動に一貫性がなくて確証は無いんだが
そのWaterfoxってのだけ更新時に画面外のレンダリングを省いてるのはプレビューで確認できたんで
検証するのにそれは外した方がいいな
画面外に出たアプリのWM_PAINTでrcPaintが差分を返すのは正常な挙動なので
アプリ自体の画面更新と内容の取得のタイミングによってはプレビューがそうなる理屈は説明できる
キャプチャに用いているBitBltとも内容が異なるのはGDIとDWMでは見てるバッファが違うのかもしれない
ただ全部のアプリがそうなるとなるとこっちじゃ現象自体が確認できないのでなんとも >>473
>>477
Firefox、Waterfox、Chrome、VisualStudio2019、MPCBE、ペイント、メモ帳
画面外に出た部分はプレビュー更新されないし、BitBltも更新されてない画像しか取れない
Edge、フォト
画面外に出た部分もプレビュー更新される、BitBltでは画面内でも画像が取れない
IE
画面外に出た部分もプレビュー更新される、BitBltでは画像が取れたり取れなかったり不安定
動画です https://dotup.org/uploda/dotup.org1976519.mp4.html
>>474
Loiloだと画面外は真っ黒でした。他は名前言ってもらえれば試します
>>475
x64でプラットフォームツールセットはVisual Studio 2019(v142)なのでXP互換ではないと思います
>>476
ウィンドウの一部が画面外に出ても、ウィンドウがすべて画面内にあるのと同じようにキャプチャしたいです ディスプレイ外にはみ出した窓があってそのはみ出したリージョン内で表示更新かかってて
そいつを ALT+PrtScr でキャプチャしてもうまく取れてないなら厳しいんでないかな 俺自作のソフトはキャプチャできるが、ALT+PrtScrはキャプチャできん＠win10 >>478
なるほど、ペイントで現象確認した。
GPUリソースを食わないよう改善した結果とかかねえ。 どうなんだろう。BitBlt(,,,SRCCOPY | CAPTUREBLT) しか方法ないのかね。 2段階のアクセラレータはどのようにやるのがいいの？
Visual Studio のCtrl+K Bみたいな・・・ >>484
アクセスキーテーブル切り替えか、
状態遷移だろうよ。 なんかだんだんワケがわからなくなってきたが再度確認したら
基本的にUWPアプリ以外は画面外の再描画しないっぽいな（Chromium系はやっぱり描画されてるけど）
ほとんどのアプリが律義にrcPaint見てるとも思えんし描画先がGDIだと強制的にOSでクリップされてんのかしら？
おそらくWindows Compositionが噛んでてBitBltで取れないUWPアプリはWindows.Graphics.Captureで取れるけど
UWPアプリ以外でクリップ済みのイメージしか取れないのはまあ当然っちゃ当然 win10でUWPでない従来のアプリの画面外キャプチャできるよ
win7がaeroオフだと撮れなかったみたいに何らかの条件があるのかもしれないが Mozilla Firefoxなどサードパーティ大手は今もWin32APIをネイティブに使っており.NETは使ってない。 エクスプローラのアドレスバーで「デスクトップ」とか「ダウンロード」って入れたら
そこのパスに移動しますが、「デスクトップ」（という日本語）からパスに変換するAPIはありますか？ >>489
SHGetLocalizedNameの逆写像っぽい。CSIDLからテーブルを作るのが楽かと。 SHGetFolderPath() でCSIDLコンプリートをめざすとか >>494
早いですね。
とはいえ、実在するパスからの逆引きだと、「コントロール パネル」とか「プリンター」みたいな仮想フォルダ名は取れない。 PIDLとGUIDをどうやれば結び付けられるか？ え～と 仮想フォルダならレジストリを見る方法があるが、KnownFolderの方が正しい方法に思える。 いや判るだろ
1809 update 入れた後に可笑しくなったんだろω 1809以降の挙動ならプログラムじゃなくてWindows側の問題みたいですね
BitBltだけじゃなくプレビューにも問題出てるからバグっぽいですし
そのうちアップデートで治ることを期待しつつプログラムでの対応は諦めます
いろいろ答えてくれた皆様ありがとうございました ありがとう。だがしかし別のアプローチで
俺が解決したい（本当の）問題は解決できていたのだよ
まあ誰かの役に立つだろうから放っておいたけどな
すまんなｗww アップデートで直るかっちゅーても挙動自体は描画の最適化とも言えるので仕様としてこのままいきそうだけどなあ
自作ので試してみたけどやはり一部でも画面外に出てると無効領域をクライアント全体と指定しても
強制的にクリップされたHDCが返ってくるね
BeginPaintだけじゃなくてWM_PAINT外でのGetDCでも同様
DXGI swap chainが出力先ならクリップされない
普段窓を画面外に追い出したままにするってことがないから気付かなかったなコレ SetForegroundWindowでフォーカスを奪えない、
入力中にフォーカスが奪われるとウザいからWindowsが
奪えないようにしてるって話はよく聞くと思うけど
逆にエクスプローラが起動すると（バックグラウンドなのに）
フォーカスを奪ってくれて困ってるんだけど対応策ない？
ウザいんだがｗ >>447
さらに追試を重ねていました
悪いときは 10G, うまくいっても 5000G 程度（日によってばらばらです）で
FILE_END ができなくなる現象は、
FILE_END が悪いのではなく、システムで圧縮するように指定するとそういうことがおきることがわかってきました。
Windows もいろいろとあてにならない、もう linux に軸足を移そうか、と思案しています >>510
SetFocus()を使うと好きなコントロールにフォーカスを与えることが出来る。
SetForegroundWindow()は余り効果が無い。 longポインタ引数にintポインタ渡して>>445みたいなトンチンカンな返答する人が何か言ってる >>513
>>445 を日本語に翻訳してみました。
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointer
では api 関数の第二引数は 「LONG」で定義されています。
ここで注意しないといけないのは「long」ではなくて「LONG」。
すなわち LONG は win32api.h で定義されている型です。これが実際の環境ではどう typedef されているかは環境依存です。
それを調べるために >>445 で実際に sizeof(LONG) の値を出力させると sizeof(LONG) = 4
私は >>443 で第二引数に int (そして渡す値は 0) を使っていますが sizeof(int) = 4
値は 0 だから signed/unsigned については問題ない
そして sizeof(int) = sizeof(LONG) だからなおさら問題ないのです。
昔は DWORD (Double WORD) と定義されていましたが、1 word = 2 bytes, 2 words = 4 bytes
32bit 環境での普通の int のサイズは 4 なので昔から int を当てて問題なかったのですよ
結論：>>513 >>444 はニワカ、win32api スレに投稿する前に 10 年 ROM ってください DOS窓でprintf出力しながらWin32APIだって使えるからWin環境 LONGは、WPARAMやLPARAMと型変換する危険コードが多い気が。もちろん古いコードだけど。 >>515
だから、あなたは 10 年 ROM ってなさい、ってさっき言ったでしょう？ ここはWin32スレなんだからWin64や総称であるWindows APIはスレ違い
32ビットの話だけしてろ >>519
残念ながらその意見に賛同する人は少数派だと思いますよ > 昔は DWORD (Double WORD) と定義されていましたが
LPARAMは 16bit,32bit共に LONG (符号付整数) >>519
64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ
Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度
つまりスレチでも何でもない double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが >>524
16bit CPUや32bit CPUという言葉と
ポインタ = アドレス幅が違うことは普通にあるってわかってる？
8086は16bit CPUでレジスタ幅は16bitだがアドレス幅は20bit（最大1MB）
80286も16bit CPUだがアドレス幅は24bit（最大16MB）
80386は32bit CPUでレジスタ幅、アドレス幅ともに32bitで
分かりやすい時代がPentiumの第一世代（1995年ぐらい）ぐらいまで続いたが
Pentium Proからは物理アドレス拡張が搭載され32bit CPUだが
アドレスバスは36bit（最大64GB）になったんだが 俺メインフレームでdiagnose命令とかいじくってて
別な案件でhdlでcpu書いたりしてるけど メインフレームw
何歳になってもイキリ小僧してるんだな
サルのパパとママはご存命かい？ >>525
ソフト的なAPIの話に物理アドレス空間で語るバカ乙w 釈迦がどうかはともかく
>>525 が全くトンチンカンなレスであることは事実
いつものあいつだろ >>532
APIの話だというのなら、OSが16bitだろうが32bitだろうが
APIの仕様が代わるわけないんやで
異常事態でもなんでもなく、それが高い互換性の理由だ 64ビット対応で
Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、
DialogProcの戻り値をINT_PTRにしろ。
とかの若干の変更点があるようだ。 HANDLEもこっそりtypedefに_PTR変えたんだっけ ダイアログプロシージャの戻り値がめんどうなことになる
x86じゃBOOLだけどx64だとINT_PTR
でもVC6だとBOOLはintだという 歴史的理由で仕方のない面もあるが、
単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから
型の実態は結局なんなんだ？って悩むことになってる。
もうそろそろネイティブ型だけを使えるようになってほしいが
そのために言語を変えるほうが楽だろうな intとlongのサイズ違うこともあるしな
c#みたいにint32みたいなの最初から用意しとけよ 前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。 32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に
悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか
どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。
恐らく、exeファイルのサイズも増加するだろう。 コンピュータが遅かった時代はCPUに最適なデータ型を
使うことが重要だったが、今は数値型しかなくて
データサイズは自動的に決まりますとかばかりだもんな 64BITポインタptrと配列添え字idxに対して、
ptr[idx]
と書いた場合、idxが32BITと64BITだと実は、32BITの方が
1クロック増えてしまう可能性が高い。なぜなら、マシン語レベルでは、
上記の演算で、ptrは64BIT整数として扱われ、ptr[idx]は、
*(ptr+idx)として処理される。ところが、64BIT+64BITの整数演算は
あるが、64BIT+32BITの整数演算は無い事が多い。なので、
idxが32BITだと、いったん、64BITにBIT幅を拡張する命令を1つ
挿入する必要がある。
だから、64BITポインタのアーキテクチャだと、idxも64BITにした方が
速度が上がる可能性が高い。 >>544
>今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな
C++だと今でもデータサイズは明示します。 >>546
他の言語の話や。今は速度よりも利便性のほうが重要や >>548
例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている
わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、
整数は32BIT整数型までだと double型に精度を落とすことなく完全に
収まるので、何も考えずに正しく扱えるだけです。
JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。 >>549
また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、
console.log(54 / 10);
とすると、5.4と表示されます。これは、54や10が整数ではなく、
54.0 や 10.0 という double 型浮動小数点として扱われているためです。
これは、Sun/Oracle の Java とは全く結果が異なります。後者では、
54/10は、「整数除算」なので、結果は整数の「5」となります。 > JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
64bitも使うのかって話なんだけどな？ 52bitで十分だろう？
https://sbfl.net/blog/2018/06/18/javascript-bigint/
> JavaScriptのNumber（数値型）は倍精度浮動小数点数となります。
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。 なんだ。JavaScriptにBigIntあるじゃん
Numberで表せる最大の整数値は十分な値にも思えますが、
分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。
BigIntは、任意精度の整数を表す新しいプリミティブ型です。
任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。 やっぱりどんなときでもプログラマがデータ型を
選んでくださいっていうのは時代遅れだと思わ >>553
自動化することは可能ですが、現在の技術でそういうところまで自動化した
言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる
かも知れません。これはコンパイル意を作成した経験に基づく話です。
もの凄く厳しい世界が実はまだ沢山残っています。 >>554
誤：かも知れません。これはコンパイル意を作成した経験に基づく話です。
正：かも知れません。これはコンパイラを作成した経験に基づく話です。 100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ 今より100倍遅かった時代もあるのに
何を言ってるんだろうか？
それこそ時代遅れの感覚 あと、「かも知れません。」とかいう推測はどうでもいいから
コンパイラを作り上げた俺が言うのだから
説得力は高いだろうし >>555
GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような
例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を
floatや整数型などにバラして処理するので数10倍かかります。
なので、慎重になる必要があります。
CPUの場合でもintとdoubleで速度がかなり違うことが多いです。 あと極まれにスピードが重要な部分があるから
全部スピード重要視しろとかいうアホな感覚なｗ
あれはやめてほしい。
極稀に重要なら、極稀に使うものを作ればいいだけ
よく使うものを短くする。（仕事の）圧縮の鉄則 >>558
あなたより私の方が良いコンパイラを作っている可能性も有りますよね。 >>560
自動化の道は検討の価値はあるでしょう。
しかし、int32型とint10000000型を自動的に取捨選択できるほど、
コンパイラが賢くなるのは恐らく遠い未来です。
どこかで機能制限や精度を人間が指示する必要があると考えられます。 >>561
そういう俺のほうが優れてるとか言う主張をしたいなら、
個人を特定できるような情報をだせ >>562
コンパイラが無理なら実行時にメモリ拡張すればいいだけ
そういうことも思いつかないから、その程度止まりなんだよｗ >>564
それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、
OSなどの作成には向いていない言語になるでしょう。 大胆に変数はすべて128bitしかないという言語だって考えられる
最大 340282366920938463463374607431768211456 までしか扱えないが >>566
そんな言語が今はたくさんあり実用化されています。 >>567
64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。
あなたが普段使っているコンパイラも、非常に細かい高速化を施して
あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの
動的言語では達成できません。
例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ
から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。
あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。 >>568
有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの
メジャー言語ではそのような方針はとっていません。 >>564
「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。
全く発表してませんから。 スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ > つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
ひどい説明だな
どのくらいひどいかというと
WM_SYSTEMMENU並み >>575
NULLは0だから～
site_tはどうせintだから～
こういう馬鹿なハケンが一人いると崩壊するよね とか言うやつほどnullptrのことを知らなそうｗ #ifdef _WIN64
#define BOOLX64 INT_PTR
#else
#define BOOLX64 BOOL
#endif
BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp)
こうやって回避してるわ Windowsのデータ型だけのヘッダファイルって無いかしら？
データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、
APIのヘッダファイルはincludeしたくない。
APIを直接使うのは面倒だから、全部ラップしてるんだよね。
だから他からは使えないようにしたい。 横にそれるが
データ型もAPIの一部だと思ってるがあってるよな？ 普通のアプリならMFCが一番だと思うんだがなあ
変に角を丸くするとか透明にするとかされても使いにくいだけだろうに むしろMFC = 角を丸くするとか透明だろ
MFC以外でそんなの見たことないわｗ あんまりMFC関係なくね？
WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで
MFCはラッパーとしての薄さがありがたいだけやん MFCはかゆいところに手が届かないからな
廃れたWTLがいい >>591
WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。
https://git.code.sf.net/p/wtl/git 廃れたかどうかは、使ってる人がいるかどうかであって
作っている人がいるかどうかではない あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ タスクマネージャもよく後ろに移動する時あるけど何なのあれ API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる タスクバーより手前にくる時もある
別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど TOPMOSTなんて思い上がった言葉ですぐ気がつけよ
スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが >>604
こりゃ失礼、ありがとうございます
なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか……
PC98じゃあるまいし、言われて見りゃ無理くさいすね
画面上の変化を監視して作業自動化する様なのを頼まれたのですが、
監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします GetPixelって内部でどうやってるのかな
毎回呼び出すと遅いんだよね 故意に減速してるようだね
ビットマップオブジェクトにキャッシュしといて
そこから取ると普通の速度になる 仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが
今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな XPでは爆速だったのがVistaから突然遅くなった TOPMOSTの競合の話ではない
"ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。"
"•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。" それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
例えたった1点の色であっても、非常に沢山のCPUパワーを必要としてしまう可能性が
ある。仮想VRAMにキャッシュしておけば高速化できる可能性は高いが。 >>615
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、 >>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う～ん
呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな > 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった >>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら
もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。
最小化したときはアプリ側で描画止めてるソフトが多いけど
それでも最小化した時点の縮小画面は見れるし
Windows VistaのAeroから変わってるんだわ。
半透明処理もGPUにやらせてるからWindows 2000の頃と違い格段に軽くなってる。 >>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。 昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。 でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない 同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。 >>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。 いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。 どっかで阿鼻叫喚が始まる予感
ttps://twitter.com/MurakamiShinyu/status/994781934407553024
https://twitter.com/5chan_nel (5ch newer account) お
いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし >>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応 「ワールドワイド言語サポートで Unicode UTF-8 を使用」をするとどうなるか？
Unicode対応のアプリ・・・設定とはとは無関係にUnicode対応
Unicode非対応のアプリ・・・
日本語アプリはcp932でないと動かない。
ASCIIしか使えないアプリはcp932でもUTF-8でも動く。
UTF-8に対応したアプリは現時点ではまず存在しない。
この設定は今後UTF-8に対応したアプリが作られたときのための設定
この設定はデフォルト値でしかないのでUTF-8にしてもchcp932相当のことをすればcp932アプリは動く
互換モードの設定でコードページを指定できるようになるかもしれないね いまだにファイルパスがユニコード対応してないアプリあるからな。氏ねと言いたくなる >>643
コマンドプロンプトはUnicode対応だよ
cp932の状態でもdirでUnicodeのファイル名表示できてるじゃん chcp 65001
でバグバグになるのいつ治るの >>646
表示が崩れる問題なら直ってる。
動作自体なら以前から問題なく動いている。 >>641
こういう流れになってますが
ttps://twitter.com/unagix/status/1198150980317016065
動かなくなるんじゃなくて、破壊されて動かなくなるのが正解なのでは？
https://twitter.com/5chan_nel (5ch newer account) >>648
破壊されて動かなくなるとは、一体どこにそんな証拠があるのでしょうか？ 全てのA系APIがUTF-8をI/Oするんじゃろ？
非対応アプリがテキスト系ファイルI/Oしたら死ぬのでは？ >>651
WindowsはUnicode対応なので関係ない話
非対応アプリが動かなくなるだけ だいたい全てのA系APIがUTF-8をI/Oしたからって
何の問題があるんだ？
今までだってそれは、全てのA系APIがSJISとかASCIIとか
韓国や中国のなにかに変更するスイッチだっただろうと
そこにUTF-8が増えただけに過ぎない。 Windows自体は昔からUTF16だと思ってたんだけど、
いつのまにかUTF8になってたの？ >>654
Windows NTはUTF-16だよ？
この設定はUnicodeに対応してない古いWindows 9xアプリのための
互換モード設定だから
将来的に互換モードとして使っていたこの機能をUTF-8アプリの
移植用に利用しようとか考えてるんでしょ？ Linuxアプリのこともあるし。
WindowsネイティブのUnicode（UTF-16）モードとは別に
UTF-8モードが追加されたってだけの話 >>652-653
>>651
A系アプリの問題の話なのに、なんでWindows自体の話になるの？
てか、>651のみならずリンク元の流れすら読んでない感じ？
まあ実際俺も試したわけじゃないけど、書いてることが事実だとすると
設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ > A系アプリの問題の話なのに、なんでWindows自体の話になるの？
A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
Windows APIの話なんだからWindowsの話だろ？
Windows自体はWindows APIのW系（Unicode）を原則として使用してるが
古いアプリのためにA系のAPIも提供してる。Windows はW系を使ってるので
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
したところで何の影響もない。影響があるのは古いアプリのみ
> 設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
それならデータ消せばいいだけだろ。アプリの都合なんか知るか >>658
>それならデータ消せばいいだけだろ。アプリの都合なんか知るか
だからそのアプリの話を一貫してしてるんだけど？
アプリのデータを消す？
大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
システムプロファイルも全て戻らないということなので、戻したら動く保証はどこにもない
何度も言うけど、A系アプリの話だからな？
例えばCの話をしてるのにJaveや.NETが今は主流だからCなんて知らん
って的外れなこと言ってるだけだお前は >>660
何が言いたいのかわからん。
アプリが動かなくてなってもWindowsは問題なく動くだろ
SJISにしか対応してないアプリのコードページを変えてデータが壊れたって
それはアプリの動作保証外の使い方をしたからってだけで
OSのせいでもアプリのせいでもない。
データ消えたら困るなら保証外の使い方をするなよ。
バックアップぐらい取れ。 英語圏の人間向けであって、日本人が使うオプションじゃないからな
大手のソフト含めて対応してない（設定変えるとおかしくなる）のは山ほどあるよ >>660
君はちょっと落ち着け
>>648の内容はシステムの設定を元に戻せないという話であって
アプリの話じゃないだろ
そして
>大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
だったらβの機能なんか使うなよ、で終わりだよ
βじゃなくなるときに、キレイに全部戻せるようになってるか、
SJISアプリは切り捨てますって発表があるかのどっちかだろ >>661
なんでWindowsが動かなくなる（だったりWindowsの問題や責任）話と勘違いしてるの？
単純に設定変えたらA系アプリに問題があるねってだけの話だぞ？
的外れも甚だしいし視野が狭すぎる
過去資産を使ってるクライアントを持ってたら、この手の話には敏感になるわ
バックアップとかそういう次元の話じゃない
お前みたいなのがクライアントのサポートしたらクライアントが居なくなるレベル >>665
だから何が言いたいんだよ。
cp932前提の古いアプリはUTF-8で動きませんって
当たり前の話なだけだろ つーか、最初っから俺が言ってるんだわ
641 自分：デフォルトの名無しさん[sage] 投稿日：2019/11/26(火) 11:36:11.45 ID:fVihpbt7 [1/4]
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応 >>664
> だったらβの機能なんか使うなよ、で終わりだよ
まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
割を食うのはこっちになったりすると目も当てられんからね
>>666
そんな当たり前の次元の話を一切してないからね ふ～ん
Pythonで問題起きるのか
Rubyはどうなんだろ 上の >>662 のPythonの人は
PYTHONENCODING=utf-8の方を気にしてるけど
setdefaultencodingとかはどうしてるのかな >>667
> cp932使ってる古いアプリは、この設定にすると
> 動かなくなるだけ。つまり捨てるしか無い。
この時点で間違ってる
つーかW系A系のAPIの使い分けしたことあれば、A系の動作が変わることでどうなるのか
ってある程度予想できそうなもんだけど、なんでここまで勘違いが続けられるの？ プロファイル壊されるってゆーてるリンクの連中だけが情報量ゼロなの草 結局W系で作るしかないんだから余計なことは考えなくていいよ fopen()の振る舞いで困るかも。Win32のfopen()はutf8を特別扱いするから。 >>671
いわゆるバイナリモードを使うとBOMがついてきちゃうとか、
いろいろトラブルが発生する可能性はあるね
前回のアップデートでもコンソールで文字化けする問題があったし
それをざっくり言えば、古いアプリを捨てるか、設定変えんな、
という話になるだろ
APIオタクと運用を見てる人で視点が違うことを理解しなよ
>>668
>まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
それは契約文書にきちんと盛り込むべきだね MultiByteToWideChar/WideCharToMultiByteの第一引数にシフトJISコードページ932を指定しないといけないらしい。CP_ACPだと死ぬ。 >>672
壊されないよ。日本語が化けることはあっても
それは想定とは違うデータが入っただけだし
アプリの問題 シフトJISテキストファイルにUTF-8テキストが混ざったら、そりゃ文字化けするでしょう。 コードページを変えると文字化けするだろうね
それだけの話。別に動かなくなるわけじゃない。
コードページをもとに戻せば動く
壊れたデータは直せばいいだけ main()に渡される引数文字列argvどうなります？ 自前で先行バイト検出しながら文字列書き換えるような関数とか如何すんのよ >>682
Unicode非対応アプリのmainだとして、
Unicode対応アプリ（からUnicode APIを使って）呼び出せば、引数全てがUTF-16からUTF-8に変換されてから
呼び出される。Unicode非対応アプリから呼び出せば、渡した文字列（バイト列）がそのまま渡される。
そこは今までと変わらない。今までもUnicode対応アプリから呼び出せば、設定されたコードページ（例えばcp932）に
変換されて呼び出される。違いはUTF-16からUTF-8だと変換できない文字がないので文字化けは一切発生しない。
なお、渡されたからと言ってアプリが正しくその文字列を扱えるかどうかは別の話
結局の所cp932専用で作られたアプリは完全に同じようには動かない。（ASCIIの範囲でなら問題ないだろう） >>683
実装と場合（データ）によるとしか言えない。
Unicode（UTF-16）非対応の古いアプリは、想定したコードページでしか
まともに動かない。それだけの話だよ。 あと、システムプロファイルとか意味不明。
何の話をしてるのかわからないレベル。 ちなみにUnicodeから非Unicodeへの変換は変換できない文字があるから一部文字化けするが、
非UnicodeからUnicodeへの変換では文字化けすることはない。
だから、cp932を扱えるアプリがcp932でレジストリ（UTF-16）に書き込んでも
適切に変換が行われるし、そのアプリがUTF-8を使えるなら、それもレジストリに書き込んでも壊れたりしない。
例えばアプリ（cp932）から レジストリ（UTF-16）に書き込んで、
レジストリ（UTF-16）を アプリ（UTF-8）から参照することは問題なくできるということ >>685
非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
そこにUTF-8とかねじ込まれても困るわ もちろんレジストリ（UTF-16）をアプリ（cp932）で参照したときは扱えない文字列があるが、
それはファイル名（UTF-16）をアプリ（cp932）で扱えない文字があるという程度の話でしか無い。 >>688
お前は意味がわかるように書き込め
> 非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
どういう使い分けがされてるのか書け
> オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
それって引数がWCHAR *ならW系が使われて、引数がCHAR *ならA系が使われるってだけだろ
> そこにUTF-8とかねじ込まれても困るわ
そこにってどこよ？何が困るんだよ。
UTF-8はCHAR*を使うって理解してるか？
今までA系はASCIIだけでなくSJISや多数の文字コードで使われていたというのに
UTF-8が増えたごときで何も困らんだろ >>690
鬼門っていうか、単にUnicode非対応のアプリは
想定しているコードページに変換できない文字を扱えないってだけだけどな
たったこれだけのことなのに何をグダグダ言ってるのかわからん >>684
UTF8アプリなんて存在するんだっけ？ >>691
たとえUnicodeに対応しているプログラムであっても何らかの出力ファイルをSJISで出力するような構造だと、
それを勝手にUTF-8に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな >>694
まずないだろうね。作れるようになったのは最近だし。
念ために言っておくけど、ないっていうのは
Unicode対応アプリではない（＝A系APIを使う）かつASCII文字としてUTF-8を使うアプリのことね。
UTF-8はUnicodeだろというツッコミはいらん。
WindowsにおいてUnicode対応とはUTF-16アプリのこと
最近Unicode非対応の古いアプリでもUTF-8が使えるようになったから、
古いアプリをUTF-8用として作り直して新しくすることでA系のまま
Unicode対応にできるとかいうジョークのような話ｗ
それするぐらいなら最初からUnicode対応として.NETとかで作りますわ。
完全に将来のLinuxアプリなどの移植用。多分最終的にマニフェストとかで
このアプリはUTF-8アプリですって指定できるようになるんじゃない？ >>695
だからなんなんだよ？
当たり前の話するな。OSともアプリとも関係ない話だわ
LinuxでもMacでも同じことは起きるわ。だからなんだんだよ >>698
勝手に文字コードを変えんなってだけやろ
利用者の意思で変えさせろと クッソ伸びてて草
MBSCなソフトがA系APIでデータ読み書きしてたら非対応のUTF8に書き換わってて、
以降データが文字化けしたまま困ることになるんだから、元に戻せばOKとか非対応なんだから
仕方ないとか、こればかりは擁護不可能の的外れ
表示だけの問題じゃなく記録データにも影響があって、こいつばかりは復元ソフトでも組まないと戻せない
MBSCなソフトは使えないだけならば、単純にA系APIを廃止すればいいだけなんだが
MSはお節介にもどうにかして過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
用意したって点だけ見ても、単純に非対応とか元に戻せばいいというような話ではない
年末にお父ちゃんから、古い宛名印刷ソフトのデータが壊れたって連絡が来るかも知れないくらいには、
時と場合によっては取り返しが付かない
今のところデフォでこの切り替えは無効だが、将来もしかしたら～というのが現時点でのキモだろう >>701
そんな長々と書かなくても、
SJISのファイルにUTF-8で書き込んだら文字化けしたのと同じことでしょ
そんなのLinuxでもmacOSでも起きる問題だって言ってるんだが >>701
> 過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
意味不。単にUTF-8にも対応したってだけ
コードページを一つ増やしたに過ぎない。
A系の挙動は昔から設定で変更できた。 もしかしてこいつは、ユーザーが設定変更しなくても
アップデートで勝手にUTF-8に変わるとか思ってるのか？
ならものすごくマヌケだｗ >>700
編集して上書きしたらUTF-8に変るんじゃなく新規での作成がUTF-8になるだけ？
それなら俺の誤解だったわ
勝手に変えるのなら死ねだが 本当にアホだったな。ユーザーが意図的に変えない限り変わらないってのに 論旨はは>>638よりは>>648みたらはっきりしてる
”安易に設定変更したらA系使ってるソフトが恐い”ってことだけであって、”問題ない”
と連呼してるアホ一人が理解力0というかマイナスなだけ しかもエアプなんだろうな。
>>638は古い情報で、
そもそも「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用」の設定と
『メモ帳の文字コードと全く関係ない』話だってのもわかってないんだろう
『当時』はたまたまそこの設定がデフォルトになっていただけで、
今は常にUTF-8（BOMなし）
メモ帳は古いアプリでもなんでも無いしな
で、メモ帳が保存するテキストファイルの文字コードと
古いアプリの挙動も全く関係ない話。そんなの考えるまでもなくわかること
こいつずっとテキストファイルのデフォルトの文字コードと
APIの話をごっちゃにしてたのかよ
完全に素人だ >>710
言っとくが俺と>>701は別人だからな >>709
>”問題ない”と連呼してる
連呼の意味わかってる？ｗ
”問題ない”で >>638以降のレスを探すと
>>684で一回しか書いていない。しかも関係ない話
お前は思い込みが激しいってことがはっきりわかったな はい、論点誤魔化してきたね
未だに文字化けする程度の認識しかしてないから、話するだけ無駄だと思うよ
メモ帳とか連呼の定義とか持ちだしてきてもう意味不明
そもそもWinAPIのプログラムも組んだことないの丸わかりだから、キチガイに付き合うだけ損 例えば標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
そんなの使ってたら、ファイル前半はシフトJIS、後半はUTF8になって、どっちでも読めなくなる
これは極端な例だけど同じようなことはそこら中で起こりえる >>709
んだ
>>714
そうだね
単純にそういう話になると思ってたんだが、このスレでこのレベルの未経験者が話しに入ってくるとは思わなかった はぁ、リンク先も読んでないのかよ
>>638のリンク先読めよ・・・
https://twitter.com/MurakamiShinyu/status/994781934407553024
> 今までデフォルトでShift JISだったもの（メモ帳をはじめ…）が
> この設定をすると「メモ帳」の「名前を付けて保存」で「文字コード: ANSI」
> （デフォルト）だとBOM無しのUTF-8、「文字コード: UTF-8」だと
> BOM付きのUTF-8のファイルになります。
↑注意 これは古い話で今は当てはまらない
https://twitter.com/5chan_nel (5ch newer account) >>717
> 単純にそういう話になると思ってたんだが、
その話は当たり前で、LinuxでもmacOSでも同じことになると
さんざん言ってる ちなみに
> 標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
これはコードページとは何の関係もない。
当たり前だがSJISで出力してるアプリは、
コードページをどう変更しようが、SJISで出力される。
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
チェックを入れたところで、SJISで出力してるアプリが
UTF-8で出力するように変わることはない。 設定変更しなければ良い、ってのは利用者の目線で開発者の発想ではないわな >>658
＞A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
＞Windows APIの話なんだからWindowsの話だろ？
win32api には同じ api 関数に対して A 系と W 系の二つの異なった関数が準備されているんです
A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います >>674
win32api に fopen は存在しません、CreateHandle ならば存在しますが もちろん、「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
の設定（コードページ）を見て、アプリ内部でその文字コードに変換して
出力するように作られてるアプリは別な。
あくまでA系APIを使ってるアプリの話
SJIS前提で作られてるアプリは、SJISでしか出力しません。
ただしAPIがUTF-8前提として処理するのでASCII以外だと
出力がおかしくなります。 >>722
> A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います
うんしってる。そして新設された「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
というのは、A系を使ってASCII互換のUTF-8を使えるようになる機能です。 問題のオプションが A系 W系に関係するものか、誰か見解を出していただけませんか？ >>718
>>648読んでる？
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
>>719
> その話は当たり前で、LinuxでもmacOSでも同じことになると
> さんざん言ってる
今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
>>720
> 当たり前だがSJISで出力してるアプリは、
> コードページをどう変更しようが、SJISで出力される。
君は、
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
これ自体がウソだって言ってるんだね？
ダラダラ連投せずに、そう書けば？ >>728
> 今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
だから他のOSでも起きる、SJISのファイルにUTF-8で書き込むと壊れるという話を
ごちゃまぜにするなと言ってる。
それはWin32APIと関係ない話だと言ってるだけ >>729
> SJISのファイルにUTF-8で書き込むと壊れるという話を
なぜそのようなことが起こるのか、どういうきっかけで起こるのか、影響範囲はどうなっているのか、
A系APIの挙動が変わるからだ
という話なだけでしょうが
他のOSを例に出す意味がない
君の主張は、APIの挙動は変わらないということなんだね？
要点をまとめなよ >>728
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
「ダウト」なのの１つ目は「半端ねぇ」の部分。
A系APIは昔から、コードページの設定をみてそのコードページの文字コードを
前提として処理している。昔から当たり前のことで今更驚くことじゃない。
英語ならASCIIを前提として処理するし、日本語に設定すればSJISを前提として
処理するするようになるし、韓国語や中国語にすれば、その国文字コードを前提して処理する。
20年以上そういう機能だった。
そしてもう一つはI/Oするって所。APIが設定に応じた文字コードを前提とするだけで別にI/Oするわけじゃない。
どの文字コードを使うかはアプリによる。SJIS専用のアプリはSJISしかI/Oしない。
UTF-8を前提としてる状態でSJISを流すとおかしくなるというだけで、
それらのAPIがUTF-8でI/Oするように変わるわけじゃない。
（エラーメッセージとかはSJISのリソースを使うようになるが、
これはAPIが変換してるわけじゃなくコードページに応じたリソースに変えてるだけ） >>730
要点 「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」の設定によるAPIの挙動と
アプリが入出力する文字コード（ファイル等を含む）は関係は一切ない
アプリが入出力する文字コードはアプリの実装によって決まる。
（Win32 APIと関係ないから、他のOSも同じという話につながる） APIの挙動変るのはやっぱヤベーな
iniから文字列を取り出す >UTF-8
今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
これを利用したディレクトリトラバーサルとかも可能なんじゃね？ >>734
VC のドキュメントがなんの役に立つ？ 他のソースはないかな。
βとはいえMSが単なるロケールの追加じゃなくてそんな過激なスイッチを導入しようとする意図がよくわからん。 英語圏だと切り替えても英語入出力だけするなら何も変わらないしメリットの方が多い
日本語圏じゃデメリットしかないがｗ >>719
> その話は当たり前で、
本当？
SJISアプリをUTF-8アプリとして動作させるんだぜ？
printf("あほまぬけ\n"); こんなアプリがあったときに、
設定前と設定後で出てくる文字コードが違うんだぜ？
Linuxでそんなことが起こるかよ。 >>737
シングルバイトアプリがマルチバイトアプリとして動くわけ？
もっと変なことになるだろそれ _tcsincなんかマルチバイト前提にしか使わないような関数だろ
どんな挙動になるんだ 「ワールドワイド言語サポートで Unicode UTF-8 を使用」にチェックを入れ
なければUnicode非対応のアプリは従来通り動くし、これにチェックを入れな
ければ動かない既存のアプリっていうのも現状では無いんでしょう？
非対応アプリを対応させるのに要するコスト以上の利益が今後見込めるなら
アプリ開発元も対応させるだろうけど、そうでないなら放置されるんじゃ
ないかなあ。
MSがUnicode非対応アプリを切り捨てるようなことをすれば、Windows離れ
(＝パソコン離れ)が進むだけでしょ。 CP1252のアプリにUTF8突っ込まれてもやっぱり困るだけだよなぁ。 いきなりなんとかアプリで括るから話が噛み合ってないのでは？
まず確認すべきなのはAPIの挙動がどう変わるのかで、
次に典型的なsjisアプリでAPIをどう使っているのか
だから影響はこうだみたいな
誰か整理して教えて >>738
> printf("あほまぬけ\n"); こんなアプリがあったときに、
設定後は文字化け出力 >>731
こちらの論拠は全てこのツイートにあるしこれベースで話していたわけで、
最初から君の主張がそれなら話が早かったんだけどね
端からAPI関係ないと言われても話が通じず意味不明にしか思わない
しかしはっきり言って、どっちも信用ならんｗ
自分でテストするしかないわもう ググってみて気付いたが一年以上前の話題なのね、これ。 >>738
> 設定前と設定後で出てくる文字コードが違うんだぜ？
違うという証拠は？
printf("あほまぬけ\n"); と書いてコンパイルしたとき
\0で終わるSJISのバイト列が格納されてるに過ぎない。
それが設定で変わるわけ無いだろ。 >>733
> APIの挙動変るのはやっぱヤベーな
それは英語圏のASCII前提で作られているアプリでSJISを使うと
\（0x5c）が含まれる「表」などで誤動作するって話と同じこと
http://www.kent-web.com/pubc/garble.html
> 今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
> これを利用したディレクトリトラバーサルとかも可能なんじゃね？
UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。
というかそもそもが「英語圏で作られた日本語などを扱えないUnixアプリ」でこのような問題が
起きないように考慮されて作られたのがUTF-8だから >>747
A系のAPIがUTF-8に変換されるってのは、そういうことだろう？ >>748
>UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。
ねぇねぇ？
大丈夫？ >>743
> まず確認すべきなのはAPIの挙動がどう変わるのかで、
WindowsはUTF-16。ファイル名などOSから文字列を受け取るときに
A系APIを使うとシステムロケールの設定で設定された文字コードに変換されて渡される。
またOSに渡すときはUTF-16に変換される。
これは標準入出力やファイルに出力するときには全く関係ない。
SJIS前提のアプリがSJISで出力するとき（つまりA系APIのみを使ってる）
変換は一切されない。SJISで出力される。
Unicodeに変換されるのはアプリが_setmode等を使ってファイルハンドルを
Unicode出力モードに意図的に変更した場合。（OSのシステムロケールの設定で勝手に変わるのではない）
そしてこの話はUnicode出力する話で、今はSJISで出力するアプリの話をしてるのだから関係ない。
SJISで出力するアプリはシステムロケールの設定が英語だろうがUTF-8だろうが常にSJISで出力される。
だから英語モードのコマンドプロンプトはSJISを理解できないから文字化けする。
chcpでコードページを932にすると「Unicode出力モードではない出力」は、SJISとして扱うので
出力を "受け取った側" の ”コマンドプロンプトが” Unicodeに変換して画面に出力する。
出力側でAPIが勝手に変換しているのではない。 >>749
> A系のAPIがUTF-8に変換されるってのは、そういうことだろう？
違う。WindowsネイティブのUTF-16が、A系APIを使ったときにUTF-8で渡ってくるというのは
APIの引数の話であって、printfなどの標準入出力やファイル入出力とは関係ない。 >>753
printfは内部でWriteFileを呼んでるよ？ そこまで調べたなら、WriteFile、ReadFleには
AやWという区別がないところまで調べようか？
これはバイナリで読み書きする。必然的に文字コードの変換など起きない。 dirコマンドはUnicodeでコンソールに書いている例
cp932でもUnicode文字のファイル名を表示している・
これを踏まえて>>756お前がどうなるのか書けや
実は知らんのだろ？ UTF-8は文字の一部にASCIIコードが含まれることはない
とか言っちゃう人に説明しても無駄だと思うからやめとく そこは単なる表現ミスだろｗｗ
ID:j6pNPBz/ は言ってること基本的にあってる
こいつはどうか知らんが、このタイプのやつってやたら自信と知識あるのにプログラミングできないことが多い Code Pages
https://docs.microsoft.com/en-us/windows/win32/intl/code-pages
Many Windows API functions have "A" (ANSI) and "W" (wide, Unicode) versions.
The "A" version handles text based on Windows code pages, while the "W" version handles Unicode text.
Windows code pages are also sometimes referred to as "active code pages" or "system active code pages".
A Windows operating system always has one currently active Windows code page.
All ANSI versions of API functions use the currently active code page. 頭でっかちって奴？
装備は良くてもと実力が・・・的な >>758
SJISは「表」のように文字の一部に「\」が含まれることがある。
UTF-8では文字の一部にASCIIコードが含まれることはない。
反例があるならどうぞ 素人ですまんが"a"の文字コードはUTF8ではどうなるの? ASCIIと全く同じ。そして他の文字の一部に含まれることはない。 >>733が
> 今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
と書いてるから\にしただけの話
ダメ文字の定義なんて無いし >>762
マルチバイトの文字の2バイト目以降にASCII文字が含まれることはない、とか言えば相手に誤解されないんじゃないか？
相手が理解してない、間違ってると決めつけるのでなく、自分の意図が正しく相手に伝わってない可能性があることに想像が至らないのかな。
いつも他人と衝突してばかりで(主に周囲の方が)苦労してそう。 APIの挙動は変わらないから問題ないっていうのなら、本件のスイッチはなんの意味が？
実際に、表示に問題が出たりpythonで問題が出たりしてるけど、原因は何？
このスイッチで何が起こっている？
本当にロケールの変更だけなのか？問題ないならスイッチなんか付けずに勝手に処理変えていいのでは？
この説明をして初めて問題がないという事に説得力が出るんじゃないの？ > APIの挙動は変わらないから問題ないっていうのなら、
誰もそんなこと言ってない。スレ読み返してお前がどれにレスしてるのか言ってみろよ。 >>764
つまり、UTF-8にASCIIコードが含まれるんだよね。 >>769
問題ないし関係ない主旨の書き込みを繰り返しされてたよね
要点はこれらしい>>732
>>770
すっごい抽象的で意味分かんないだよね
関係ないって言ってるその内容そのものが一番問題なはずなんだけど まあちゃんと問題切り分けできてないのがヤバイヤバイゆーてるのが気にくわんのとちゃうの
なんか知らんがユーザープロファイル壊れたハンパねえとか
具体的な問題点あげさせたら>>754,756みたいにまるで理解してなかったりとか 問題起こす可能性ある行為
文字列に対して0x81～0x9f以下だからみたいな全角半角判別をする(やりたいならutf16にしてからする)
printf("死ね")というようにソースに文字列を直接書く(文字列は必ずリソースから使う。utf8リソースも用意する)
文字列をエンコード変換せずにファイルに書き込む(cp_acp使って変換する) >>722
LoadLibrary には A と W があるのに
GetProcAddress には無いんだっけ
なんでだろ
LoadModule は忘れた LoadLibraryの引数はファイル名なんだから9xとNTで文字コードが違うけど
GetProcAddressの引数の関数名はASCIIしかないからでしょ ユニコードビルドのプログラムならまず問題は起きんよ
あえてCHARを使うケースなんて限られているしそういうとこはAPIを介することもない
printfなんか使わず_tprintf使うしな
問題は過去に作られたマルチバイトビルドのモノ Unicodeしか対応するつもりがないのでwprintfを使う。 CP_ACP を使うのは別に悪くないぞ
active code page なんで文字通り動作時の CP に合わせて
良きに計らって変換してくれる
CP が utf-8 なら 入力も出力も CP_ACP で utf-8 と変換
CP が cp932 なら 入力も出力も CP_ACP で cp932 と変換
これは正しい動作
ただしソースが SJIS 固定で書かれてるのに
CP_ACP 使って Unicode に変換して出力してる糞ソフトは可笑しくなる CP_ACPってGetACPで返ってくるのと同じものだろ？
active code page じゃなくて ansi code pageの略みたいだけど
これchcpしたコマンドプロンプトから呼び出しても変わってないやん。
これWin9x系対応かつ多言語対応のGUIアプリを作るときしかまともに使えないんじゃね？
今どき多言語対応にするならUnicode使うだろうし、古いアプリの
メンテナンスなら仕方ないけど、20年近く前のアプリ？ｗ
今の時代にcp932が登場するとしたら、バッチファイルから実行される
コンソールアプリぐらいだろうけど、chcpで変わらないのだから
chcpのデフォルトになってしまうCP_ACPでは機能不足だよ >>771
「表」に含まれる「\」のようにASCIIコードが文字の一部には含まれることはない setconsoleoutputcpとかいくつかあるだろ >>784
そんな素人にとってすら常識なことを言わないでくれ。 >>788
つまりCP_ACPじゃなくてSetConsoleOutputCPを使っていう話だよね >>776はファイルに書き込む話だからcp_acp。setconsoleじゃない これって将来OS内をutf8にする布石だったりする？ 質問
1..ソースファイルのフォーマットはどうするべき
2.StringCchPrintfAはcrtに丸投げしているようだが使っていいのか ソースのエンコードなんてどうでもいいよ
APIの挙動は何も変わらないからStringCchPrintfA使っても問題ない
いわゆるc言語の教科書に書かれてるようなソース書いてたら問題起きる
ローカライズ、グローバライズ、多言語、その辺を意識する必要があるってだけ >>794
どうせVisual Studio使うんだろ？
ならソースコードのエンコードはデフォルトのUTF-8（BOM、シグネチャ付き）
UnicodeでないとUnicode文字が書けないだろ？
ソースコードにASCII文字しか書かないなら、UTF-8でもいいがそれは
結局SJISと同じになるので区別がつかない。SJISと誤判断されないようにBOM付きが良い。
StringCchPrintfAではなくStringCchPrintfWを使え。
今どきはUnicode対応だろ。いつまでも9x対応にしなくていい。 改行コードは、Windowsしか使わないならCR LFでいいが、
俺はWSLからも参照するのでLFにしてる。 linuxのツールなら大抵どっちの改行もOKでしょ
windowsはCR LFだけってのが多いけど LinuxのシェルスクリプトはCR LFだと動かないぞ
むしろWindowsツールのほうが両対応してるのが多い >>795
strsafe.hを眺めると、StringCchPrintfはAPIではなく、_vsnprintf_sに行き着くように見えるのだが、そのまま使ってよいのか
>>796
char[]でファイルとやり取りする仕様なのでUnicodeにはできない
BOM付きUTF-8には抵抗がある >>800
ソースコードの文字コードとコードは関係ない。
> char[]でファイルとやり取りする仕様なので
ファイルとやり取りする所だけ変換すればよい
ってか、本当にUnicode非対応のアプリ作ってるのか？ > StringCchPrintfはAPIではなく、_vsnprintf_sに行き着くように見えるのだが、
正直、StringCchPrintfがなんでAPIなのかの理由のほうがわからんのだがな
処理内容的にOSとやり取りする理由がないので
APIやない方が理解できる。
というかMS専用関数じゃなくて_vsnprintf_s使ったら？
まあ俺はC++使うんだけどさ。std::wstringとか APIだと脆弱性見つかった時の修正が楽
組み込み関数だと全アプリ作者に修正促さないといけないし、現実的に脆弱性の修正不可能だからな 現在のウィンドウのIMEの種類を取得する方法ってありますか？
「やりたいこと」
今使用しているIMEがGoogle Japanese IMEかMS IMEなのかどうか知りたい。
ローマ字やかな入力などの情報ではなく、MS IMEや Google IMEなどのキーボードレイアウト？の情報がほしいのです。
GetKeyboardLayout関数などを使用してみたのですが、言語別のキーボードの情報を知ることはできるのですが、日本語キーボードのIMEはどちらも同じ値しか取得できません。
調べてもなかなか分からず困っています。Win32 APIで取得するにはどうしたらいいですか？ utf-8 BOMをエラーにするのは正義の戦士だからでは。 ディスプレイの解像度の変更をSetDisplayConfigで作成しましたがDPIの変更の方法が分かりません
DPIを変更するAPIはありますか？ >>807
回答ありがとうございます。
その関数も試してみたのですがどうやっても取得できず、もうお手上げ状態なので諦めました。 >>810
サンクス
非公開のAPIなんだね
何とか頑張ってみる クリップボードのデータのtextって毎回上書きですか？
何回分かのスタックになってないのですか？ >>813
なってない。
というか、クリップボードはテキストとか関係無く毎回上書きされる。
クリップボードに何かが入った時を監視してそれを保存するアプリは組めるし、実際にそういうのもある。 SetClipboardViewer で
クリップボード内容の更新の毎に WM_DRAWCLIPBOARD が飛んでくるようになる 秀丸のコピペとか他のエディタ(viとかemacs)のコピペとかでも
winのクリップボードと共有されてるときと無関係なときがあって
良く判らん winキー + vで履歴がみれるからどこかしらに貯めてるんだろうけど
C#ならとれるみたいだが ちゃんとアプデしてるwin10でなおかつその機能が有効になってないと使えないものをわざわざ使うの？ 趣味なら自分だけ使えりゃいいし、そうじゃなくても最近の開発の流れは最新状態だけサポートしてればいいんだよ
対応環境広く取りたいなら独自実装 動作環境も開発環境も選ぶ状況において、なおかつ今のクリップボード履歴の仕様的に満足できるのか
ってな観点で、もちろんそれで必要十分なら止めはしないが、わざわざ作るんならコスト的にも独自でいいじゃんと思うわけよ >>820
だから使う使わないって話はしてねえっての
話聞いてんのかこのアスペは
何を作るのか要件はなにかも知らないのに何勝手に妄想してんだ >>823
自己紹介だよね？
何を思って817書いてるの？日記だったの？
要件不明だけどこれも使えるよって自分で書いてるんだよね？
使う使わないの話以外に何のつもりだったの？
やっぱり日記だったの？
もしくはこんな知識僕持ってるんだよ！すごいよね！ってことなの？
それならごめんね、すごいすごい ついでに822の補足として書いとくと、以下の仕様をわざわざ限定された環境で作って
限定された内容で実現する意味あるの？
ってのがこちらの趣旨
わざわざ書くのもアホらしいのでコピペだが
・保持できるサイズは1MB未満データ(全体上限は5MB)
・保持件数は、ピン留めを含め50件まで
・履歴の編集ができない
・検索機能もなく、古い履歴を探していくのが大変
・ピン留め以外の履歴は、パソコン再起動時に消えてしまう
・ピン留め履歴をグルーピングできない
・設定・カスタマイズができない
ホントマジで何が言いたくて>>817を書いたのか説明して欲しいな ・保持できるサイズは1MB未満データ(全体上限は5MB) ＝拡張できる可能性ある
・保持件数は、ピン留めを含め50件まで ＝拡張できる可能性ある
・履歴の編集ができない ＝拡張できる
・検索機能もなく、古い履歴を探していくのが大変 ＝拡張できる
・ピン留め以外の履歴は、パソコン再起動時に消えてしまう ＝そういう仕様。問題なし
・ピン留め履歴をグルーピングできない ＝拡張できる
・設定・カスタマイズができない ＝拡張できる
プログラマ次第 Win7厨が死ぬのでAUTO
再起で消えるのはAUTO
MSの気まぐれ仕様変更に左右されるのでAUTO
つか、クリップボードアプリを今さら自製する意味あんの？ 「ピン留め以外の履歴は」だぞ。ピン止めしてれば再起動で消えない
さらに標準機能のままで別のデバイスとのクリップボード共有もできる >>824
要件次第ってことを言わなきゃわからんか？
なんでこんなに頭悪いんだろうこいつ
お前が勝手に脳内で妄想してる要件なんてみんな知らないんだが
使う使わないは質問者次第だろ
だからアスペと話すのは疲れるんだわ >>829
こっちは要件に合致しようがしまいが、そんな限定品をわざわざ使わんでよろしいと書いてるだけ
アスペほど人をアスペ呼ばわりするんだよな ＞そんな限定品をわざわざ使わんでよろしい
でも使っている人がいることを考慮すればOSの機能に統合していくほうが良いのでは？
（あくまで機能をONにしている人の場合はってことね、OFFなら全部独自でも）
ただ、独自にクリップボードアプリ入れている人はそんなOSの機能使ってないだろうから、今更こっちで実装する意味もないだろうし
クリップボードアプリを初めて導入しようとする人に対して、“限定的なOSの機能”を勧めるより独自でいいじゃんってのもわかる
ただすでに使っている人に対して、このソフト使いたいならそんなOSの機能使うのやめてこっちの機能使ってと強制するよりいいんじゃないの
ケースバイケースではあると思うけどプログラマーが機能を限定・強制するより
ユーザが取捨選択できるようにするのがプログラマーらしいと思うんだけど違うんかね？ >>831
要件次第と自分で言いつつ、最後には要件を満たしてるとすげ替えてくる辺りがオツムアウト そもそもクリップボード履歴へのアクセスはWin32API案件なのか？
まあ共有機能以外の魅力は皆無だし、共有ならクリップボードじゃなくていいな >>833
ほんとこいつなんなんだ
おまえの
＞要件に合致しようがしまいが
ってのにレスしてるんだが
このアスペ君はどうしようもないな まあ今はWinRTでもC++/WinRTとかでじゃんじゃかデスクトップからも呼んでいこうぜみたいな方向性だから
Win32APIの範疇でええんちゃう >>835
日本語も理解できないのに、よく日本人のフリするね
「要件に合致しようがしまいが」という言葉は、「要件に一切触れてない」という意味以外に何があるんだよ
＞＞要件に合致しようがしまいが
＞ってのにレスしてるんだが
どうやっても「要件が合致してる」という日本語にならんわ
「アスペ連呼する奴自身がアスペ」だけ正解
>>832
強めに否定したけど、確かにそれが正論よ
でもこのスレで>>813レベルの質問だから、Win32APIどころかWindowsの仕様も
分かってないしクリップボード履歴すら知らんでしょこの人
やりたければ好きにやればいいけど、このレベルでどうせやるならこのスレ的には
王道通って基本知識得た方がいいと思う >>827
今後のアプリはクリップボード非対応であるべきという主張か？ >>837
横からだけど…
「要件に合致しようがしまいが」って言うのは「要件に合致してる」場合も含むよね？
そのケースですら「使わんでよろしい」って言うのは流石にアホすぎる
って言うことまで説明しないとわからないのはアスペ以前のレベルかと >>839
横からだけど・・・
要件に合致しててもそれに見合うリターンがあるかどうかで取捨選択は普通にある
それよりも、要件が分からないままなのに要件に固執する意味が分からない >>841
実際のところ、要件に固執しているのではなく、自分の主張が正しいんだ！議論に勝つのは俺だ！ってところに固執してるだけだろうから議論に参加しても不毛だぞ。 同意して欲しいだけならそう書け
もしくは知恵袋か発言小町で聞いとけ
女の腐ったような奴め >>841
> それに見合うリターンがあるかどうか
広義の要件ってそう言うのも含むだろ
仮に>>830の言う要件にはリターン云々が含まれないとしても見合うリターンがあるケースがないわけじゃないだろうし >>846
その人にとって見合うリターンがなければないんでしょ
見合うと思う人はあるんでしょ
単にそうやって相容れない話があるだけで、要件という言葉について固執する意味ないと思います
それでも要件という言葉の定義に固執するのであれば、まずはWin32APIというスレのテンプレ定義に従うべきだと思います
自分は細かいこと言いたくないですが、要するにスレチです >>847
スレチと言いながら頓珍漢なレスされてもなぁ
> 見合うと思う人はあるんでしょ
それを含めて
> 「使わんでよろしい」
って言ってるからバカにされてることにそろそろ気づけよ…
まあスレチとか言い出してるしそろそろ恥ずかしくて出てこれなくなる頃だと思うがw >>848
ん？横からのふりして本人か
理解できないのを誤魔化しちゃいかんよ
お前という人間をいかに正当化しようが、お前はクソ 居なくてよろしい
クリップボード履歴の機能を使い回すのもクソ 使わなくてよろしい
似たようなもんだ >>848
レス先間違ってる訳ではないですよね？
レスの意味が分からないのですが、見合う見合わないはあなたが判断することではないでしょ
論点は見合うか見合わないじゃないですよということと、言葉の定義にこだわってる（？）なら
テンプレからこだわってくださいねって書いてるだけですが >>850
反論できずに人格攻撃かよw
ダサ過ぎる
>>851
そりゃその理解力だとわからんだろうなw
見合う見合わないの判断を誰がするかなんて話してない
見合う可能性があってそれに対してまでも
> 「使わんでよろしい」
って言うバカがいたって言うだけの単純な話 >>852
自演も隠さねえなｗ どっちがダセえんだよ
カスにカスって言うことに理屈はねえよバカス
使わんでよろしいの真意も書いてるけど、お前は読めないから要件ばかり固執して逃げてんだろ
あと、人格攻撃はお前が真っ先にしてきたことだからな
アホだから覚えてないだろうが >>854
> 使わんでよろしいの真意も書いてる
どこに書いてるのかなぁ？
レス番示して引用してみ
まあどうせ言い訳して逃げるんだろうけど
あとアホにアホって事実を伝えるのは人格攻撃と違うぞw >>855
じゃあ俺のは人格攻撃じゃないのは分かるね？いや、アホだから分からんか
このやりとりが始まってからの書込みすら追いかけられないドアホは
今後も勝利宣言に固執するんだろうなあ >>856
あれ？
> 使わんでよろしいの真意も書いてる
はどうなったのかな？
ごたくはいいからはよ書けよ
書けないなら黙ってろよ、恥の上塗りするだけだし
あとお前のは人格攻撃
根拠も示せずにカスとか喚いてるだけだしw >>857
すごくはっきり書いてるよ
ちゃんと読みなよ
日本語検定中 >>858
うん、ずっとそこだよ
そもそもスレチと言いながらレスし続けるのはちょっと矛盾してないかね？
>>859
低能がよくやる方法でごまかそうと必死だな
勢いで
> 使わんでよろしいの真意も書いてる
って書いたもののどこにも書いてなくてどうしようか顔真っ赤ってパターンw
これまでも何度も見たわ ていうか、何1つ技術論になってない。
どうでも良い話ばかりで意味が無い。 >>860
鏡を見なよ
書いてること読めないくせに、書いてないことにして逃げてる君が居るよ
日本人じゃないのかなあ？ >>864
「書いてる」って強弁するしかない低能乙
低能のパターンっていつも同じだなw >>866
IDたどればわかるって言うのも低能がよくやる手
もちろんどんだけたどっても出てこない
出てくると言うなら
> レス番示して引用
するだけでいいんだけど、やれないから色々知恵を絞って言い訳してる
まあ知恵絞っても所詮低能の知恵だからいつものパターンしか出てこないけどなw 匿名掲示板にないものをあてにする
そもそも根本的なことがわかってないまま
おかしい前提でわめくやつってよくいるよね >>867
はい、日本語検定終了です
無能をご自身で証明しましたね
854 ：デフォルトの名無しさん ：sage ：2019/12/13(金) 20:55:09.79 (p)ID:azLSlpn/(6)
このＩＤすら辿れんの？検索って言葉も知らなかったの？
書込み6つのうち、理由書いてるの一つだけだぞ
これでも使わなくていい理由に該当する日本語文章を理解できないなら、マジモンだわ >>869
知ってるならお前こそ無駄なレスするなよw
>>870
たどっても書いてないからなぁ
書いてると言うならとっとと
> レス番示して引用
しなよ
まあできないからグダグダ言うしかないんだろうけどw スレチの指摘がスレチって小学生ですか？
スレ内検索方法もスレチですよ 5ch初心者か？
嵐の相手する奴もまた嵐
って言葉も知らんの？ ここが適切かどうか解りませんが最近のWindows10で腑に落ちないことが
32bitのアプリ内からプリンタドライバ経由でファイル生成を行ってたんですが
実体のファイルが無い(＝親プロセスから見えない)のに処理が完了するようになってました
少なくともWindows7やWindows10初期では出なかった問題なのでここ最近のアップデートで
関連する何かの仕様変更があったのでしょうか？
今までは次ステップ処理で単にファイルの存在確認だけで問題無かったのですが
対策として存在確認の前に生成されていない状況を想定し、ウェイト入りで
複数回確認することで回避は出来ています
変更内容によっては他の箇所も潜在的な問題が埋まってることになるのでいっぱい見直さないと・・・ ファイル生成完了するまで処理が戻ってこなかったのに、完了前に戻ってくるようになったって事？
これはむしろ昔からそのような仕様だったような
印刷枚数を厳密に管理するためにファイルに吐いてから自分で印刷をかけるシステムを
組んだことあるけど、ファイル生成完了まで待つ処理を作ってた記憶がある
ファイルが見えないだけなら権限の問題じゃないのかね >>876
ファイル生成完了前に戻ってくるようになった、という認識です
Windows2000の時に組んで今年に入るまでは問題報告を受けてませんでした
アクセス権の反映と思って(あるけど触れない)単純に１～２秒のウェイト入れて一時的に
回避してたのですがそれでもおかしい時があるのでキッチリ見えるようになるまで待つようにしました
Windows7の時にもの凄い回数の負荷テストを乗り越えてた処理なので
少なくともWindows10以降からの仕様とは思ってるですけどねぇ・・・ >>877
Win95～ME辺りの相当前のことなのでちゃんと覚えてなかったゴメン
ソース引っ張り出してみたけど、単にメッセージループ挟みながら
出力ファイルをaccess関数に渡して0が返ってくるの待ってるだけだった
この後自分でポートに出力してる流れ
この時のaccessが0を返すタイミングがファイル作成中なのか終了後なのかもはやよく分からないけど、
ファイル作成中なら後のポート出力で死にそうなんだよね・・
古すぎてもう動作確認無理
この辺の動きはプリンタードライバーによっても違ったような気もする
（意図した動きをEPSONはするけどCANNONはしなかったとかで、EPSONを採用したような）
いずれにせよ古すぎる話なので流し読みしてください せっかくなのでもちょい情報共有
PrinterにFileName与えて印刷ジョブ作ってファイル保存させているのですがこのファイルが見えない
何かアンチウィルス系ソフトが引っかけてるのかと思って読み書き出来るようになるまで待つループを
入れてはみたけどそもそも見えない状態で印刷処理が終了して帰ってきてます
後工程ですがAdobeのDistillerAPIで上記のファイルからPDFに変換させてるんですが
明確にPDFファイル生成終わってから戻るってプロパティを指定しているにも関わらず
実体ファイルが見えない状態で元プロセスに戻ってくるって所です
子プロセスで生成したファイルを参照する場合、同期(処理完了待ち)してても
ちゃんと実体ファイルがある(見える)かどうか確認しろって仕様なんでしょうね >>877
ファイル生成に使っている関数はなんなのかとか、
作成先はローカルHDDなのかネットワーク越しなのかその他のデバイスなのかとか とりあえずもちつけ
＼もちつきワッショイ／
+ +
ペタン
+ +
／■＼ ||| ／■＼
(´∀｀) ＿ (´ー｀)
( つ つ | |=Ｏ＝Ｏ=)
`) ) )|￣￣￣|( ( (
(＿)＿)|´∀｀|(＿(＿)
￣￣￣￣￣￣￣￣￣￣￣ 質問させてください。
コマンドプロンプトが入力待ちしている時に、右クリックするとクリップボード内のテキストが貼り付けされますが、
キーやマウスの入力エミュレートを使わずに、似たことを外部プロセスから実行する方法ってありますか？
具体的には、所定の文字列をコマンドプロンプト入力待ち領域に貼り付けて使えるようにしたいです。
WriteConsoleOutput()はあくまでも文字列をコマンド窓内に描画するだけであり、これを入力文字列としては使えないという認識です。 >>891
コマンドプロンプト版のhistoryにあたる doskey /h だけでは不満でdoskey /h の結果を使って、
プロンプト上で選んだ履歴文字列をプロンプトに出力して使えるようにし、
TABコマンドやF7, F8押下コマンド みたいな挙動が実現できればと思っています。 F7押下で履歴リスト選択がCUIとして表示されますが、これを別プロセスで実現し、リスト選択した結果を呼び出し元プロセスのコマンドプロンプトに渡せればな、と。 ちょっと教えてください
スリープ解除後、自作アプリのウィンドウが勝手に
OSによって動かされることがあるんですが
ユーザでなくOSによってウィンドウが
移動させられたことを知る方法ってあります？
もしあれば教えてください 誰に移動さられようが普通にウィンドウメッセージが飛んでくるんじゃねえの スリープ前後で瞬間的に解像度が変わっているんだろう
で、解像度の変更を監視するWin32APIは知らないけど
SystemEventsクラスで監視はできるらしい
ttps://smdn.jp/programming/tips/displayresolutionchanged/ Windows Terminal ちょっと使ってみたんだが、良さがわからなかった。
マイクロソフト公式の「車輪の再発明」って感じ。 >>896,897
DisplaySettingsChangedでちょっとテストしてみます WM_DISPLAYCHANGEで試してみました
質問には関係ありませんが、4KとFHDのデュアルモニタ構成で
スリープ復帰後にサブのFHDモニタのほうが先にアクティブになるのが原因で
個々のウィンドウが移動してしまうみたいです
22:51:29- Width=3840 Height=2160 MonitorCount=2 Left=3183 Top=921
-- Display Sleep
23:07:52- Width=1920 Height=1080 MonitorCount=1 Left=1271 Top=461
23:07:54- Width=3840 Height=2160 MonitorCount=2 Left=2542 Top=922 display portで繋いでると、ディスプレイの電源offを感知して
offってないディスプレイに勝手にウィンドウを移動するのがうざくてしかたない
offったディスプレイの電源をonしたら戻すならまだ許すんだけどそれはしてくれない
この動作をどこかのレジストリとかで止められないのかな スレチ便乗で申し訳ないけど、作業中にDPモニターがいきなり真っ暗になってスリープに突入、
そのまんまキーを押すと復帰するけど、>>901,903のような現象にはならない
これは別件かな？ >>905
モニターがスリープです
PCが突然死したのかと思いきやキーを押すと復帰して、
ウィンドウ・アイコン類の位置は不変で復帰
スレチでスマン >>901
レジストリ云々の問題じゃなく単にモニタの電源のハード不良じゃないの
人間も寒いと急死したりするし あ、 DisplayPortの仕様の欠陥か
失礼失礼 ありがとう
>903の記事読んで適当にググってみたら、結構文句が出てる件なんだな
当たり前か
で、結局一番まともな解決法は>902というね…
OSが勝手に移動するのをやめてくれるだけでいいんだけどなぁ モニタが急死したときには移動してくれると嬉しいけどなあ
急死と休止を判別できれば良いだけなのに ＞offったディスプレイの電源をonしたら戻す
を行う常駐アプリは比較的簡単に作れそう。
さらに、2ndディスプレイがオフられた時、そこにあった窓は最小化する機能も上記と併せて作れそうだな。 コマンドプロンプト上で doskey /reinstall とコマンド実行したら何が起きるのが正しいの？ オーラロードが開かれた。きらめく光、オレをうつ。
conhost.exe、コアダンプ吐いても恐れはしない。飛び込めばいい。
肉を切らせてとどめを刺せば。 GetLastInputInfoって管理者権限じゃないとちゃんと値が返ってこないっぽいんだけど、こんなもんなんですかね
アイドル時間知りたいだけなのに管理者って・・・
using System;
using System.Runtime.InteropServices;
public class GIT {
[DllImport("User32.dll")]
private static extern bool GetLastInputInfo(ref LASTINPUTINFO plii);
internal struct LASTINPUTINFO {
public uint cbSize;
public uint dwTime;
}
public static uint GetIdleTime() {
LASTINPUTINFO lastInPut = new LASTINPUTINFO();
lastInPut.cbSize = (uint)System.Runtime.InteropServices.Marshal.SizeOf(lastInPut);
GetLastInputInfo(ref lastInPut);
return (uint)Environment.TickCount - lastInPut.dwTime;
}
} 4時間アイドル状態になってたらハッカーも侵入しやすそうだからな
知りたい情報の一つだろう EnableWindow(hwnd, FALSE);
この状態でhwndのウィンドウがクリックされた事を知るにはどうすればいいですか？
モーダルダイアログを表示してる間はそれ以外のウィンドウを無効にしてるんですが(MessageBoxで言う所のTASKMODAL)
hwndがクリックされたら有効になってるモーダルダイアログをアクティブにしたいんです >>918
hwndをモーダルなウィンドウのparentにしておけば良いんじゃね >>921
ありがとうございます
それだと親の時だけFlashWindowとMessageBeepの動作になるんですよね
セオリーかはわかりませんがこれで目的の動作になりました
// クリックされた側のプロシージャ内
case WM_SETCURSOR:
if(HIWORD(lParam) == WM_LBUTTONDOWN)
if(LOWORD(lParam) == (WORD)HTERROR)
// hwndがクリックされた時の動作 GetGlyphOutline などで文字画像を取り出そうとすると、フォントが持ってない文字は代わりの文字を出力してくる。
（例えば、昔の毛筆フォントでは「髙（はしご高）」などはMSゴシックになる。）
これを抑制したいので、そのフォントがグリフデータを持っているかどうか、調べる方法はありますでしょうか？
すれ違いと言われてここを紹介されました。 フォントフォールバックやらフォントリンク無視したいならUniscribeのAPI使えばいけるかもな FreeFont とかの DLL 使っても良いと思うし
グリフがあるかどうか確認したいだけなら
ファイルを直接操作してインデックスがあるかどうかだけ観ても良い 923ですが、GetGlyphIndices で自己解決しました。ありがとうございました。 CreateWindowをした時に、強制的にウィンドウが開かれてしまうのですが、
これを最初は非表示にすることってできないでしょうか？ トップレベルウィンドウの事ならShowWindow SW_HIDEにする >>928
WS_EX_LAYEREDにしておくと初期状態で透明度100%じゃなかったっけ
あるいはcx,cyを1,1にしといて、あとでSetWindowPosとか 即表示にしてないはずなのに一瞬出るって問題ちょくちょく出るかんな 理由は忘れたし検証する気はないが、普段非表示で必要時のみウィンドウを表示する
アプリを作ったときは CreateWindowEx を使ってウィンドウサイズ0でやってた 初回のShowWindowではSW_xxxは無視される >>935
SW_HIDE試したけど無視されずに非表示になったよ STARTUPINO si;
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_SHOWMAXIMIZED;
で、こっちが優先される
SW_SHOWNORMALだとアプリケーションの設定に従うようだ START /MIN "" "C:\Windows\Notepad.exe" reg export HKCU\Software\...
でレジストリの内容をエクスポートできますが、
このコマンドと同じことをAPIを使って行うことはできますか？ >>941
やっぱり自前で一から組み立てて真似しないといけないんですかね。
常駐ソフトの終了時にreg exportをCreateProcessで実行したいんですが、
WM_ENDSESSIONの中ではCreateProcessは失敗するようなんです。 >>943
起動されたままWindowsを終了したときは、WM_DESTROYは来ないようです。
WM_QUERYENDSESSIONやWM_ENDSESSIONしか来てませんでした。 WM_CLOSE とか WM_DESTROY とか自分で呼べば >>945
WM_QUERYENDSESSIONやWM_ENDSESSIONの中でウィンドウを破棄しても、
そこからCreateProcessは呼べないようです CreateProcessを呼んでからCloseするんやろ WM_DESTROYとか来ないね
まあ聞いてる間に自分で組んでたらとっくに終わってる感
キーを読みながらぐるぐるループ回して吐くだけでしょ？ WM_ENDSESSIONから戻った後はたとえイベント発火したとしてもkillされる可能あるし >>946
別スレッドでWM_ENDSESSION来たらやってみるのは？
あとShellExecuteはダメなん？ typedef struct
{
WORD idReserved;
WORD idType;
WORD idCount;
} ICONDIR;
#pragma pack( push )
#pragma pack( 2 )
typedef struct
{
BYTE bWidth;
BYTE bHeight;
BYTE bColorCount;
BYTE bReserved;
WORD wPlanes;
WORD wBitCount;
DWORD dwBytesInRes;
WORD nID;
} GRPICONDIRENTRY;
#pragma pack( pop )
で、ICONDIR の後ろに GRPICONDIRENTRY を個数分だけ並べて ico ファイルから引っ張ってきたデータをそれに突っ込んでUpdateResource()してる。
もちろん対応するRT_ICONにイメージは追加してある。
実行時にエラーも出ないし、ResourceHackerなどで見ても、ちゃんと登録されているのだが、エクスプローラーの表示を特大アイコンにしても48x48の中央寄せ表示になってしまうんだ。
マルチプルアイコンを、::UpdateResource()で登録するとき、なにかシングルアイコンと比べて注意することがあるなら教えてください。
参考ＵＲＬでもＯＫです（探してみたけれどシングルアイコンのものしか見つからなかった） WM_WINDOWPOSCHANGING
というメッセージは、lParamにWINDOWPOS構造体のアドレスが渡されてきて、
その中のflagsメンバなどを修正するとZ-Orderの変化を阻止したり出来ます。
それは実験的に確認しました。質問は、この仕組みのことなのですが、
GetMessage()でこのメッセージを受けた後、DispatchMessage()経由で WindorProc()
に来ることが前提なのかと言うことです。逆に、
GetMessage()でこのメッセージを受けた後、DispatchMessage()を経由せずに、独自に
WindowProc()を呼び出した場合は、WINDOWPOSの中を変えたとしてもWindows Systemは
感知しないのではないかと思うのです。
今までメッセージループ内で定型として漠然と DispatchMessage() を使ってきたのですが、
こんな不思議な仕組みだったのでしょうか。 >>957
すみません。これは、Postではなく、Sendで送られてくるメッセージのようです。
だから、メッセージループや GetMessage 関数は無関係なんですね、恐らく。 PeekMessage()のPM_QS_SENDMESSAGEの働きが分かりません。MSDNによれば：
「Process all sent messages.」
「During this call, the system delivers pending messages that were sent to windows owned by the calling thread using the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function. 」
となっていますが、SendMessage()でpending messagesされているメッセージとはいかなるものなんでしょうか。
この説明だとSendMessage()されたメッセージの内、pending状態にあるものは、PM_QS_SENDMESSAGEを指定したPostMessage()によって取得できることになってしまいますが、どういうことなのか分かりません。 WM_PAINTとかはqueueの中で後回しにされるとかなんとか >>960
WM_PAINTは、この文脈では SendMessage() とは直接関係ないようですが。 別スレッドからsendされたメッセージとそのスレッド自体は待たされてる MS謹製の訳
「PeekMessage 関数を呼び出すと、呼び出し側スレッドが所有しているウィンドウへ送信されたメッセージのうち、保留されていたものを取得できます。
SendMessage、SendMessageCallback、SendMessageTimeout、SendNotifyMessage の各関数を使って送信されたメッセージが、これに該当します。」
他スレッドから送られたSendMessageは、PeekMessageを呼び出したときに受け取ることができる。 Windows OSのバイブル『Windows Internals』を日本語解説するプロジェクトが“GitHub”で開始
実際に動作するアプリで高度かつ難解な内容をコードレベルで理解
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1239207.html
＞高度かつ難解と評される同書も、実際に動作するC++/Win32 APIのコードをみながら読み進めれば理解が深まるかもしれません。 >>963
ありがとうございます。
ただし、その話は関係は有りそうですが不明瞭なので、もう少し詳細が有ればいいのですが。 >>966
他スレッドからSentされたmessageはPeekMessageで取得するのではありません。
これらのmessageはPeekMessageの内部で処理されます。 他スレッドからのsendはここの図がわかりやすい
http://chokuto.ifdef.jp/urawaza/sendmsg.html
（HSP関連の記述は読み飛ばすべし） >>967
すみませんが、その日本語は何をおっしゃっているのか分かりません。 >>968
その図の意味は分かりました。
しかし、それだと他スレッドへSendMessage()した場合、
他スレッドがGetMessage()やPeekMessage()を行って、DispatchMessage()
などを行わない限りは (他スレッドの)WndProc の実行が始まらないことに
なります。
しかし、現実には他スレッドへのSendMessage の場合でも、他スレッドで
Get, Peek, Dispatch が全く実行されてなくても、WndProc は
実行されると思います。 >>970
それか、他スレッドへ SendMessage() した場合、勝手に WndProc() が call
されてしまうとプログラムのデータが破壊されてしまう可能性があるので、
必ず Queue に入れてから、メッセージループの GetMessage() と DispatchMessage()
を介しての実行になるのかもしれませんね。 メッセージキューは思ったよりも複雑な問題だ。
EternalWindowsに詳しい解説がある。
http://eternalwindows.jp/windevelop/message/message00.html
このあたりを読んでみるとよい。 ファイル名の半角文字を小文字に統一したいのですが、MoveFile を使っても
大小の違いだけでは同一名と判断されてうまくいきません。
何かスマートな対策がありますでしょうか？ アンダーバー付きとかのファイルにリネームしてから本来のファイル名にする >>975
一度別のファイル名にしても、元のファイル名を覚えているようでダメでした。 MoveFile("A.TXT","B.TXT");
getchar();
MoveFile("B.TXT","a.txt");
これなら成功するので(笑)、おそらく時間稼ぎする方法があると思うのですが。 MoveFileExでMOVEFILE_WRITE_THROUGH付ければいいんでね？ >>974
MoveFile("A.txt","a.txt"); でちゃんと名前変わったんだけど
うまく行かないのはコンパイラの最適化とかで無かったことにされているだけじゃないの？
それともGetLastError()とかでそういうｒたーが出てるの？ そういうｒたーが出てるの？ → そういうエラーが出てるの？ 中間ファイル名を噛ませなくてもMoveFileでいけるみたいなんだけど
表示上変わっていないだけで、最新の情報に更新したら変わったりしない？ 俺環かな？と思って、Cドライブ(NTFS)に移すとうまくいきました。
Dドライブ(exFAT/USB)ではうまくいきませんでしたので仕様なんでしょうか。
お騒がせしました。ありがとうございました。 >>977
getcharじゃなくてb.txtの存在を確認汁 >>986
確か、FATは、MS-DOS時代、もともとファイル名に大文字小文字の区別が無かった。
コマンドラインからコマンド名やファイル名を小文字で入力しても、大文字のファイルが検索された。
そして、FATのディスクの中の「ディレクトリ構造」の「エントリ」には、必ず全て大文字に直した
ファイル名が記録されていた。
その影響がまだ残っていることがあるようだ。 フォントの高さの取得方法について質問があります。
現在DCに選択されているフォントの "高さ" を取得して、大学ノートの罫線のようなものを、その高さの
間隔で描画することを考えています。調べてみると GetTextExtentPoint32 というAPIがフォントのサイズを
計算してくれるようなのですが、引数に文字列が要求されます。しかし、罫線と罫線の間にどんな文字列を
描画するかは未定です。現在は適当な1文字だけ指定して高さを求めていますが、その文字よりも高さが
大きい文字が存在する場合、罫線をはみ出してしまうのではないか思います。
特定のフォントの、全ての文字を包含する高さを取得する方法はないのでしょうか。
よろしくお願いします。 >>989
ご回答ありがとうございます。
符号の違いはありますが、GetTextExtentPoint32 と同じ値が返ってくるようです。いずれも、指定した文字のサイズにかかわらず一定値が返ってくるようなので問題なさそうです。フォントの高さだけが知りたいので GetObject のほうがシンプルですね。ありがとうございました。 excelVBAでシリアル通信をする為にコード例を探してきて使っています。
ポートのファイルハンドラがわからなくなった場合に強制的にポートを閉じることは可能でしょうか。デバッグリセットかけた際に変数が初期化されてポート操作が出来なくなりました。excelを立ち上げ直すと操作可能になるので何か方法があると思うのですが 立ち上げ直しで解放されるのはプロセスが終了するからでは？ UME
user method exchangeという謎の技術名を考えた
何に使うかはしらん Unrecoverable Memory Error このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 431日 4時間 32分 32秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
