[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 09/07 04:05 / Filesize : 285 KB / Number-of Response : 1021
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Win32API質問箱 Build125



1 名前:デフォルトの名無しさん [2019/02/27(水) 15:09:08.64 ID:6ExXwgQU.net]
Win32APIについての質問はこちらへどうぞ。

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

■過去スレ
Win32API質問箱 Build124
mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問スレ Part41 【C】
mevius.5ch.net/test/read.cgi/tech/1521786252/

513 名前:デフォルトの名無しさん mailto:sage [2019/10/23(水) 12:59:02.01 ID:ou8vQa3g.net]
>>502
日本語で

514 名前:デフォルトの名無しさん [2019/10/23(水) 15:31:41.90 ID:J1BMEu9t.net]
いや判るだろ

1809 update 入れた後に可笑しくなったんだろω

515 名前:455 mailto:sage [2019/10/23(水) 21:03:31.35 ID:i0lmBL5A.net]
1809以降の挙動ならプログラムじゃなくてWindows側の問題みたいですね
BitBltだけじゃなくプレビューにも問題出てるからバグっぽいですし
そのうちアップデートで治ることを期待しつつプログラムでの対応は諦めます
いろいろ答えてくれた皆様ありがとうございました

516 名前:蟻人間 mailto:sage [2019/10/23(水) 22:21:30.01 ID:bxABcYeD.net]
やっぱりKnownFolderから取得できた。
https://github.com/katahiromz/SHVistaPathMap/blob/master/dump.cpp
自由に使え。

517 名前:蟻人間 mailto:age [2019/10/23(水) 23:01:48.53 ID:bxABcYeD.net]
揚げ物

518 名前:デフォルトの名無しさん mailto:sage [2019/10/24(木) 00:20:06.38 ID:ywNA7G1O.net]
ありがとう。だがしかし別のアプローチで
俺が解決したい(本当の)問題は解決できていたのだよ

まあ誰かの役に立つだろうから放っておいたけどな
すまんなwww

519 名前:デフォルトの名無しさん mailto:sage [2019/10/24(木) 00:41:12.27 ID:Fw8n9fLr.net]
アップデートで直るかっちゅーても挙動自体は描画の最適化とも言えるので仕様としてこのままいきそうだけどなあ

自作ので試してみたけどやはり一部でも画面外に出てると無効領域をクライアント全体と指定しても
強制的にクリップされたHDCが返ってくるね
BeginPaintだけじゃなくてWM_PAINT外でのGetDCでも同様
DXGI swap chainが出力先ならクリップされない

普段窓を画面外に追い出したままにするってことがないから気付かなかったなコレ

520 名前:デフォルトの名無しさん [2019/11/04(月) 15:23:29.75 ID:/C5zJSxn.net]
SetForegroundWindowでフォーカスを奪えない、
入力中にフォーカスが奪われるとウザいからWindowsが
奪えないようにしてるって話はよく聞くと思うけど

逆にエクスプローラが起動すると(バックグラウンドなのに)
フォーカスを奪ってくれて困ってるんだけど対応策ない?
ウザいんだがw

521 名前: mailto:sage [2019/11/04(月) 15:58:26.30 ID:fwURXfb5.net]
>>447
さらに追試を重ねていました
悪いときは 10G, うまくいっても 5000G 程度(日によってばらばらです)で
FILE_END ができなくなる現象は、
FILE_END が悪いのではなく、システムで圧縮するように指定するとそういうことがおきることがわかってきました。

Windows もいろいろとあてにならない、もう linux に軸足を移そうか、と思案しています



522 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 16:19:56.83 ID:1IiqNDSP.net]
>>510
SetFocus()を使うと好きなコントロールにフォーカスを与えることが出来る。
SetForegroundWindow()は余り効果が無い。

523 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 16:52:05.66 ID:KwYoxUXo.net]
longポインタ引数にintポインタ渡して>>445みたいなトンチンカンな返答する人が何か言ってる

