Win32API質問箱 Build127
ReactOSはかなり似てるけどね
アイコンはTangoのを使ってるけど、形的なものはそっくりだな
テーマ機能があるから、訴えられても簡単に変えられるし、大した問題でもないが https://monolith-law.jp/corporate/design-ui-copyright-law
レイアウトや色の使い方ぐらいじゃ侵害にはならないだろうって判断と
あとは「思想又は感情を創作的に表現」したものであるかが関わる
それと著作権法に触れなくても意匠法にに触れる場合はあるとさ
>>651
複雑なデザインのボタンがあってそれを丸コピしたなら危ないけど
WinAPI程度のボタンだと「レイアウトや色の使い方」の範疇に思う >>651
あの大きさでは目コピって言いわけしても無理だろw
90%一致できるw 悪目立ちしなきゃ大丈夫って感じかな
どうもありがとう
素直に使いこなせれば変なことしなくていいんだけど >>654
Windows自体がMotifのパクリ あの立体的に飛び出たボタンは誰が最初にやったかを少し調べてみたら、やっぱりMotifが最初にやった可能性が高いな
Windowsも旧Mac OSもMotifより前にリリースされてるけど、ボタンは黒い線で縁取られてるだけだからね
Motifがリリースされた1989年の直後、1990年にWindows3.0がリリースされてボタンが立体的になった
ただ、リリース直後のMotifの見た目は確認出来なかった 誰も突っ込まないけどWin32APIのGUIってなんだよ? GDI32.DLL
つうかWindowsはGUIだろ 面倒なことしなくてもDLLからアイコンロードすればいいんだけどな >>659
CreateWindow()とか知らないの? CreateWindow() のどこがGUIなんだって話なんだけど。
GUIを構成するためのAPIの一つではあるがGUIと言われても違和感しかない。 皆行間読んで回答してるんだよ
そういうのを読み取れずにいちいち突っかかってくるお前に違和感しかないわ 行間が読み取れてないわけでも突っかかったわけでもなくて
気になる人いないの?って問うただけなんだけどね。 GUIじゃなくてGUIパーツね
それを指摘してどうすんの? GUIのデザインパクっていいっすか?だろ?
左上にシステムメニューと閉じるボタン
右上にアイコン化、全画面化がWindows3.1のGUIだ よく読めよ
ボタンのビットマップとかのGUIパーツについて言ってるだろ
GUIのメソッドについてはパクるまでもなくAPI呼び出せば自然にそうなるから Win32API の話ならム板
Win32API の著作権の話ならマ板
Win32APIのGUI?(ツールのデザイン)? の著作権の話なら著作権板
だろうな
遠すぎる winsqlite3って勝手に最新版のsqlite3でstdcallにしてコンパイルして上書きしても問題起こらないんかな テキストカーソルインジケーターをアプリに組み込みたいんですが、どこかにサンプルコードないですか? >>674
>>618: 蟻人間
似た状況の話に見えるどnyaruruはどうなったんだ? >>674
キャレットはXORペンで描くのがコツだね。 >XOR
灰色背景だと見えなくなるから賛同できないわ 標準のエディットコントロール内に居るキャレットって XOR 描画してるよね たいていは白色がテキスト入力で灰色は入力不可の部分だからいんじゃない キャレットもそうだけど、最近なんか範囲選択表示で、半透明の矩形上に重ねるだけのエディタ多くね?
あれ見づらいんだよなぁ・・・フルスクラッチで作るなら確かに横着できて楽なんだろうけど エディットコントロール自作はやめたほうがいい
IMEが機能してるように見えても、音声入力や音声入力編集、読み上げで制限があるのが大半だから
キャレットもOSの強調表示機能があるし、知らないところで多機能を要求される 自作エディットコントロールわざわざ作るときって巨大ファイル編集したいとかじゃないの
OSが勝手に後付けしたアクセシビリティ機能とか知らんでいいよ 老舗エディタ(mifes, em)は巨大ファイル対応
これが異彩を放ってる
小さいメモリ(100MB以下)で大規模テキストファイル(5TB以上、2兆5000億行以上)を編集できる世界唯一の超巨大テキストエディター
https://szkwjp.サクラ.ne.jp/
https://i.imgur.com/isKK2x5.png Meryもdelphi製コントロールをヘビーカスタムしてたと思う
http://www.haijin-boys.com/ >>686
emEditor世話になっているけど意外に保存遅いんだな
まぁ頻繁に保存するような用途じゃないんだけど
そういや日本語フォント最速表示って今なんなんだろう、DirectWrite?
アルファベットなら予めテクスチャに全部落とせばいいんだろうけど >>686,688はフリーじゃない
>>690
>意外に保存遅い
emEditorは今でも活発に最適化に努めてるから最新ではどうなのか不明
飽くなき高速化への挑戦! 「EmEditor」はマルチスレッド・SIMD命令・仮想メモリをフルに使って進化
https://forest.watch.impress.co.jp/docs/special/1483714.html
freetypeが早いけどDWはOSがキャッシュしてくれる(ctfmon.exe)のが有利
harfbuzzもラスタライズしてくれるけどbitmapヒンティング切捨て、速度は不明
GDIはカラー絵文字ないから新規では厳しい
古い記事だけど 2017-05-21 GDI vs DirectWrite vs FreeType
https://i.imgur.com/8nDxIa3.png
https://silight.ハテナblog.jp/entry/2017/05/21/220505
TATEditorはfreetype (本来の速度より遅い気がする)
MeryはDW選択可能
今のnotepadはDWだと思うけどパラメータのせいなのか、同じ日本語フォントでもMeryの方がキレイ
一度気が付くと気になって仕方ない 昔はメモ帳やらエディットボックスが32KBだかしか開けなかったせいでちょっと長いテキスト表示したいなら自作するしかなかったし
今のエディットボックスも使いやすいというわけでもないし >>693
むしろエディタには完全自作しかない
エディタにあるような複雑な禁則事項はエディトボックスでは扱えない 高校生の頃からHTML直打ち自前サイト始めたから、秀丸にはお世話になったわw >>691
690だけど遅レスですいません、詳しくありがとうございます
社内で使う遊びツールに活かさせて頂きます
というかここまで詳しい人ってもう FindWindowで他プロセスの生存確認を行っているのですが、その該当プロセスが死んではないものの
応答無しレベルで重い場合にFindWindowがNULLを返すことはあるのでしょうか?
ここでは他プロセスのトップウィンドウを検索しています。
該当プロセスが本当に死んでるなら当然でしょうが、それ以外でNULLを返す可能性があるならば
対策をしようと思いつつも、そんな可能性がないなら無駄なのでご存じの方よろしくお願いいたします。
さっとググった感じでは、他プロセスの子ウィンドウを検索する場合は問題ありのような感じですが、
本件はそうではないですしほとんどの場合NULLではなく正常にウィンドウハンドルを返してくれています。 詳細なエラー情報を得るには、GetLastError を呼び出します。 他プロセスの生存確認はEnumProcesses()でやるべきなのでは >>701
その通りなのでその辺の修正を視野に入れていますが、中々再現性が薄いのもあり、そもそもの仕様として
どうなのかなという確認の意味で質問しました。
>>702
どうもすみません。説明に抜けというか間違いがありました。
生存確認だけではなく、WM_APP+nメッセージも送るためウィンドウハンドルが必要となります。
(実際、死んでいるなら起動処理も入れていますが)
要はプロセス間通信をしているのですが、データ自体はファイルマッピングによる転送、転送のトリガー通知を
メッセージ送信にしています。 FindWindowで見つからないならHWNDも取れないんだし居ない者でいんじゃね
つかそこ悩むことじゃなくね >>700,703
ちなみにそのアーキテクチャはいつの設計なん? まずプロセス間通信するなら相手が居ない場合を必ず想定すべきでFindWindowの1度の呼び出しで一喜一憂すべきではない
プロセスの起動し直しも前提に数秒おきのFindWindow呼び出しポーリングはしたっていいと思うよ
メインウィンドウなんて高々数十個だしそんな負荷にならない 該当プロセスを他プロセスから起動してたりするとどうなんだろ
あとFindWindowじゃなくてEnumWindowsなら拾えないことって無い印象だなぁ、ハンドルも取れるし
あまり関係ないけど、うちのクソシステムだとブラウザからサーバー上にあるエクセル開くんだけど、
Workbooksで拾えたり拾えなかったりするのよね(ExcelVBA) >>704
複数起動しないようmutexかけてるので、プロセス生きてるにもかかわらずFindWindowがNULL返すのなら好ましくないなと。
>>705
古いよ。保守だけで毎月3桁くれるんだからおいしい。
>>706
とりあえず見つからないならエラーも取得しつつ数秒間再試行かけてみました。
これで様子を見ます。
>>707
該当プロセスは他のプロセスからも起動したりテスト作業で自分で起動したりしてますが、一応拾えてますね。 mutex の排他って CreateWindow する前 & メッセージループする前だから
プロセスは存在してるけど、window は無いって 中間的な状態じゃね? >>701
詳細なエラー情報を得るには、関数を呼び出します。 >>710-711
お前らその金額でおいしいの?仕事してくんない? POSIXのopenatとかをWindowsで実装したいんだけど、
NtCreateFileを使えとは見るんだけど、
実際のコードは見たなことない。
gnulibから実装した方がいいのかな? 不特定多数に文字だけで意思疎通するには答えやすい尋ね方というのがあると思うが、そんなことよりスクリーンセーバー作ろうぜ IME のオンとオフの実装で以前は
ImmGetContext
ImmSetOpenStatus
ImmReleaseContext
の3点セットで完全にオンとオフが機能していたように記憶しているのですが
今のWindowsでは機能しないことがあります(Windows 11 Home 22H2 OS Build 22621.2070)
この原因や解決策をわかる方がいたら教えてほしいです
Windows の公式サンプルでもこの3点セットでオンオフを実装しています
github.com/microsoft/Windows-classic-samples/blob/ac06e54a15e9a62443e400fffff190fb978ea586/Samples/Win7Samples/winui/input/ime/fullime/Main.C#L237 旧版MS-IMEじゃないとダメなんじゃないっけ?知らんけど 心配無用
Win11でなら上手く動かなくても許される y=f(x)のグラフを描こうとした場合、GDIのLineTo()で書けますが
グラフとx軸の間の領域を背景とは異なる色で描画しているアプリを
見かけることがあります。
ベタにやろうとすると(x,0)から(x,f(x))までを別のペンでLineToすれば
できそうですが、それだとあまりにも遅そうなんでどのようにするのが
一般的なんでしょうか? >>721
グラフを描画するのであれば、さすがにそういうのに向いたプログラミング言語を使ったほうが
本質的な所に時間を使えるんじゃないか? (分かりやすく)グラフが丁度収まる矩形サイズの描画メモリをCreateDIBSectionとかで確保して
掛け算や条件文をなるべく使わずに、直接メモリを塗りたい色で書き換えて、
最後にその描画メモリをバックバッファへ転送する、とか データ左端,Y軸下端 to データ左端,Y値 to データX値,Y値 to
... to データ右端,Y値 to データ右端,Y軸下端 (to データ左端,Y軸下端) 自分で線描画してメモリDCでダブルバッファするか
既製のチャートコントロールを使う
jもしくはavascriptにグラフ描画のは沢山あるからそ!をwebview2か何かで表示する いや、GDI+かDirect2Dを使えばいいんだよ メール関係のライブラリを知っていたら教えてください。
Windowsで使えるライブラリってないのでしょうか。 まああるかないかで答えればあるんだけどさ
メール関係って言われても色んな技術の集合だしなあ
その質問をこのスレで聞いちまう所がまずセンスないよね 送受信はたいしたことないけど
お行儀悪いのを忖度して可視化するのがとても大変 GetTempPathで取得できるフォルダ(AppData\Local\Temp)の中を見ると、
固定名と思われるサブフォルダを作っているアプリが結構あるのですが、
こういうアプリって、その固定名のサブフォルダが他のアプリと競合したり、
同じ名前のファイルがすでに存在していてサブフォルダを作るのに失敗したりするケースは、
ちゃんと想定しているものなんですか? >>741
想定していないアプリなんかは、事前に同じ名前の空ファイルでも置いておけば、
テンポラリフォルダを作れなくて正しく動かなくなってしまうということですよね? 同名のファイルが存在してサブフォルダが作れずに阻害された後
どうなるかも作り手次第だろうね
名前を変えて悪あがきするか、エラー報告して終わるか、だんまりするか・・・ 単なるファイルのコピーすら気を付けても穴だらけだしな
その時点の知識で最良を目指すしかない >>740
そもそもTempは一時的なフォルダでしょ
本アプリは上書きで使っていくだけだから影響はないでしょ
キャッシュや恒久的に使用するデータをそこに保存している場合は不具合のもとだろうけど
データ検証しない場合はエラー吐いて落ちるだけじゃね? Tempフォルダの中身は削除されても文句言えない物だから
なんなら同名あったら問答無用で削除して自分用作るすらあると思うわ その通り
既存の同名があって作成者が自分じゃなければ消して新しく同名で造れば良い >>740
勝手に数字をつけて存在しない名前を探してくれるAPIがあっただろ
数字は16ビットなので65536個全部あったらだめだが APIを呼び出した次の瞬間名前が衝突する可能性も考慮するんだぞ みなさんありがとうございます。
>>745-748
テンポラリファイルではなく、固定名のサブフォルダを作るアプリに対する疑問でした。
フォルダ上に同名のファイルがあったら、その名前のサブフォルダは作れないですし。
確かにそれを言い出したら、インストール時も、
Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。 >>750
作る前に存在の有無ぐらい確認するでしょ それはアプリ作成側がそこまで思いを致すかどうかなんだよ >>750
テンポラリファイルではなく、固定名のサブフォルダを作る場合は
C:\Users\ユーザー名\AppData\Local\会社名
で作るのが一般的では?(暗黙のルール?)
個人で作ってるならアプリ名を元に他と被らないようにするとか