◀Unicode版開発トップへ
  • 540 Commit報告:(Fix) ANSIコンパイル版不具合修正
    • 542 Re:Commit報告:(Fix) ANSIコンパイル版不具合修正
    • 585 Re:Commit報告:(Fix) ANSIコンパイル版不具合修正
  • [540] Commit報告:(Fix) ANSIコンパイル版不具合修正 Uchi 2008年06月29日 18:38

    リビジョン:
    rev1405

    変更種別:
    バグ修正

    内容:
    ANSIでコンパイルした時の不具合修正しました。
    不具合は以下の通り
    『開く』『名前を付けて保存』ダイアログの『ファイルの種別』が正常でない。
    同じく、『タイプ別設定』/『共通設定』の『インポート』『エクスポート』ダイアログの『ファイルの種別』
    同じく、『タイプ別設定』/『共通設定』の『支援』のファイルを開くダイアログの『ファイルの種別』
    『タイプ別設定』『スクリーン』ドロップダウンが文字化けしている。
    iniファイルにキーネームが正しく書き込まれない。(次回起動時、メニューのシートカット表示などが乱れる)
    『共通設定』『キーワード追加』/『セット追加』テキストボックスの初期値に変な文字列が表示される。
    『ファイル内容比較』ファイル名が出ない。
    キーボードマクロが正しく出力されない。
    『外部コマンド』の『アウトプット』取り込み時のコメントが不正。
    • [542] Re:Commit報告:(Fix) ANSIコンパイル版不具合修正 kobake 2008年06月30日 04:28

      TCHAR対応いただくのは構わないのですが、もしかしたら将来無駄になってしまうかもしれません。。

      一応TCHAR方式でANSIコンパイルをサポートしていますが、
      正直、個人的にはこの方式に希望は持っていません。
      TCHAR, char, wchar_t 3種の文字列が混在した状態での保守は不経済的です。
      APIをラップするほうがよっぽど有意義な管理となるはずです。

      今だから言いますが、あえてANSIコンパイルをTCHAR方式でサポートしたのは、
      ANSI版支持者の不安を緩衝し、無駄な議論を避けるためだけです。設計的な価値は全く無い、完全に無駄撃ち前提の対応でした。

      ANSI対応方法 (TCHAR方式, APIラップ方式, or others) をどうするかは、本家統合後に議論を提起するつもりです。

      このまま TCHAR方式が採用されれば、今回対応いただいた分も
      無駄にはならないのですが、どう転ぶかは今の時点では判りません。
      そういう理由から、自分は手を付けないでいます。
      先に言っておくべきでしたね。。すみません。
    • [585] Re:Commit報告:(Fix) ANSIコンパイル版不具合修正 kobake 2008年08月26日 23:28

      ソースコードおよび動作に問題ないことを確認しました。