524 名前: mailto:sage [2019/11/04(月) 18:29:13.81 ID:fwURXfb5.net]
>>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 ってください

525 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 18:55:51.87 ID:KwYoxUXo.net]
>>514
445のどこがWindows環境?

526 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 19:29:40.39 ID:ex697rOI.net]
DOS窓でprintf出力しながらWin32APIだって使えるからWin環境

527 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 20:03:10.14 ID:xxqq9QlV.net]
LONGは、WPARAMやLPARAMと型変換する危険コードが多い気が。もちろん古いコードだけど。

528 名前: mailto:sage [2019/11/04(月) 20:32:15.68 ID:fwURXfb5.net]
>>515
だから、あなたは 10 年 ROM ってなさい、ってさっき言ったでしょう?

529 名前:デフォルトの名無しさん mailto:sage [2019/11/04(月) 23:46:10.01 ID:hiiCgg8I.net]
ここはWin32スレなんだからWin64や総称であるWindows APIはスレ違い
32ビットの話だけしてろ

530 名前: mailto:sage [2019/11/05(火) 00:15:09.88 ID:SbnLKNM3.net]
>>519
残念ながらその意見に賛同する人は少数派だと思いますよ

531 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 01:54:03.16 ID:RTdVMJgD.net]
Win64APIなんてどっから出てきたの?



532 名前:デフォルトの名無しさん [2019/11/05(火) 11:28:00.41 ID:f5fZl2jz.net]
> 昔は DWORD (Double WORD) と定義されていましたが
LPARAMは 16bit,32bit共に LONG (符号付整数)

533 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 11:48:37.07 ID:McETm4vA.net]
>>519
64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ
Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度
つまりスレチでも何でもない

534 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 19:37:14.92 ID:wVD+ILW8.net]
double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが

535 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 20:20:06.81 ID:Rmlz0hln.net]
>>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)になったんだが

536 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 20:52:13.30 ID:mHpC8FDb.net]
>>525
釈迦に説法ご苦労

537 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 21:08:53.99 ID:Rmlz0hln.net]
釈迦は俺やしw

538 名前:デフォルトの名無しさん mailto:sage [2019/11/05(火) 21:43:32.83 ID:mHpC8FDb.net]
俺メインフレームでdiagnose命令とかいじくってて
別な案件でhdlでcpu書いたりしてるけど

539 名前:デフォルトの名無しさん mailto:sage [2019/11/06(水) 01:32:27 ID:k1IDaN6Q.net]
メインフレームw
何歳になってもイキリ小僧してるんだな
サルのパパとママはご存命かい?

540 名前:デフォルトの名無しさん mailto:sage [2019/11/06(水) 02:20:55.89 ID:71FJFoA8.net]
>>529
何イキっとんねん

541 名前:デフォルトの名無しさん mailto:sage [2019/11/06(水) 04:07:48 ID:Z1mcKm+J.net]
イキなりえなり



542 名前:デフォルトの名無しさん mailto:sage [2019/11/06(水) 07:21:07 ID:cnDla3Ge.net]
>>525
ソフト的なAPIの話に物理アドレス空間で語るバカ乙w

543 名前:デフォルトの名無しさん [2019/11/06(水) 12:01:28.81 ID:o3tEvZiY.net]
釈迦がどうかはともかく
>>525 が全くトンチンカンなレスであることは事実
いつものあいつだろ

544 名前:デフォルトの名無しさん mailto:sage [2019/11/06(水) 15:05:39.69 ID:Z1mcKm+J.net]
>>532
APIの話だというのなら、OSが16bitだろうが32bitだろうが
APIの仕様が代わるわけないんやで
異常事態でもなんでもなく、それが高い互換性の理由だ

