文字コードの指定ダイアログでCPのチェックが効かない事が有る

[beru]

問題内容

文字コードの指定ダイアログでCPのチェックが効かない事が有る

再現手順

1. 文字コードの指定ダイアログを表示する（文字コードセットの選択は UTF-8）
2. CPのチェックボックスをチェックするとコントロールが無効表示になる
3. 文字コードセットの指定コンボボックスのドロップダウンを表示すると選択肢が増えている（選択は変更しない事）
4. OK か キャンセル のどちらかを選択してダイアログを閉じる
5. 再度文字コードの指定ダイアログを表示する
6. CPのチェックボックスがチェックされていないのでチェックするとコントロールが無効表示にならない
7. 文字コードセットの指定コンボボックスのドロップダウンを表示しても選択肢が増えていない

再現頻度

必ず

問題のカテゴリ

• プログラムの動作上の問題
• ローカルビルド

環境情報

サクラエディタ   v2.4.0.0 64bit dev Alpha Version
(GitHash 91aaed7a6454aa4ff04803a086bb119fbf85a620)
(GitURL [email protected]:sakura-editor/sakura.git)

      Compile Info: V_A641916 WPR WIN601/I800/C000/N601
      Last Modified: 2019/9/14 00:41:15

[berryzplus]

イベントハンドラの途中で Windows API を呼んで、
画面状態を変えてるのが敗因なんじゃないかと思っています。

本来のサクラエディタのダイアログプロシージャの構造は、
基本的にはMFCを模倣した ダイアログデータエクスチェンジ っぽい実装です。
（CDialog::GetData()の使われ方を見たら構造がわかるはず。）

DDXの利点は、データと画面表示の整合性を集中管理できることだと思います。

イベント処理の前に「画面⇒データ」して、
終わったら「データ⇒画面」することで、
データの整合性は保たれます。

「画面⇒データ」が失敗したときに処理を止めるようにすれば、
変なデータ入力に悩まされることもありません。

コード選択ダイアログの他にも、タイプ別設定一覧とプロファイルマネージャが似た感じの構造になっていて、たぶん「問題アリ」です。

DDX風に組むことのデメリットは、 Windows API を使ってコントロールのデータを微調整するような、ゴリゴリ系のプログラムをする必要がなくなることだと思います。実装の傾向を見た感じ、過去の開発者は「あえてゴリゴリ書くのが好き」な人が多かった感じなのでしかたないんかな、と思っています。

[berryzplus]

ちなみに、直し方は超簡単なのでコメントで共有しときます。

sakura/sakura_core/dlg/CDlgSetCharSet.cpp

Lines 40 to 47 in 4014723

	/* モーダルダイアログの表示 */
	int CDlgSetCharSet::DoModal( HINSTANCE hInstance, HWND hwndParent, ECodeType* pnCharSet, bool* pbBom)
	{
	m_pnCharSet = pnCharSet; // 文字コードセット
	m_pbBom = pbBom; // BOM
	return (int)CDialog::DoModal( hInstance, hwndParent, IDD_SETCHARSET, (LPARAM)NULL );
	}

ここに m_bCP をリセットするコードを追加してやれば良いです。

	m_pbBom = pbBom;			// BOM
	m_bCP = false;

	return (int)CDialog::DoModal( hInstance, hwndParent, IDD_SETCHARSET, (LPARAM)NULL );