berryzplus
berryzplus
> タイトルバーの左端に表示されるアイコンがぼやけているのも気になりますね。 クッキリハッキリぎざぎざ表示させる対応なら簡単にできそうです（キリッ
> じゃあ @berryzplus さんには以下のページのガイドラインに従った 256x256 サイズのアイコンを用意して頂きましょうか。 > > https://docs.microsoft.com/en-us/windows/desktop/uxguide/vis-icons 先生！ハードル高すぎます！ｗ クッキリハッキリぎざぎざってのは単にスケーリングするだけの対応を行う場合の話です。 アイコン読み込み箇所は共通化されているので、そこでsystem dpiに合わせたスケーリングを行えば実現可能と思われます。
超HighDPI端末でサクラエディタを表示したときにどう見えるかを示す画像を貼ります。
> ヒンティングはオフの方が好きです。 そこに食いつかれるとは思っても見ませんでした。出してみるものですねｗ > そして新しいバージョンの DirectWrite は Vista にバックポートされていません。 対応OSの話題で vista を外した理由の一つがこれです。 DirectWrite対応はまだまだずっと先の話だと思っていますが。 > うらやましい。ゲームができる４Kモニタが欲しい。 実は借り物、明日返却 :sob: 画面小さいのに4Kだから、推奨拡大率250%という無茶な値になってます。 15.4インチUHDのノートパソコンです。
> メニューのアイコン表示が小さい CMenuDrawerのリファクタリング試行中です。 辻褄を合わせるためにかなり大きな構造変更をすることになりそうです。
> ツールバーのアイコン表示が小さい > メニューのアイコン表示が小さい > 共通設定のツールバータブのリストボックスのアイテムに表示しているアイコンが小さい この3つ、もう少し整理したら出せる感じです。 画像ファイル読込み時にサイズをチェックして小さいアイコンだったらStretchBltで引き延ばす、という内容。実際にHighDPI向けの大きなイメージを用意したらそれはそれで動く感じを想定しています。アイコンの拡大はうまくいきそうだけど共通設定「ツールバー」のとこの表示がおかしくなってるのとか、細かいとこの対応中です。
> どう対応したらよいのでしょうね。 すんません、ぼくも分からんです。 > 今までどうしてきたのかご存じの方に伺いたいです。 してない（つもり。）です。 マクロにバージョン判別機構を導入してはどうか？という提案が出たことがあります。 > 「SourceForgeに投稿されたもかさん他のパッチをそのままこちらで取り込んでよいのか」も明らかにしたいところだと思います。 （取り込んでも）良い、だと思っています。 しかしながら導入実績は1件しかなかったと思います。 既にそのままでは取り込めませんし、当時とC++の規格が違うので(ry > SourceForgeとGitHubのそれを同一プロジェクトとみなすことにSourceForgeの方々が揃って同意しているのかが後から来た人間にはよく分かりません。取り扱いについて何らかの合意があるならばご教示くださるとうれしいです。 いちおう、ここのプロジェクトを立ち上げたのは SourceForge 時代のコードの 7割くらいを書いた @kobake さんなので、後継プロジェクトと考えて良いと思います。旧プロジェクトからの移行メンバーで正体を明かしているのは3人だけで、全体の規模を考えるとかなりアレなんですが、良いことにしておきます。（おそらくみなさん引退されたりクラスチェンジされているはず。歴史20年っすから。） なお、zlibライセンスはMIT同様にかなり緩いライセンスなので、ライセンスに則ってパッチを適用する分には投稿者本人の合意を得なくとも何の問題もありません。
## 総評 指摘内容は正しいと思いますが、周辺課題が多いので放置してました。 ## ~~問題「1つめ」の直し方~~ ```c++ if( szFuncDec[0] == '\0' ){ ``` ~~ここでやってるのは「機能名の取得」です。~~ ~~関数系機能の定義を走査して、機能番号が見つからなかったらコマンド系機能を走査する~~ ~~をやりたいんだと思うので、取得できてるかを見た方が良さそうに思いました。~~ (追記：マクロコマンドでもマクロ関数でも正しく名前が取れることを確認しました。) ## 問題「2つめ」の直し方 ```c++ // L"未定義のエラー\nError_CD=%d\n%s" auto_snprintf_s( szMes, _countof(szMes), LS(STR_ERR_DLGPPA5), Err_CD, to_wchar(Err_Mes) ); ``` 修正により...
`IsBadStringPtr` は使わないほうがよいです。 https://github.com/sakura-editor/sakura/blob/2deb79197c608f00897453a762d9178d07fc59e5/sakura_core/macro/CPPA.cpp#L367-L371 `IsBadStringPtr` には副作用があり、関数名の印象に反して「指定された文字列ポインタが不正であることを安全に確認する」ことはできないためです。 https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-isbadstringptra
逆ですね・・・ > 関数系機能の定義を走査して、機能番号が見つからなかったらコマンド系機能を走査する をやりたいんだと思うので、取得できてるかを見た方が良さそうに思いました。 先にマクロコマンド 320件 から機能IDを探し、 なかったらマクロ関数 61件 からも探す、がやりたいことです。 if 文の記述が誤っていることによる効果は、以下です。 * エラー発生元がマクロ関数だった場合に、機能名が取れない。（実害あり） * エラー発生元がマクロコマンドだった場合に、無駄な検索が走る。（実害なし）