545 名前:蟻人間 mailto:sage [2019/11/06(水) 15:13:44.92 ID:Z1hQUtYe.net]
64ビット対応で
Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、
DialogProcの戻り値をINT_PTRにしろ。
とかの若干の変更点があるようだ。

546 名前:デフォルトの名無しさん [2019/11/06(水) 15:19:20.45 ID:o3tEvZiY.net]
HANDLEもこっそりtypedefに_PTR変えたんだっけ

547 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:18:36.16 ID:7K0XtVuo.net]
ダイアログプロシージャの戻り値がめんどうなことになる
x86じゃBOOLだけどx64だとINT_PTR
でもVC6だとBOOLはintだという

548 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:32:58.79 ID:sEmiRyTj.net]
歴史的理由で仕方のない面もあるが、
単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから
型の実態は結局なんなんだ?って悩むことになってる。

もうそろそろネイティブ型だけを使えるようになってほしいが
そのために言語を変えるほうが楽だろうな

549 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:44:34.42 ID:ubAK6fog.net]
intとlongのサイズ違うこともあるしな
c#みたいにint32みたいなの最初から用意しとけよ

550 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 01:48:09.03 ID:cfOynPV2.net]
stdint.h使おう

551 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:23:16 ID:+N3PsKU8.net]
前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。



552 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:26:43 ID:4jX7Qkw7.net]
いいかげんな知識で語りたがるやつ多すぎ

553 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:27:07 ID:+N3PsKU8.net]
32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に
悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか
どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。
恐らく、exeファイルのサイズも増加するだろう。

554 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:42:22 ID:sEmiRyTj.net]
コンピュータが遅かった時代はCPUに最適なデータ型を
使うことが重要だったが、今は数値型しかなくて
データサイズは自動的に決まりますとかばかりだもんな

555 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:44:07 ID:+N3PsKU8.net]
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にした方が
速度が上がる可能性が高い。

556 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 02:45:21 ID:+N3PsKU8.net]
>>544
>今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな
C++だと今でもデータサイズは明示します。

557 名前:デフォルトの名無しさん [2019/11/07(木) 02:54:21.19 ID:PsJP4fV8.net]
size_t型が無難にして最強

558 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:00:35.26 ID:sEmiRyTj.net]
>>546
他の言語の話や。今は速度よりも利便性のほうが重要や

559 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:18:33 ID:+N3PsKU8.net]
>>548
例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている
わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、
整数は32BIT整数型までだと double型に精度を落とすことなく完全に
収まるので、何も考えずに正しく扱えるだけです。
JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。

560 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:23:20 ID:+N3PsKU8.net]
>>549
また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、
console.log(54 / 10);
とすると、5.4と表示されます。これは、54や10が整数ではなく、
54.0 や 10.0 という double 型浮動小数点として扱われているためです。
これは、Sun/Oracle の Java とは全く結果が異なります。後者では、
54/10は、「整数除算」なので、結果は整数の「5」となります。

561 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:38:26 ID:sEmiRyTj.net]
> 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となります。



562 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:39:52.10 ID:sEmiRyTj.net]
なんだ。JavaScriptにBigIntあるじゃん

Numberで表せる最大の整数値は十分な値にも思えますが、
分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。

BigIntは、任意精度の整数を表す新しいプリミティブ型です。
任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。

563 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:43:05 ID:sEmiRyTj.net]
やっぱりどんなときでもプログラマがデータ型を
選んでくださいっていうのは時代遅れだと思わ

564 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:53:54.05 ID:+N3PsKU8.net]
>>553
自動化することは可能ですが、現在の技術でそういうところまで自動化した
言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる
かも知れません。これはコンパイル意を作成した経験に基づく話です。
もの凄く厳しい世界が実はまだ沢山残っています。

565 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 03:55:32.96 ID:+N3PsKU8.net]
>>554
誤:かも知れません。これはコンパイル意を作成した経験に基づく話です。
正:かも知れません。これはコンパイラを作成した経験に基づく話です。

