profile
viewpoint

beru/demosaicing 1

demosaicing practice

beru/flirt 1

fork of flirt. http://flirt.sourceforge.net/

beru/AdderNet 0

Code for paper " AdderNet: Do We Really Need Multiplications in Deep Learning?"

beru/binn 0

Binary Serialization

push eventberu/tflite_test

beru

commit sha cd023a77c96f1b3e0c81f90b41976668dfc7169e

関数化

view details

push time in 2 days

issue commentsakura-editor/sakura

テストをビルドするときに毎回googletestがビルドされる。

現状で200個くらいのテストケースのうち、単体テストじゃないテストケースは2つだけです。

単体テストできない設計は設計バグです という主張はアリだと思うので、 アプリ全体を可能な限りグローバル変数に依存しない書き換えていくリファクタリングもアリだと思います。

まぁ、基本的にミッションインポッシブルだとは思うんですけど。

そういうリファクタリングをしたいという主張を自分はここでしていないと思いますが、いったい何からそう読み取ったんでしょうか?berryzplus さんの頭の中で導き出した一定の結論を前提とした事が文章として補足されずにいきなり話題に登場している印象を受けます。分かる人なら分かるよね的なノリで進めているのでしょうか?とはいえ想像抜きでの会話なんて無理な事も確かです。

仮に Google Test から doctest に移行するとテストフレームワークの機能差故に実施出来なくなるテストケースが一部あるとしたら、それは省いてしまえば良いのではないかと考えています。それらのテストケースはどうしても取り除きたくはないと言われればそこで話は終了してしまいます。ですがそこまで保守する必要があるテストケースが存在するのかどうかは疑問です…。

自分がGoogle Test から doctest に移行したいって主張しているのは単にビルドシステムのギミックを排除したいからで、それによって発生するテストケースの低減は考慮してません。そんな提案は考慮の価値無しと言われたらそれでこのN回目の話はお終いで、来年も再来年も Google Test を使い続けることになるのかなと思います。

sanomari

comment created time in 2 days

issue commentsakura-editor/sakura

テストをビルドするときに毎回googletestがビルドされる。

doctesthpython互換の単体テストを作る仕組みですよね。

そういう認識ではないです。

https://github.com/onqtam/doctest

の事です。名前が被ってますが…。

サクラエディタは単体テストを書けないコードで構成されているので、移行は不可能だと思います。 (移行するには、先に単体テストできるように改修することが前提になります。)

Google Testって一般的なうたい文句は単体テスト用のライブラリだと思いますが、単体テストを書けないコードをそれを使ってテストしてるのも不思議な話ですね。

説明が面倒で自明な行間のごにょごにょの事情できっと移行がOutOf眼中(死語)なんですね。

sanomari

comment created time in 2 days

push eventberu/tflite_test

beru

commit sha 4fd6674c7826158db36df8011f18e3a327117dca

ComputePaddingWithOffset 関数の確認用 html 作成

view details

push time in 4 days

push eventberu/tflite_test

beru

commit sha 3c267c81757cbe59eab347772b0b48833e8fb97c

記述の見直し

view details

push time in 5 days

issue commentsakura-editor/sakura

Thank you very much for the free open source program!

Пожалуйста. благодарю вас за доброта.

Шоу должно продолжаться!

mrkaban

comment created time in 5 days

PullRequestReviewEvent

push eventberu/tflite_test

beru

commit sha e893ec24f58b3eaecc2b42ef7df8dbd90a8d9e14

int8 同士の Conv2D の確認

view details

push time in 5 days

issue commentsakura-editor/sakura

Grepダイアログ部品配置の改善提案

日本語版のリソースファイル英語版のリソースファイル は別れているので配置の調整は個別に出来るので大丈夫じゃないかと思います。別の見方をすれば個別に調整する必要があるのでその分の手間は必要です。

あと英語版の優先度は低いと思うので必ずしも同時に対応する必要は無いと個人的に思います。

suconbu

comment created time in 6 days

Pull request review commentsakura-editor/sakura

