berryzplus
berryzplus
GITHUB_TAG_HEAD_URLというのを作るのもアリかも知れない・・・（言いっぱなし 変数名 | 意味 -- | -- GITHUB_HEAD_URL | 最新masterのHEADコミットURLを指す GITHUB_PR_HEAD_URL | PRのHEADコミットURLを指す GITHUB_TAG_HEAD_URL | リリースタグのHEADコミットURLを指す バージョン情報ダイアログに表示する（or リンクさせる）のは、この中のどれか1つでいいような。（実装大変そうですが :cry:
あかん、TAG HEADなんてないんやね。 https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta4 を表示したときに出るリンクに紐付けられないかと思っただけです。 > Ver2.4.0 beta4 (Unicode版) > @KENCHjp KENCHjp released this Feb 15, 2020 · [8 commits](https://github.com/sakura-editor/sakura/compare/v2.4.0-beta4...master) to master since this release これ、ということになるのかな？ https://github.com/sakura-editor/sakura/compare/v2.4.0-beta4...master
ちがうな・・・。 `https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta4/commits/13ebfd36d5cda933bfa9681b91e5cbe544c2628f` という形式が使えればそれが正しい気がする。 しかし、このURLで表示されるページは `https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta4` と同じ気がする - https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta4/commits/13ebfd36d5cda933bfa9681b91e5cbe544c2628f - https://github.com/sakura-editor/sakura/releases/tag/v2.4.0-beta4
> https://github.com/sakura-editor/sakura/tree/v2.4.0-beta4 > > でいいと思います。 じゃ、それで（そういうのがあるのも知らんかったｗ PR #1201 で出してるリッチエディット採用の提案は、コピペ用バージョン表記の分かりやすい形式を模索するためのものだったりします。 現在の形式 ``` サクラエディタ v2.4.0.0 32bit DEBUG dev (GitHash xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) (GitURL http://github.com/ACOUNT_NAME/PROJECT.git) ``` 変更後の最新master例 ``` サクラエディタ v2.4.0.0 32bit (URL https://github.com/sakura-editor/sakura/commit/eec7d9a0) ``` 変更後のPRビルド例...
## 概要 #1240 のコメントに書いてきたんですけど、この部分の対応が未実施です。 > 特にParseCommandLineのほうは、リソース文字列表示なので、特殊な言語ファイルを読み込むと、バッファオーバーランする可能性があるので、それっぽい関数に変更してほしいです。 ## 「それっぽい関数」って何やねん！ Windowsのリソース関数には、リソースの種類に応じて色んなものがあります。 ビットマップなら `LoadBitmap`、文字列なら `LoadString` というように専用関数があります。 リソースの種類に関係なく、EXE/DLLに含まれるリソースを直接検索する `FindResource` なんてものもありますが、「リソースの種類」に応じた専用関数を使うのが基本です。 このあたりのWindows API基礎知識を踏まえると「何かの情報を埋め込むことができる文字列」に対する「リソースの種類」があるんじゃないか？と考えられると思います。 利用できる専用関数の一覧は`FindResourceEx`関数のマニュアルに書いてあります。 https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-findresourceexa 「何かの情報を埋め込むことができる文字列」を処理する専用関数・・・ `FormatMessage`関数がこれに該当すると思われます。 https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage ## サクラエディタの課題事項 サクラエディタのリソース文字列は、現在すべて `RT_STRING` になっています。 これは EXE/DLL...
たぶん旅立たないぞ。 現状の分析からすると、フォーマットのやり方じゃなくて「無駄にリソース化してるとこをベタ書きに戻そうぜ！」って言い出す可能性のが高いです。 理由があるならモダンじゃなくていいし、C言語でもアセンブラでもいいです。
PPAの実行コンテキストを外から指定できる仕組みを作ったとして、 仕組みを活用するには `CEditView` を生成できる仕組みが必要。 https://github.com/sakura-editor/sakura/blob/b5d590011f05e93ec423f5d3fe03dcbae1849eef/sakura_core/macro/CPPA.h#L275-L278 現状、`CEditView`をインスタンス化するには`CEditDoc` をインスタンス化していることが必要で、 `CEditDoc` をインスタンス化するには共有メモリの初期化化が完了している必要がある。
高解像度ディスプレイ対応、いつかはやりたいです。やるのは賛成 :smile: HighDPIには何段階かのステップがあると思っています。 ステップ | 内容 ---- | ---- 72dpi | 旧世代のディスプレイ解像度。大昔のMacやVisual Basicと互換。 96dpi | windows 95世代のディスプレイ解像度。モバイルノートなどのディスプレイ解像度として今も現役です。 HighDPI | windows vista世代から登場。いわゆるFull HDディスプレイに対応するための仕組み。旧来のDPIで作られたアプリは実際の解像度に合わせて拡大されるようになった。高DPI対応アプリは自動拡大の対象外でサクラエディタはこれに対応していることになってます。（実は未対応な部分が多いんですが :cry:） HighDPI(PerMonitor) | windows 8.1世代から登場。複数ディスプレイを接続した端末での使い勝手を向上するための仕組み。拡大率をウインドウごとに制御できるようになった。これができると、ノート＋4Kディスプレイなどの組み合わせで使うときも支障なく使えるようになります。「これに対応してほしい」という要望はtwitterや掲示板でよく見かけるので、そのうちやろうと思ってます。 フィルタなしの技術情報が欲しい方は[この辺](https://docs.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows)見てください。 この issue...
> リンク先に書いてありますが、PerMonitorには、Win10 1703から使えるようになったPerMonitor v2というものもあります。 説明できる自信がなかったので端折りました :cry: 「拡大率をウインドウごとに制御できるようになった」の説明はV2なんです。 V1は「拡大率をアプリごとに制御できるようになった」でちょっと違うはず。 まずは System DPI に対応させなきゃならんです・・・。
ちゃんと対応できてる部分と、対応できてない部分があって、 おそらくそれは、ちゃんと対応できてない部分だと思います。