566 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:58:19 ID:sEmiRyTj.net]
100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ

567 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:58:57 ID:sEmiRyTj.net]
今より100倍遅かった時代もあるのに
何を言ってるんだろうか?
それこそ時代遅れの感覚

568 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 03:59:39 ID:sEmiRyTj.net]
あと、「かも知れません。」とかいう推測はどうでもいいから

コンパイラを作り上げた俺が言うのだから
説得力は高いだろうし

569 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:00:34.74 ID:+N3PsKU8.net]
>>555
GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような
例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を
floatや整数型などにバラして処理するので数10倍かかります。
なので、慎重になる必要があります。
CPUの場合でもintとdoubleで速度がかなり違うことが多いです。

570 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:02:01.90 ID:sEmiRyTj.net]
あと極まれにスピードが重要な部分があるから
全部スピード重要視しろとかいうアホな感覚なw
あれはやめてほしい。

極稀に重要なら、極稀に使うものを作ればいいだけ
よく使うものを短くする。(仕事の)圧縮の鉄則

571 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:02:17.73 ID:+N3PsKU8.net]
>>558
あなたより私の方が良いコンパイラを作っている可能性も有りますよね。



572 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:05:54.80 ID:+N3PsKU8.net]
>>560
自動化の道は検討の価値はあるでしょう。
しかし、int32型とint10000000型を自動的に取捨選択できるほど、
コンパイラが賢くなるのは恐らく遠い未来です。
どこかで機能制限や精度を人間が指示する必要があると考えられます。

573 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:07:52.13 ID:sEmiRyTj.net]
>>561
そういう俺のほうが優れてるとか言う主張をしたいなら、
個人を特定できるような情報をだせ

574 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:08:39 ID:sEmiRyTj.net]
>>562
コンパイラが無理なら実行時にメモリ拡張すればいいだけ
そういうことも思いつかないから、その程度止まりなんだよw

575 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:08:50 ID:+N3PsKU8.net]
>>563
それはお互い様です。

576 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:11:41.18 ID:+N3PsKU8.net]
>>564
それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、
OSなどの作成には向いていない言語になるでしょう。

577 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:12:20.64 ID:sEmiRyTj.net]
大胆に変数はすべて128bitしかないという言語だって考えられる
最大 340282366920938463463374607431768211456 までしか扱えないが

578 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:13:03 ID:sEmiRyTj.net]
>>566
そんな言語が今はたくさんあり実用化されています。

579 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:17:30.53 ID:+N3PsKU8.net]
>>567
64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。
あなたが普段使っているコンパイラも、非常に細かい高速化を施して
あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの
動的言語では達成できません。

例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ
から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。
あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。

580 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 04:18:51.44 ID:+N3PsKU8.net]
>>568
有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの
メジャー言語ではそのような方針はとっていません。

581 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 04:23:37 ID:+N3PsKU8.net]
>>564
「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。
全く発表してませんから。



582 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 05:42:32.39 ID:xrNXmkmc.net]
スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ

583 名前:デフォルトの名無しさん mailto:sage [2019/11/07(Thu) 06:22:21 ID:D8b5RtWG.net]
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。

ひどい説明だな
どのくらいひどいかというと
WM_SYSTEMMENU並み

584 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 11:03:05.72 ID:JQdG/Jj/.net]
公共の場で変数型のピロートークですか

585 名前:デフォルトの名無しさん [2019/11/07(木) 11:05:56.88 ID:dB1QBG ]
[ここ壊れてます]

586 名前:Xo.net mailto: >>545
size_t 使え
[]
[ここ壊れてます]

587 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 11:27:25.53 ID:nSoHFrko.net]
>>575
NULLは0だから〜
site_tはどうせintだから〜

こういう馬鹿なハケンが一人いると崩壊するよね

588 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 12:11:51.38 ID:sEmiRyTj.net]
とか言うやつほどnullptrのことを知らなそうw