利用できないコマンドラインオプション「-WQ(INIファイルを出力して即終了)」を削除する

 void CFileNameManager::GetIniFileName( LPWSTR pszIniFileName, LPCWSTR pszProfNam 		if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_szPrivateIniFile[0] != L'\0' ){ 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bReadPrivate = true; 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = true;-			if( CCommandLine::getInstance()->IsNoWindow() && CCommandLine::getInstance()->IsWriteQuit() )-				m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = false;  			// マルチユーザ用のiniフォルダを作成しておく 			if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate ){

少し動作確認してみました。

Release x64 構成でビルドすると sakura.exex64/Release フォルダに作成されますが、そこに下記の内容に sakura.exe.ini ファイルを配置します。

(なお、sakura.exe.ini ファイルが sakura.exe と同じ場所に無い状態で起動すると sakura.exe と同じ場所に sakura.ini ファイルが作成されます。MultiUser=0 にした時も同じ動作になります。)

[Settings]
MultiUser=1
UserRootFolder=2
UserSubFolder=sakura_settings

起動すると %USERPROFILE%/Documents/sakura_settings/ フォルダが作成されて、そのフォルダの中に sakura.ini ファイルが作成されました。

そのフォルダの中の sakura.ini ファイルを削除してからサクラエディタを終了すると、そのフォルダの中の sakura.ini ファイルが再度作成されていました。

%USERPROFILE%/Documents/sakura_settings/ フォルダを削除してから、サクラエディタを終了すると %USERPROFILE%/Documents/sakura_settings という名前のファイルが作られました。中身は sakura.ini 相当です。ただし次にサクラエディタ起動時に読んではくれません。

挙動的にPR前後で変わっているかと思ったんですが、どうも同じみたいですね。

リファクタリングの範疇を超えていますしイレギュラーな操作に関する事なので対応不要かもしれませんが、フォルダが無かったらフォルダを作成する処理が ini ファイルを保存する際には常に行われると良いのではないかと思いました。

berryzplus

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

利用できないコマンドラインオプション「-WQ(INIファイルを出力して即終了)」を削除する

 void CFileNameManager::GetIniFileName( LPWSTR pszIniFileName, LPCWSTR pszProfNam 		if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_szPrivateIniFile[0] != L'\0' ){ 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bReadPrivate = true; 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = true;-			if( CCommandLine::getInstance()->IsNoWindow() && CCommandLine::getInstance()->IsWriteQuit() )-				m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = false;  			// マルチユーザ用のiniフォルダを作成しておく 			if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate ){

14c8faf8ebf196c745894d132767873c6813795e で色々とリファクタリングが行われていますね。

従来は CFileNameManager::GetIniFileName で行われていた ini フォルダを作成する処理が、CShareData::InitShareData に移動しているのが気になりました。

berryzplus

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

利用できないコマンドラインオプション「-WQ(INIファイルを出力して即終了)」を削除する

 void CFileNameManager::GetIniFileName( LPWSTR pszIniFileName, LPCWSTR pszProfNam 		if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_szPrivateIniFile[0] != L'\0' ){ 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bReadPrivate = true; 			m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = true;-			if( CCommandLine::getInstance()->IsNoWindow() && CCommandLine::getInstance()->IsWriteQuit() )-				m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate = false;  			// マルチユーザ用のiniフォルダを作成しておく 			if( m_pShareData->m_sFileNameManagement.m_IniFolder.m_bWritePrivate ){

ここの判定は不要なので削ってしまった方が良いと思います。

berryzplus

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentsakura-editor/sakura

Grepダイアログ部品配置の改善提案

上のスクリーンショットを見て思った点を書きます。

  • ダイアログのマージンが少しだけ大きい気がしました。
  • 検索、キャンセル、ヘルプ、の3つのボタンの横幅はもっと狭くても良い気がします。
  • ラベルの横幅は、今の日本語表示の場合はもっと詰めても切れない気がします。
  • エディトの左側に位置するラベルの位置が少し上寄りになっているように見えます。

文章で書いてもイメージが湧きづらいかもしれないので、実際にこちらで調整して確認した上で画面のスクリーンショットを載せるべきかもしれないですね…。

suconbu

comment created time in 6 days

pull request commentsakura-editor/sakura

CFigure_Comma::Matchの実装内容を他のCFigureと合わせる

このPRの変更と直接は関係ないですが気になった点として、タブ位置を再計算するタイミングがレイアウト情報の変更時で文書の編集時には行われない点です。

あと完全にこのPRと関係ないですが、サクラエディタが Markdown を表示する際に表を整形表示してくれたら見やすいかもと思いました。

berryzplus

comment created time in 6 days

PullRequestReviewEvent

pull request commentsakura-editor/sakura

利用できないコマンドラインオプション「-WQ(INIファイルを出力して即終了)」を削除する

不味くは無いです、レビューありがたいです。

berryzplus

comment created time in 6 days

issue commentsakura-editor/sakura

テストをビルドするときに毎回googletestがビルドされる。

自分は googletest から doctest に移行して今存在する色々な仕組みを撤廃してすっきりさせたいです。googletest を使うためにビルド周りに手が入っている色々を列挙すると結構長くなるので、正直よくやるなぁ…と思います。

今までに主に @m-tmatma さんや @berryzplus さんが CI や Unit Testing を整備してくれていてインストーラー入手しやすかったりで超有難いんですが、構成の単純さは犠牲になってしまっていると思います。

tools の中の ChmSourceConverter (他に ToolBarTools フォルダ以下のツールも).NET Framework を使っていますが、久々に違うPCでサクラエディタのビルドを bat ファイルを実行して行うと色々と失敗したりして気付いたりしました。とはいえまぁそれが嫌なら C++ で書き直せばいいだけの話ではありますね。

sanomari

comment created time in 6 days

issue commentsakura-editor/sakura

Grepダイアログ部品配置の改善提案

ちなみに、皆さんダイアログリソース編集時は GUI エディタではなくテキスト編集でやられているんでしょうか。

自分はそうしてます。編集後の配置の確認ではリソースエディタで見たり実行して確認したりです。 比較的効率は悪いですが、たまにしか変更しないのであまり気にはしてないです。

suconbu

comment created time in 8 days

issue commentsakura-editor/sakura

開発コアメンバー募集

他に思い付くメンバー特典としてラベルの編集や適用が行えるので表示を装飾する事が出来ます。

kobake

comment created time in 9 days

Pull request review commentsakura-editor/sakura

プロパティシートに対してシステムフォントを設定

 void SetFontRecursive( HWND hwnd, HFONT hFont ) }  /*!-	ダイアログボックス用のフォントを設定(日本語以外では何もしない)+	ダイアログボックス用のフォントを設定 	@param[in]	hwnd		設定対象ダイアログボックスのウィンドウハンドル+	@param[in]	force		強制設定有無(TRUE:必ず設定 FALSE:日本語の場合は設定しそれ以外では設定しない) 	@return		ダイアログボックスに設定されたフォントハンドル(破棄禁止) */-HFONT UpdateDialogFont( HWND hwnd )+HFONT UpdateDialogFont( HWND hwnd, BOOL force )

BOOL force の代わりに bool unconditional とかいうのも書き方の候補として思い浮かびました。 前者の方がタイプ量が少ないですね。

suconbu

comment created time in 9 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentsakura-editor/sakura

開発コアメンバー募集

もしよろしければ @suconbu さんいかがでしょうか?

推薦させていただきます。Owner の方よろしければ Invite お願いします。

kobake

comment created time in 9 days

PullRequestReviewEvent

pull request commentsakura-editor/sakura

プロパティシートに対してシステムフォントを設定

自分の環境でも変更前後でスクリーンショットを取りました。

変更前
image

変更後
image

変更後の方はフォントの見た目が統一されて良いですね。

suconbu

comment created time in 9 days

pull request commentsakura-editor/sakura

プロパティシートに対してシステムフォントを設定

ギザギザっていうのは多分フォントのラスタライズでアンチエイリアスが掛かっていない事を指しているんだと思います。 元の表示は小さいサイズのドットフォントを引き延ばしたような表示ですね。

suconbu

comment created time in 9 days

issue commentsakura-editor/sakura

Grepダイアログ部品配置の改善提案

新しいレイアウトの方がよさそうに見えますね。

ウィンドウの横方向のリサイズがなんとなく出来ても良さそうな印象を受けますね。

検索対象ファイルの設定で複数のファイルやフォルダを指定する際に1行の入力箇所で指定するの大変なので、Windows10の環境変数のPathの設定時のような画面で編集が出来るといいなと思います。

suconbu

comment created time in 9 days

push eventberu/tflite_test

beru

commit sha c754cb246e479b8bb291e325668949ddcdf9c760

テスト追加

view details

push time in 10 days

pull request commentsakura-editor/sakura

ダイアログフォント美化

#1424 でリソーススクリプトを変更したのにマージ後にコンフリクトが発生しないのは、この変更が「ダイアログ」を対象にしているからなのかな?とか。( #1424の対象は「プロパティーシート」なのでちょっと違う・・・)

私の変更でも同じプロパティシートを編集していますが、たまたま同じ行に変更が入らなったようです。

システムフォントでなくシステムフォント風を使っている(≒高さは変わらない)のが理由で、高さの変更は影響しなかったかもです。

下記の変更で高さを変えた事との関連を話しているっぽいですね。

https://github.com/sakura-editor/sakura/pull/1424/files#diff-67955f03bb0bbb169f93ff6fa4998095L1190

いやーしかしこのPRでリソーススクリプトの調整が数多く行われましたね。リソースエディタでの編集ではなくてテキストエディタで編集してビルドして動作確認しての繰り返し作業だと思うのでかなり大変だったんじゃないですか?

suconbu

comment created time in 12 days

push eventberu/tflite_test

beru

commit sha bd125860834d40273ba5a60a453920df582f4958

確認を進める

view details

push time in 12 days

Pull request review commentsakura-editor/sakura

サクラエディタのコマンドライン引数に超長い文字列を指定するとクラッシュする問題に対処する。

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) { 	MY_RUNNINGTIMER( cRunningTimer, "CCommandLine::Parse" ); -	WCHAR	szPath[_MAX_PATH];-	bool	bFind = false;				// ファイル名発見フラグ-	bool	bParseOptDisabled = false;	// 2007.09.09 genta オプション解析を行わなず,ファイル名として扱う-	int		nPos;-	int		i = 0;-	if( pszCmdLineSrc[0] != L'-' ){-		for( i = 0; i < _countof( szPath ); ++i ){-			if( pszCmdLineSrc[i] == L' ' || pszCmdLineSrc[i] == L'\0' ){-				/* ファイルの存在をチェック */-				szPath[i] = L'\0';	// 終端文字+	const int nCmdLineWorkLen = static_cast<int>( ::wcsnlen( pszCmdLineSrc, INT_MAX ) );++	auto cmdLineWork = std::make_unique<WCHAR[]>( nCmdLineWorkLen + 1 );+	LPWSTR pszCmdLineWork = cmdLineWork.get();+	::wcscpy_s( pszCmdLineWork, nCmdLineWorkLen + 1, pszCmdLineSrc );++	// コマンドラインの解析を開始する位置(先頭部分をスキップする場合がある)+	int nPos = 0;++	// コマンドラインの先頭が '-' で始まっていない場合+	if( pszCmdLineWork[0] != L'-' ){+		// 先頭部分を空白を含むパスとして切り出せる場合は切り出す。+		WCHAR szPath[_MAX_PATH]{ 0 };+		for( size_t i = 0; i < _countof( szPath ); ++i ){+			const WCHAR& chSrc = pszCmdLineWork[i];

う~ん、他人の考えはよくわかりません。

berryzplus

comment created time in 12 days

PullRequestReviewEvent

pull request commentsakura-editor/sakura

ダイアログフォント美化

f4a552969c45dbaa6f1ff28fdb3d214f0d814010 では色々な箇所の調整がされていますね。 コミットメッセージに説明がしっかり書かれているのが良いですね。

suconbu

comment created time in 12 days

push eventsakura-editor/sakura

miwa

commit sha 4a7b4aa7e0ec0e482b8b50814b8635a5bfa300ff

ダイアログボックスでシステムフォントを使うようにする

view details

miwa

commit sha b0e4ee85f8a1597adbb4ac01ade264cd722655aa

文字切れ解消のためのコントロール高さ調整

view details

miwa

commit sha c0b3ba15585697ab8f25fb4c412d620f90256bb5

OnInitDialogの後でSetMainFontするようにする

view details

miwa

commit sha e4da55bf3c6a49a84d8ef0fb298f6daaa5879a98

共通設定ダイアログのシステムフォント化と配置調整

view details

miwa

commit sha b635eb40803b45ba4631704b6da0695c6f82ac4f

タイプ別設定ダイアログのシステムフォント化と配置調整

view details

miwa

commit sha 0259d1b37302ec7b747c570bcdb70f98c5372067

ファイルを開くダイアログのシステムフォント化

view details

miwa

commit sha 9b5063390323ad97edef20804dbac06fc4711de9

印刷プレビューダイアログのシステムフォント化と配置調整

view details

miwa

commit sha c184a6fcfc669f22e023ce7b3225b95ae577720d

フォント設定処理を共通化

view details

miwa

commit sha fdc661cc724c1075ada40c6ef1fdf8cf7ac2a8d1

日本語リソース以外のフォントはそのままに

view details

miwa

commit sha 68601d680b271e139fba7104d5a1166db4899374

汎用入力ダイアログの修正

view details

miwa

commit sha 1283afa2ea583d80ad821bb3e75983bda0d15a33

印刷ページ設定ダイアログを閉じた後フォントがおかしくなる問題を修正

view details

miwa

commit sha 024704aedab1dfcc5e17c1d897ed7840f90e4342

アウトライン解析ツリーヘッダ部のサイズ調整

view details

miwa

commit sha 54ca5100f0a73e7a95a57712c4169b1a6962f97c

関数名・キャッシュキー見直し

view details

miwa

commit sha 03657f7d53c0fab722dfc0e4c5fda4cb365dd282

バージョン情報ダイアログの文字切れ解消とURLの下線消えを修正

view details

miwa

commit sha f4a552969c45dbaa6f1ff28fdb3d214f0d814010

文字切れ/重なり修正 * 履歴とお気に入りの管理のヘルプボタンとサイズ変更グリップとの重なり * 共通設定->支援タブのmigemoとテキストボックスとの重なり * 共通設定->編集タブの「改行コードNEL,PS,LSを有効にする」の右側文字切れ * タイプ別設定->ウィンドウタブの「折り返し単位」の右側文字切れ * タイプ別設定->正規表現キーワードタブのDLL名下部文字切れ * 印刷ページ設定の「ヘッダー」付近のテキストボックス上部切れ

view details

miwa

commit sha 04120b3d63600580a843b382ab557f465c456520

「ドロップファイルは1つのみ有効」の文字切れ修正

view details

beru

commit sha bb83d9da22bb4f7e92904b31549f3e2b4b5048b8

Merge pull request #1421 from suconbu/feature/use_systemfont_in_dlg ダイアログフォント美化

view details

push time in 12 days

PR merged sakura-editor/sakura

ダイアログフォント美化 enhancement

<!-- 必須 --> PR の目的

すべてのダイアログボックスで Windows のシステムフォントを使うようにし文字の見た目を良くします。

※システムフォントではなくエディタと同じフォントの方が適当と思われる部分 (キーワード補完やアウトライン解析など) があります。この点は別の PR で対応したいと考えています。

例:

- -
現状 image
変更後 image

<!-- 必須 --> カテゴリ

  • 仕様変更

<!-- 自明なら省略可 --> PR の背景

<!-- 自明なら省略可 --> PR のメリット

ギザギザしていない、きれいな文字が表示されるようになります。 (Windows7 以前ではユーザーが選択しているフォントに依存)

MS Pゴシックが苦手な人も気持ちよく使えるようになるかもしれません。

<!-- なければ省略可 --> PR のデメリット (トレードオフとかあれば)

特にありません。

<!-- 仕様変更/機能追加の場合は必須 --> 仕様・動作説明

ダイアログボックスのフォントが「MS Pゴシック」からシステムフォント (下表) に変わります。

OS 標準のシステムフォント
Windows10 Yu Gothic UI
Windows8 Meiryo UI
Windows7/Vista: メイリオ (メッセージボックス)

<!-- 必須 --> テスト内容

  • システムフォントに「Yu Gothic UI」が設定されている状態 (Windows10 標準状態) で、すべてのダイアログボックスを表示させ、文字切れや文字重なりがないことを目視確認します。
  • フォント変更ツール (参考資料) にてシステムフォントに「Meiryo UI」「メイリオ」を設定し、それぞれ「印刷ページ設定」ダイアログにて文字切れや文字重なりがないことを目視確認します。 →全部確認するのは大変なのでサイズ調整前に一番文字切れが目立っていたものだけとしました。

<!-- わかる範囲で --> PR の影響範囲

<!-- なければ省略可 --> 関連 issue, PR

GREPダイアログ内の全コンボボックスに対してフォント設定で指定されたフォントを使用する #1400

<!-- なければ省略可 --> 参考資料

  • Meiryo UIも大っきらい!!:http://tatsu.life.coocan.jp/MySoft/WinCust/index.html
+525 -408

35 comments

16 changed files

suconbu

pr closed time in 12 days

pull request commentsakura-editor/sakura

ダイアログフォント美化

04120b3d63600580a843b382ab557f465c456520 の修正も確認して問題ないと思いますので Merge します。

suconbu

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventberu/tflite_test

beru

commit sha baa05b48806c96f0811e42aba400ec211806fb11

少し更新

view details

push time in 12 days

PullRequestReviewEvent

push eventsakura-editor/sakura

Katsuhisa Yuasa

commit sha 1a1408ba6b8e2f60d38d4c34a812ea9462a6b564

プロパティシートのコントロール表示のちらつき防止

view details

Katsuhisa Yuasa

commit sha 079929f9b9ad367e29b69b029d70b82561c3c9fb

SendMessage anywayz

view details

beru

commit sha 298ac44df29b409ec0095e8f5d395b6fed861109

Merge pull request #1424 from beru/reduce_flickering プロパティシートのコントロール表示のちらつき防止

view details

push time in 13 days

PR merged sakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

<!-- これはコメントです。ブラウザで表示されません。 --> <!-- Preview のシートで見た目のチェックができます。 -->

<!-- 必須 --> PR の目的

<!-- PR の目的を記載してください --> <!-- 参考: https://github.com/sakura-editor/sakura/wiki/Pull-Request-%E3%82%92%E9%80%81%E3%82%8B%E9%9A%9B%E3%81%AE%E6%B3%A8%E6%84%8F -->

共通設定の画面において、主にリスト系のコントロールの内容を切り替える際にちらついて表示されるので、それがなるべく起きないようにするのが目的です。

<!-- 必須 --> カテゴリ

<!-- 編集 必須 --> <!-- 以下はテンプレートなので、追加、削除してください。 -->

  • その他の問題

<!-- 自明なら省略可 --> PR の背景

<!-- PR を行う背景を記載してください -->

画面を操作していてコントロールの表示のちらつきが気になったので下記の対策を入れました。

  • リスト系のコントロールの表示内容を差し替える前後で WM_SETREDRAW メッセージを送る事で表示更新のタイミングを制御
    • コントロールに対して行ってもちらつきが減らなかった場合は親ウィンドウのダイアログ(プロパティシート)に対してメッセージを送るようにしましたが、その場合は後で InvalidateRect を実行しないと画面の表示が更新されないので、そうするようにしました。
  • リソースファイルのプロパティシートの拡張ウィンドウスタイルに WS_EX_COMPOSITED を付けてダブルバッファリングされるようにしました。これをやらないでもちらつきが特に気にならないレベルまで解消される場合もありますが、そうでない場合もあります。メカニズムがいまいち不明なのと、動作環境によって挙動が変わるかもしれません。

<!-- 自明なら省略可 --> PR のメリット

<!-- PR のメリットを記載してください。 -->

表示のちらつきが減ります。

<!-- なければ省略可 --> PR のデメリット (トレードオフとかあれば)

<!-- PR のデメリットやトレードオフ等あれば記載してください。 -->

WS_EX_COMPOSITED スタイルを付けてダブルバッファリングしているのでメモリ使用量が増えます。ただし最近のPCであれば問題になるような増加量では無い筈です。

<!-- 仕様変更/機能追加の場合は必須 --> 仕様・動作説明

<!-- 仕様変更の場合は、変更前後の仕様を記載してください。 --> <!-- 機能追加の場合は、その仕様や動作を記載してください。 --> <!-- その他の場合は、必要に応じて処理の仕様や動作説明を記載してください。 -->

<!-- 必須 --> テスト内容

<!-- PR を投げるにあたってテストした内容を記載してください --> <!-- PR を投げないとテストできない、or 難しい場合、その旨記載すること --> <!-- テストが十分でない場合、Draft PR とする or タイトルに [WIP] とつけること -->

画面表示を目視で確認しました。

リスト表示のちらつきが減ったかどうかの確認は、ドロップダウンリストの選択を切り替えるとリストの表示内容が切り替わるので、その際のちらつきが減ったかどうかを確認しました。

<!-- わかる範囲で --> PR の影響範囲

<!-- 既存の処理に対して影響範囲を記載してください。 -->

下記の画面に手を入れました。

  • 共通設定
    • メインメニュー
    • ツールバー
    • タブバー
    • キー割り当て
    • カスタムメニュー
    • 強調キーワード

<!-- なければ省略可 --> 関連 issue, PR

<!-- 関連する issue, PR の情報を記載してください。 --> <!-- #xxx と書くと チケット xxx に対して自動的にリンクが張られます。 --> <!-- 参考: https://help.github.com/en/articles/closing-issues-using-keywords--> <!-- issue, PR の URL をそのまま貼り付けても OK -->

<!-- なければ省略可 --> 参考資料

<!-- 参考になる資料の URL 等あればここに記載御願いします --> <!-- 説明に必要なスクリーンショットがあれば貼り付けお願いします。--> <!-- 画像ファイルをこの欄にドラッグ&ドロップすれば画像が貼り付けられます -->

https://docs.microsoft.com/en-us/windows/win32/gdi/wm-setredraw https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-invalidaterect https://devblogs.microsoft.com/oldnewthing/20171018-00/?p=97245 https://devblogs.microsoft.com/oldnewthing/20110124-00/?p=11683

+24 -12

13 comments

7 changed files

beru

pr closed time in 13 days

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

レビューありがとうございます。Mergeします。 もし問題が見つかったらあとで修正します。

beru

comment created time in 13 days

pull request commentsakura-editor/sakura

ダイアログフォント美化

今になって気づいたのですが、表示スケールが 200% にもなると元の MS Pゴシック でも ClearType が適用されて綺麗に表示されるのですね。。

表示スケール 100% の場合にどうなるか確認してみました。

変更前

image

変更後

image

変更後は書体が変わってアンチエイリアシングが掛かってますね。変更後の方が行間が少し空いていて読みやすいですね。

アンチエイリアシングすると表示が必要以上にぼやけてしまって人によってはそれが気になりますが、高解像度のディスプレイで表示スケールを上げて利用する分にはあまり気にならないですね。

suconbu

comment created time in 13 days

PullRequestReviewEvent

pull request commentsakura-editor/sakura

ダイアログフォント美化

@suconbu さん

確認された時のモニタの設定は 200% でしょうか? ~(DPI 設定が 100%, 125% では発生しないようです)~ →100%, 125% の時、一行目の文字切れは発生しませんが二行目「Last Modified」以降が表示されない問題は発生していました。

はい、ディスプレイ設定の拡大縮小とレイアウトが 200% の環境で確認しました。

suconbu

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventsakura-editor/sakura

novice123

commit sha 9efb280d3cbe532239cee322bce67a7668f0ba77

[patchunicode#1050] エンコーディング名による文字コードの設定の修正 https://sourceforge.net/p/sakura-editor/patchunicode/1050/ skrw_fix_xml_detect_v0_5.patch ・いくつかのエンコーディング名の別名を追加 MS932やSJIS、ハイフン・アンダーバー考慮 ・xml encoding名が不明な名前だった場合にUTF-8と認識されるバグを修正 例 <?xml version="1.0" encoding="MS932" ?> ・xml宣言がありencoding名がない場合は、UTF-8固定だった(規格どおり)ものを自動認識を優先してそれでも不明ならUTF-8にするように修正

view details

Kohki Akikaze

commit sha c14cd385b1b59cdfe76b6a6acb85b22d3b4d0e94

memicmpを_memicmpに置換

view details

Kohki Akikaze

commit sha 463d262dd2485b0bd57097a60f5db5604a4e2747

追加したエイリアスを認識できていなかった問題を修正

view details

Kohki Akikaze

commit sha 8686e07ffd42a3406e5ab570b4183d517456d34f

変更漏れと思わしき箇所に対応を行った

view details

Kohki Akikaze

commit sha 88ebecc2db9bee4b72d8c685dc3c8b803e0191b9

追加したif文の判定結果が常に偽となる可能性を排除する

view details

Kohki Akikaze

commit sha a9524d18a3ebeb1c5d0575373342284955dee20d

認識可能なエイリアスを拡充する

view details

Kohki Akikaze

commit sha 57bf7ae44e0f887db745ba13eaf10f55e0bb5617

文字コードの定義で重複しているものを一つにまとめた Windows-1252に対してCODE_LATIN1と1252の二つが定義されており、 それぞれの変換処理には前者の場合CLatin1::Latin1ToUni関数、後者の場合CCodePage::CPToUni関数が使われている。 Latin1(ISO-8859-1)とWindows-1252で差異のある0x80~0x9fの変換には、 どちらにおいてもMultiByteToWideChar関数にコードページ1252を指定して実行するようになっているため、 Latin1とWindows-1252を区別せずに処理しているように見えることから、後者の指定を除去することとした。

view details

Kohki Akikaze

commit sha d4a1777197c52c542e7d14ccc3c0bb60942cce37

コード上のコメントを更新

view details

Kohki Akikaze

commit sha 79e730701d27f0de1970f1ced5fdaa5a9a39d143

GetEncofing_metaでのif文の判定回数を減らす

view details

Kohki Akikaze

commit sha 7d0d297d55dae08f75fee83df17e7b21bed15c08

エンコーディング名の定義にマクロを導入する

view details

Kohki Akikaze

commit sha 64fe1e0eea53eaa0a45abe7acf4b3c5264bb4179

日付の入ったコメントが残っていたので除去する

view details

Kohki Akikaze

commit sha 39159b0d3a3abe196fd77a14e47dda7b0fc7767e

追加した変数が状況次第で使われない可能性に対応

view details

Kohki Akikaze

commit sha e821b7cb70bbce4c69a540dacbbea662220cbeb9

文字数のチェックにループを使わないようにする

view details

Kohki Akikaze

commit sha d3d8a4d20ca864d7367d225713882b4f75ece71c

AutoDetect系関数における判定処理を統一する

view details

Kohki Akikaze

commit sha 0ea3203919ec15fdc5c23e8ff76050122d7f79a0

encoding指定が引用符で終わっていない場合に判定処理を行わないようにする ::find_first_ofの戻り値がnposだった場合、MatchEncodingの第2引数が負数となってしまうため、 MatchEncodingでの判定処理が成功しなくなってしまう。 もしnposの場合は判定を省略し、指定がなかったものとして扱うようにする。 std::stringを使用していた箇所をstd::string_viewを使用するように変更する。

view details

beru

commit sha ea149b0375d04e5f569f6597e74fdf596f35c35c

Merge pull request #1422 from kazasaku/feature/fix_detect_charset_from_xml_declare XML宣言を用いた文字コード判別処理を強化する

view details

push time in 13 days

PR merged sakura-editor/sakura

XML宣言を用いた文字コード判別処理を強化する 🐛bug🦋

<!-- これはコメントです。ブラウザで表示されません。 --> <!-- Preview のシートで見た目のチェックができます。 -->

<!-- 必須 --> PR の目的

<!-- PR の目的を記載してください --> <!-- 参考: https://github.com/sakura-editor/sakura/wiki/Pull-Request-%E3%82%92%E9%80%81%E3%82%8B%E9%9A%9B%E3%81%AE%E6%B3%A8%E6%84%8F --> XML宣言のencoding指定を使った文字コード判別処理を強化し、文字化けが発生する可能性を減らします。

<!-- 必須 --> カテゴリ

<!-- 編集 必須 --> <!-- 以下はテンプレートなので、追加、削除してください。 -->

  • 不具合修正

<!-- 自明なら省略可 --> PR の背景

<!-- PR を行う背景を記載してください --> XML宣言のencoding指定に未知のエンコーディング名が指定されていたとき、これをUTF-8として認識するバグがありました。 patchunicode#1050で提案されている修正パッチを取り込み、この問題を解決するものです。

<!-- 自明なら省略可 --> PR のメリット

<!-- PR のメリットを記載してください。 -->

  1. XML文書のencoding指定に記述された(サクラエディタにとって)未知のエンコーディング名を新たに認識できるようになります。
    • この点はcodingの記述があるファイルやHTMLファイルのcharset属性に対する判別処理でも享受できます。
  2. エンコーディング名を認識できなかったとしても、自動判別によって文字化けを極力回避できるようになります。

<!-- なければ省略可 --> PR のデメリット (トレードオフとかあれば)

<!-- PR のデメリットやトレードオフ等あれば記載してください。 -->

  • 特にないと思います。

<!-- 仕様変更/機能追加の場合は必須 --> 仕様・動作説明

<!-- 仕様変更の場合は、変更前後の仕様を記載してください。 --> <!-- 機能追加の場合は、その仕様や動作を記載してください。 --> <!-- その他の場合は、必要に応じて処理の仕様や動作説明を記載してください。 --> このPRに含まれる変更は次の通りです。

  1. エンコーディング名のエイリアスを追加した
    • エイリアスや表記ゆれなど、エンコーディング名の定義を追加。
    • パッチに含まれている16個のほか、WHATWGのエンコーディング仕様書などから20個を選定。
  2. 認識できないエンコーディング名がXML宣言に記述されているときに、UTF-8として認識される問題を修正した
  3. XML宣言にencoding指定がない場合でも自動判別処理が行われるようにした
    • 自動判別で文字コードを決められないときは、XML仕様に基づきこれまで通りUTF-8として扱う。
  4. 取り込みの過程で見つけた問題点を修正した
  5. エンコーディング名「windows-1252」が2回定義されていたので一つにまとめた
    • この点に関して確認したことを https://github.com/sakura-editor/sakura/pull/1422#issuecomment-703174189 に記述しています。
  6. エンコーディング名の定義方法を変更した
    • レビューにて提案された変更です。
    • マクロENCODING_NAMEを定義して文字数を自動算出するように変更し、文字数の数え間違いによってエンコーディング名が認識されなくなる問題を防ぎます。

<!-- 必須 --> テスト内容

<!-- PR を投げるにあたってテストした内容を記載してください --> <!-- PR を投げないとテストできない、or 難しい場合、その旨記載すること --> <!-- テストが十分でない場合、Draft PR とする or タイトルに [WIP] とつけること -->

テスト1(追加したエイリアスを認識するか)

  1. テストファイルのうち01~04を開き、文字化けが発生していないか確認する
  2. ステータスバーの文字コード表示が正しいか確認する
    • テストファイル01:SJIS
    • テストファイル02:EUC
    • テストファイル03及び04:JIS

テスト2(未知のエンコーディング名のとき)

  1. テストファイル05を開き、文字化けが発生していないか確認する
  2. ステータスバーの文字コード表示が「SJIS」であるか確認する

テスト3(encoding指定がないとき)

  1. テストファイル06を開き、文字化けが発生していないか確認する
  2. ステータスバーの文字コード表示が「UTF-8」であるか確認する

テストファイルの説明

テストファイル.zip

  • テストファイル_01.xml
    • Shift_JISのファイルで、新たに追加した名称(sjis)をXML宣言のencodingに指定
  • テストファイル_02.txt
    • EUC-JPのファイルで、新たに追加した名称(cseucpkdfmtjapanese)を1行目の# codingに指定
  • テストファイル_03.html
    • ISO-2022-JPのHTMLファイルで、新たに追加した名称(csiso2022jp)をcontent属性のcharsetに指定
  • テストファイル_04.html
    • ISO-2022-JPのHTMLファイルで、新たに追加した名称(iso2022jp)をcharset属性に指定
  • テストファイル_05.xml
    • Shift_JISのファイルで、XML宣言のencodingに未知の名称(shifutojisu)を指定
  • テストファイル_06.xml
    • UTF-8(BOMなし)のファイルで、XML宣言のencoding指定を省略

<!-- わかる範囲で --> PR の影響範囲

<!-- 既存の処理に対して影響範囲を記載してください。 -->

  • 次のファイルを開く際の文字コード判別処理
    • XML
    • codingの記述があるファイル
    • HTML(http-equiv属性またはcharset属性でエンコーディング名の指定があるもの)

<!-- なければ省略可 --> 関連 issue, PR

<!-- 関連する issue, PR の情報を記載してください。 --> <!-- #xxx と書くと チケット xxx に対して自動的にリンクが張られます。 --> <!-- 参考: https://help.github.com/en/articles/closing-issues-using-keywords--> <!-- issue, PR の URL をそのまま貼り付けても OK --> BugReport/195 patchunicode#1050 #1418

<!-- なければ省略可 --> 参考資料

<!-- 参考になる資料の URL 等あればここに記載御願いします --> <!-- 説明に必要なスクリーンショットがあれば貼り付けお願いします。--> <!-- 画像ファイルをこの欄にドラッグ&ドロップすれば画像が貼り付けられます -->

+211 -156

15 comments

1 changed file

kazasaku

pr closed time in 13 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

サクラエディタのコマンドライン引数に超長い文字列を指定するとクラッシュする問題に対処する。

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) { 	MY_RUNNINGTIMER( cRunningTimer, "CCommandLine::Parse" ); -	WCHAR	szPath[_MAX_PATH];-	bool	bFind = false;				// ファイル名発見フラグ-	bool	bParseOptDisabled = false;	// 2007.09.09 genta オプション解析を行わなず,ファイル名として扱う-	int		nPos;-	int		i = 0;-	if( pszCmdLineSrc[0] != L'-' ){-		for( i = 0; i < _countof( szPath ); ++i ){-			if( pszCmdLineSrc[i] == L' ' || pszCmdLineSrc[i] == L'\0' ){-				/* ファイルの存在をチェック */-				szPath[i] = L'\0';	// 終端文字+	const int nCmdLineWorkLen = static_cast<int>( ::wcsnlen( pszCmdLineSrc, INT_MAX ) );++	auto cmdLineWork = std::make_unique<WCHAR[]>( nCmdLineWorkLen + 1 );+	LPWSTR pszCmdLineWork = cmdLineWork.get();+	::wcscpy_s( pszCmdLineWork, nCmdLineWorkLen + 1, pszCmdLineSrc );++	// コマンドラインの解析を開始する位置(先頭部分をスキップする場合がある)+	int nPos = 0;++	// コマンドラインの先頭が '-' で始まっていない場合+	if( pszCmdLineWork[0] != L'-' ){+		// 先頭部分を空白を含むパスとして切り出せる場合は切り出す。+		WCHAR szPath[_MAX_PATH]{ 0 };+		for( size_t i = 0; i < _countof( szPath ); ++i ){+			const WCHAR& chSrc = pszCmdLineWork[i];

え、ここの参照外すと不適切なコードになってしまうんですか。世の中には色々な次元の適切さが有るんですね。

berryzplus

comment created time in 13 days

PullRequestReviewEvent

push eventberu/tflite_test

beru

commit sha d69676d66a123319d8a3c9da2a70bf2860716ad8

use property sheet

view details

push time in 13 days

Pull request review commentsakura-editor/sakura

サクラエディタのコマンドライン引数に超長い文字列を指定するとクラッシュする問題に対処する。

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) { 	MY_RUNNINGTIMER( cRunningTimer, "CCommandLine::Parse" ); -	WCHAR	szPath[_MAX_PATH];-	bool	bFind = false;				// ファイル名発見フラグ-	bool	bParseOptDisabled = false;	// 2007.09.09 genta オプション解析を行わなず,ファイル名として扱う-	int		nPos;-	int		i = 0;-	if( pszCmdLineSrc[0] != L'-' ){-		for( i = 0; i < _countof( szPath ); ++i ){-			if( pszCmdLineSrc[i] == L' ' || pszCmdLineSrc[i] == L'\0' ){-				/* ファイルの存在をチェック */-				szPath[i] = L'\0';	// 終端文字+	const int nCmdLineWorkLen = static_cast<int>( ::wcsnlen( pszCmdLineSrc, INT_MAX ) );++	auto cmdLineWork = std::make_unique<WCHAR[]>( nCmdLineWorkLen + 1 );+	LPWSTR pszCmdLineWork = cmdLineWork.get();+	::wcscpy_s( pszCmdLineWork, nCmdLineWorkLen + 1, pszCmdLineSrc );++	// コマンドラインの解析を開始する位置(先頭部分をスキップする場合がある)+	int nPos = 0;++	// コマンドラインの先頭が '-' で始まっていない場合+	if( pszCmdLineWork[0] != L'-' ){+		// 先頭部分を空白を含むパスとして切り出せる場合は切り出す。+		WCHAR szPath[_MAX_PATH]{ 0 };+		for( size_t i = 0; i < _countof( szPath ); ++i ){+			const WCHAR& chSrc = pszCmdLineWork[i];

ここは参照じゃなくてコピーで良いです。その方が軽いです。

berryzplus

comment created time in 13 days

PullRequestReviewEvent

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

マシンの能力も関係すると思います。ところで一般的にモニタのリフレッシュレートは 60Hzですが、240Hzのゲーミングモニターを使えば(マシンパワーが十分にあれば)中間のコマが更に表示される可能性は増えますね。無駄な中間のコマを表示すると計算量も増えてしまうので、リスト系のコントロールに大量にアイテムを登録する場合には WM_SETREDRAW を使って再描画を抑える事が推奨されています。

beru

comment created time in 13 days

push eventberu/tflite_test

Katsuhisa Yuasa

commit sha 60500b2ec9cab7697633996800bfc9c7c656bc68

add files

view details

push time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha 3145aa42ad87ea0171570b42f8167f68ecd193e7

0.25 to 0.1

view details

push time in 13 days

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

上記のコメントに ScreenToGif でキャプチャして保存したアニメーションGIFファイルを貼り付けました。 等速再生なので違いがわかりにくいかもしれません。

下記のページでは同じ動画を 1/4 の速度で再生しています。 https://beru.github.io/flickering/test.html

beru

comment created time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha 9a463870add786a92e74292fb12f7a2647b3d8c3

Revert "add map" This reverts commit 95871b5422d62aa5b82236694572de2c3bdf4a92. Revert "update" This reverts commit 9f51be68eea040887a44a2bcc29e0b4e47846fe5.

view details

push time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha 95871b5422d62aa5b82236694572de2c3bdf4a92

add map

view details

push time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha 9f51be68eea040887a44a2bcc29e0b4e47846fe5

update

view details

push time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha 1bbfd43b46d07e5c1b4204ab25efa97b707a6681

change speed

view details

push time in 13 days

push eventberu/beru.github.io

Katsuhisa Yuasa

commit sha d36dcc2115ffd73e45104446ebb5aaedc0d4b4f3

flickering

view details

push time in 13 days

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

変更前

455a7fff55759ba3058a210fa9ca62d1f8eb8baa_IDD_PROP_KEYWORD

変更後

079929f9b9ad367e29b69b029d70b82561c3c9fb_IDD_PROP_KEYWORD

beru

comment created time in 13 days

push eventberu/tflite_test

Katsuhisa Yuasa

commit sha 804a6e821cda30e87e931d6ff483c008bffe2407

classification の確認

view details

push time in 14 days

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

超スロー再生にしたときに問題のある瞬間のコマがどう見えるか、 つまり、「ちらつく」がどういう不具合なのかを説明してもらえればいいっす。

百聞は一見にしかず、ということわざがあるぐらいなので言葉で説明してもきちんと伝わるか自信が無いですが書いてみます。

本来は表示する必要のない途中の絵が見えてしまうのがちらつきの原因です。例えばユーザーが操作をする前にリストボックスにアイテムがたくさん表示されているとして、操作後に下記の処理が行われるとします。

  • LB_RESETCONTENT : リストボックスのアイテムを全消去
  • for ループ
    • LB_ADDSTRING : リストボックスにアイテムを追加
  • LB_SETCURSEL : リストボックスの選択アイテムを設定し、選択アイテムが表示される位置にスクロールを調整
  • LB_SETTOPINDEX : リストボックスの指定アイテムが表示されるようにスクロール位置を調整

上記の処理の途中、例えばリストボックスのアイテムを全消去した後の内容が表示されると、そのコマの絵ではリストボックスのアイテムは空表示になります。上記の処理がすべて完了後にも描画が行われますが、そのコマではリストボックスにアイテムが入った状態の絵になります。

  1. 操作前:リストボックスにアイテムがたくさん表示されている
  2. アイテム消去後:リストボックスのアイテムを全消去された空表示
  3. 処理完了後 : 再度リストボックスにアイテムがたくさん表示されている

途中の 2 の絵は本来は表示する必要は無いもので、表示されるととても短い時間の間に 1 -> 2 -> 3 の3コマが表示されるのでその分画面の表示の切り替わりが頻繁になり、表示がちらついたような印象を受けます。

実際には3コマだけとも限らず、中間の状態のコマがもっとたくさん間に挟まって表示されてしまう事もあります。よく行われる対策としては、LB_ADDSTRING するループの前後で WM_SETREDRAW を送って再描画がその間にされます。このPRでやっている事も基本的には同じです。

beru

comment created time in 14 days

push eventberu/tflite_test

beru

commit sha b9628986b5c08f20173562766109515a82ee494d

メモ更新

view details

push time in 16 days

create barnchberu/tflite_test

branch : master

created branch time in 16 days

created repositoryberu/tflite_test

created time in 16 days

pull request commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

変更前の「ちらつく」について定量的な表現で事象を解説してもらえれば、改修確認のデータ取ってもよいです。目視チェックする能力はないので、目視がいい場合は他の人に頼んでください。

いつかHFR(ハイフレームレート) 撮影が出来るカメラを購入して撮影した動画を YouTube において確認出来るようにしようかと思います。

beru

comment created time in 16 days

Pull request review commentsakura-editor/sakura

サクラエディタのコマンドライン引数に超長い文字列を指定するとクラッシュする問題に対処する。

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) { 	MY_RUNNINGTIMER( cRunningTimer, "CCommandLine::Parse" ); -	WCHAR	szPath[_MAX_PATH];-	bool	bFind = false;				// ファイル名発見フラグ-	bool	bParseOptDisabled = false;	// 2007.09.09 genta オプション解析を行わなず,ファイル名として扱う-	int		nPos;-	int		i = 0;-	if( pszCmdLineSrc[0] != L'-' ){-		for( i = 0; i < _countof( szPath ); ++i ){-			if( pszCmdLineSrc[i] == L' ' || pszCmdLineSrc[i] == L'\0' ){-				/* ファイルの存在をチェック */-				szPath[i] = L'\0';	// 終端文字+	const int nCmdLineWorkLen = static_cast<int>( ::wcsnlen( pszCmdLineSrc, INT_MAX ) );++	auto cmdLineWork = std::make_unique<WCHAR[]>( nCmdLineWorkLen + 1 );+	LPWSTR pszCmdLineWork = cmdLineWork.get();+	::wcscpy_s( pszCmdLineWork, nCmdLineWorkLen + 1, pszCmdLineSrc );++	// コマンドラインの解析を開始する位置(先頭部分をスキップする場合がある)+	int nPos = 0;++	// コマンドラインの先頭が '-' で始まっていない場合+	if( pszCmdLineWork[0] != L'-' ){+		// 先頭部分を空白を含むパスとして切り出せる場合は切り出す。+		WCHAR szPath[_MAX_PATH]{ 0 };+		for( size_t i = 0; i < _countof( szPath ); ++i ){+			if( pszCmdLineWork[i] == L' ' || pszCmdLineWork[i] == L'\0' ){

Releaseビルドの最適化結果は未確認ですが、今どきのメジャーなコンパイラならこのくらいの最適化はしてくれるかもしれないですね。

人によって判断が分かれるって喩えですかね。

これについては実は何も考えていなくて、 http://www.tokudenkairo.co.jp/keireki.html を読んで消滅処理は厳しいのかぁ…という事で適当に文をこさえた次第です。

人によって判断が分かれるというのはその通りですね。

コメントつける位置がよくなかったですがループ中で3回以上使われているようです。たった今判断基準が4回以上に変わったという事であればしょうがにゃいです。

berryzplus

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

サクラエディタのコマンドライン引数に超長い文字列を指定するとクラッシュする問題に対処する。

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) { 	MY_RUNNINGTIMER( cRunningTimer, "CCommandLine::Parse" ); -	WCHAR	szPath[_MAX_PATH];-	bool	bFind = false;				// ファイル名発見フラグ-	bool	bParseOptDisabled = false;	// 2007.09.09 genta オプション解析を行わなず,ファイル名として扱う-	int		nPos;-	int		i = 0;-	if( pszCmdLineSrc[0] != L'-' ){-		for( i = 0; i < _countof( szPath ); ++i ){-			if( pszCmdLineSrc[i] == L' ' || pszCmdLineSrc[i] == L'\0' ){-				/* ファイルの存在をチェック */-				szPath[i] = L'\0';	// 終端文字+	const int nCmdLineWorkLen = static_cast<int>( ::wcsnlen( pszCmdLineSrc, INT_MAX ) );++	auto cmdLineWork = std::make_unique<WCHAR[]>( nCmdLineWorkLen + 1 );+	LPWSTR pszCmdLineWork = cmdLineWork.get();+	::wcscpy_s( pszCmdLineWork, nCmdLineWorkLen + 1, pszCmdLineSrc );++	// コマンドラインの解析を開始する位置(先頭部分をスキップする場合がある)+	int nPos = 0;++	// コマンドラインの先頭が '-' で始まっていない場合+	if( pszCmdLineWork[0] != L'-' ){+		// 先頭部分を空白を含むパスとして切り出せる場合は切り出す。+		WCHAR szPath[_MAX_PATH]{ 0 };+		for( size_t i = 0; i < _countof( szPath ); ++i ){+			if( pszCmdLineWork[i] == L' ' || pszCmdLineWork[i] == L'\0' ){

pszCmdLineWork[i] ですが何回も見てるのでいったん wchar_t 型のローカル変数にコピーした方が効率が良いかなと思いました。

何それおいしいの?と思うかもしれませんが、ローカル変数の活用には核変換の研究に国民の血税を費やすのと同じくらいの意義が有ります。

berryzplus

comment created time in 18 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 			int len = wcslen(szPath); 			for (int i = 0; i < len ; ) { 				if ( !TCODE::IsValidFilenameChar(szPath[i]) ){-					WCHAR msg_str[_MAX_PATH + 1];-					swprintf(-						msg_str, _countof(msg_str),-						LS(STR_CMDLINE_PARSECMD1),-						szPath-					);-					MessageBox( NULL, msg_str, L"FileNameError", MB_OK);+					if (false == bError) {+						LongFilePathErrorMessage(szPath, STR_CMDLINE_PARSECMD1);+						bError = true;+					}

https://github.com/sakura-editor/sakura/pull/1423/files#r499568007 と同様のコメントですがこちらも

					if (!bError && (bError = true))
						LongFilePathErrorMessage(szPath, STR_CMDLINE_PARSECMD1);

のように書く事ですっきりすると思います。

usagisita

comment created time in 18 days

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 				//	ファイル名の後ろにあるOptionを解析するため,ループは継続 				int len = lstrlen( pszToken + 1 ); 				if( len > 0 ){+					CNativeW cmWork; 					cmWork.SetString( &pszToken[1], len - ( pszToken[len] == L'"' ? 1 : 0 )); 					cmWork.Replace( L"\"\"", L"\"" );-					wcscpy_s( szPath, _countof(szPath), cmWork.GetStringPtr() );	/* ファイル名 */-				}-				else {-					szPath[0] = L'\0';+					if (cmWork.GetStringLength() < _countof(szPath)) {+						wcscpy_s(szPath, _countof(szPath), cmWork.GetStringPtr());+					}+					else if(false == bError){+						LongFilePathErrorMessage(cmWork.GetStringPtr(), STR_ERR_FILEPATH_TOO_LONG);+						bError = true;+					} 				} 			} 			else{-				wcscpy_s( szPath, _countof(szPath), pszToken );		/* ファイル名 */+				if (wcslen(pszToken) < _countof(szPath)) {+					wcscpy_s( szPath, _countof(szPath), pszToken );		/* ファイル名 */+				}+				else if(false == bError){+					LongFilePathErrorMessage(pszToken, STR_ERR_FILEPATH_TOO_LONG);+					bError = true;+				}

https://github.com/sakura-editor/sakura/pull/1423/files#r499568007 と同様のコメントですがこちらも

				else if(!bError && (bError = true))
					LongFilePathErrorMessage(pszToken, STR_ERR_FILEPATH_TOO_LONG);

のように書く事で行数を減らせると思いました。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 				//	ファイル名の後ろにあるOptionを解析するため,ループは継続 				int len = lstrlen( pszToken + 1 ); 				if( len > 0 ){+					CNativeW cmWork; 					cmWork.SetString( &pszToken[1], len - ( pszToken[len] == L'"' ? 1 : 0 )); 					cmWork.Replace( L"\"\"", L"\"" );-					wcscpy_s( szPath, _countof(szPath), cmWork.GetStringPtr() );	/* ファイル名 */-				}-				else {-					szPath[0] = L'\0';+					if (cmWork.GetStringLength() < _countof(szPath)) {+						wcscpy_s(szPath, _countof(szPath), cmWork.GetStringPtr());+					}+					else if(false == bError){+						LongFilePathErrorMessage(cmWork.GetStringPtr(), STR_ERR_FILEPATH_TOO_LONG);+						bError = true;+					}

思い付きですが下記のように書く事で行数を減らせて可読性も下げられるので一石二鳥だと思いました。

				else if(!bError && (bError = true))
					LongFilePathErrorMessage(pszToken, STR_ERR_FILEPATH_TOO_LONG);
usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 			int len = wcslen(szPath); 			for (int i = 0; i < len ; ) { 				if ( !TCODE::IsValidFilenameChar(szPath[i]) ){-					WCHAR msg_str[_MAX_PATH + 1];-					swprintf(-						msg_str, _countof(msg_str),-						LS(STR_CMDLINE_PARSECMD1),-						szPath-					);-					MessageBox( NULL, msg_str, L"FileNameError", MB_OK);+					if (false == bError) {+						LongFilePathErrorMessage(szPath, STR_CMDLINE_PARSECMD1);

ここでも使っているので、関数名を LongFilePathErrorMessage としていますが Long という修飾は要らないのではないかと思いました。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 		while(input){ 			responseData += input.ReadLineW(); 		}-		ParseCommandLine( responseData.c_str(), false );+		return ParseCommandLine( responseData.c_str(), false, bError );

ここであえて return を付けた事で見積もりが増えて良いと思います。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 				//	ファイル名の後ろにあるOptionを解析するため,ループは継続 				int len = lstrlen( pszToken + 1 ); 				if( len > 0 ){+					CNativeW cmWork;

szPath に収まるサイズなら cmWork を経由せずに szPath にコピーした方がヒープを使う cmWork 変数を使用せずに済むので効率が良くなると思います。記述がちょっと大変そうですが…。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse ) 		if( ( bParseOptDisabled || 			! (pszToken[0] == '-' || pszToken[0] == '"' && pszToken[1] == '-' ) )){ +			WCHAR	szPath[_MAX_PATH] = {0};

変数のスコープを狭める事は良い事だとは思うんですが、配列のゼロ初期化の頻度が高まりそうだなと思いました。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 void CCommandLine::ParseKanjiCodeFromFileName(LPWSTR pszExeFileName, int cchExeF 	@note 	これが呼び出された時点では共有メモリの初期化が完了していないため, 	共有メモリにアクセスしてはならない.++	bError エラー表示済みか。エラーは1回目のみ表示。(レスポンスファイル用) */-void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse )+void CCommandLine::ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse, bool bError )

この関数って再帰関数なんですね。しかし300行以上あるのは長いですね。。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

コマンドラインでMAX_PATHを超えるファイル名を指定すると落ちる

 class CCommandLine : public TSingleton<CCommandLine> { 	LPCWSTR GetDocType() const noexcept { return m_fi.m_szDocType; } 	ECodeType GetDocCode() const noexcept { return m_fi.m_nCharCode; } 	void ParseKanjiCodeFromFileName( LPWSTR pszExeFileName, int cchExeFileName );-	void ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse = true );+	void ParseCommandLine( LPCWSTR pszCmdLineSrc, bool bResponse = true, bool bError = false );

bError だと引数がエラーに関する事だとしか読み取れないので bErrorFound とかいう名前にすると良いと思います。

usagisita

comment created time in 18 days

PullRequestReviewEvent

Pull request review commentsakura-editor/sakura

プロパティシートのコントロール表示のちらつき防止

 BEGIN     LTEXT           "閉じるボタン(&X)", IDC_TextTabClose, 124, 116, 48, 8     COMBOBOX        IDC_CHECK_DispTabClose, 173, 113, 46, 80, CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP     PUSHBUTTON      "フォント(&F)...", IDC_BUTTON_TABFONT, 232, 113, 51, 14-    RTEXT           "Font", IDC_STATIC_TABFONT, 102, 127, 180, 17, SS_RIGHT+    RTEXT           "Font", IDC_STATIC_TABFONT, 102, 127, 180, 12, SS_RIGHT

https://docs.microsoft.com/en-us/windows/win32/winmsg/extended-window-styles

WS_EX_COMPOSITED の解説ですが

Paints all descendants of a window in bottom-to-top painting order using double-buffering. Bottom-to-top painting order allows a descendent window to have translucency (alpha) and transparency (color-key) effects, but only if the descendent window also has the WS_EX_TRANSPARENT bit set. Double-buffering allows the window and its descendents to be painted without flicker. This cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC. Windows 2000: This style is not supported.

と書かれています。bottom-to-top painting order というのが画面のXYのYの上下の事なのかZ-orderの上下の事なのかわかっていませんが、この事が関わっていそうです。

beru

comment created time in 19 days

PullRequestReviewEvent
more