589 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 12:17:00.95 ID:9pMbL+ZJ.net]
(´∀`)<ぬるぽ

590 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 17:55:20.14 ID:7K0XtVuo.net]
#ifdef _WIN64
#define BOOLX64 INT_PTR
#else
#define BOOLX64 BOOL
#endif

BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp)

こうやって回避してるわ

591 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 18:14:03.25 ID:2gAeIIzZ.net]
Windowsのデータ型だけのヘッダファイルって無いかしら?

データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、
APIのヘッダファイルはincludeしたくない。

APIを直接使うのは面倒だから、全部ラップしてるんだよね。
だから他からは使えないようにしたい。



592 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:03:13.60 ID:+mjs9icr.net]
データ型もラップしとけよ

593 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:07:36.74 ID:2gAeIIzZ.net]
>>581
どうやってラップすればいいですかね?

594 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 19:16:08.80 ID:2gAeIIzZ.net]
なんとなくわかったからいいやw

595 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 21:31:30.10 ID:6aSe0RTj.net]
横にそれるが
データ型もAPIの一部だと思ってるがあってるよな?

596 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 21:47:07.60 ID:nSoHFrko.net]
アプリケーション独自の型なんか知りませんがな

597 名前:デフォルトの名無しさん mailto:sage [2019/11/07(木) 23:33:07.15 ID:rEYaLqlI.net]
個人的には構造化したほうがやりいいかな

598 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 03:59:17.05 ID:ksOnEph7.net]
お前らMFCでも使ってろ

599 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 04:54:11 ID:2aYByRbi.net]
普通のアプリならMFCが一番だと思うんだがなあ
変に角を丸くするとか透明にするとかされても使いにくいだけだろうに

600 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 05:57:08.22 ID:bt2cbsd4.net]
むしろMFC = 角を丸くするとか透明だろ
MFC以外でそんなの見たことないわw

601 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 07:30:44.18 ID:D1bzmSlR.net]
あんまりMFC関係なくね?
WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで
MFCはラッパーとしての薄さがありがたいだけやん



602 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 07:52:07.38 ID:tDaXxZK7.net]
MFCはかゆいところに手が届かないからな
廃れたWTLがいい

603 名前:デフォルトの名無しさん [2019/11/08(金) 09:32:12.24 ID:MipGbP9q.net]
>>591
WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。
https://git.code.sf.net/p/wtl/git

604 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 11:37:03.54 ID:bt2cbsd4.net]
廃れたかどうかは、使ってる人がいるかどうかであって
作っている人がいるかどうかではない

605 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 12:13:14.99 ID:xtk88Sle.net]
俺が使ってるから廃れてないぞ

606 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 12:17:45.01 ID:2aYByRbi.net]
>>594
ちょと見せてみて?

607 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 13:27:31.55 ID:D1bzmSlR.net]
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ

608 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 13:56:39.50 ID:1R79qYgq.net]
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ

609 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 21:00:43.55 ID:lpVjWTGo.net]
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
https://social.msdn.microsoft.com/Forums/ja-JP/17563f89-9838-4beb-925f-32f47d90c994/topmost

610 名前:デフォルトの名無しさん mailto:sage [2019/11/08(金) 21:14:49.46 ID:sQQR9KNr.net]
TOPMOST同士があるからな

611 名前:デフォルトの名無しさん mailto:sage [2019/11/09(土) 13:55:21.92 ID:hHKZwsDl.net]
タスクマネージャもよく後ろに移動する時あるけど何なのあれ



612 名前:デフォルトの名無しさん [2019/11/09(土) 14:13:06.87 ID:BZG37V3w.net]
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる

613 名前:デフォルトの名無しさん mailto:sage [2019/11/09(土) 15:42:27.57 ID:01iIJK4d.net]
タスクバーより手前にくる時もある

別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<285KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef