09/12/05

・ Delphi の Tips
　こっそり(?)増えてます。

• 80. Delphi 起動時に渡せるスイッチは？
• 81. 日本語用に使えるコードページは？
• 82. 状況依存ヘルプ (F1 ヘルプ) をアプリケーションに組み込むには？ (2005 以降)
• 83. 紙のマニュアルが欲しい (2007 以降)
• 84. InterBase / Firebird のデータベースへ接続されているセッションが存在するかを調べるには？
• 85. Indy 10 を使ってメール(ISO-2022-JP)を送受信するには？ (2009 以降)
• 86. 手抜きな IP アドレスコントロール
• 87. MaxLength をどうにかする (Delphi 7 ～ Delphi 2007)

・ Google 日本語入力 beta
　面白い。再変換機能が実装されていない等の細かい事は抜きにしても、MS-IME (特に Office IME 2007) よりは使える場面が多いような気がする。

　個人的な好みはある程度 [ツール | プロパティ] で設定できる。例えば以下の様な設定が可能。

• サジェスト(予測変換候補表示)の最大数を増やす。
• 漢字変換モード中に数字を入力した場合の未確定文字のデフォルトを半角(この表現が正しいかどうかは別として)にする。

　...ただ、サジェストは正しい用語や用法を知っているヒトにはいいかもしれないが、ネットスラングも往々にして含まれるため、ビジネス用途でサジェストを多用するべきではないと思う。

・ 第15回 エンバカデロ・デベロッパーキャンプ
　【G2】セッションのビデオ を観た。うーん。うーん！？ 一言で片付けるとするなら、"Web 言語としての Delphi が欲しい" って事なのかな？

09/12/07

・ DocWiki
　雑談をお休みしていた間に、結構な数のドキュメントがインポートされました。

　...ただ、インポートされたのは "殆どが" 英語版にあって日本語版になかったトピックであり、"やっとこさ英語版ファーストリリースの内容に追いついた" という感じです (CGRC.EXE 等は未だに欠損中)。大量インポートされたのが "Help Update の後" というのはタイミング的によろしくなかったと思います。

　QC#78315 は流石に直りましたが (初心者向けチュートリアルのソースコードが読めない状態でした。詳しくはお手持ちのヘルプファイルで確認下さい)、QC#78374は、QC 入れて2ヶ月経った今も修正されていません。1文字分のミスを直すのがそんなに難しいのかな？そもそも DocWiki 化したのは "何か不具合があった時に早急に修正する事が可能" ってのが建前じゃなかったんだっけか？

　ともあれ、DocWiki を参照する場合には、"英語版 を先に検索し、その後、同等の 日本語版 があるかを確認した方がいい" という状況はしばらく続くようです。

09/12/08

・ Delphi / C++Builder / RAD Studio 2010へバージョンアップする絶好のチャンス！
　...いや、別に宣伝ではないのですが、Delphi 1～2005、C++Builder 1～6ユーザ はこのバージョンアップを逃すと、次回から定価で製品を購入するハメになります。有効期限は 2009年12月31日 と、今月末までになっていますのでお早めに。

• Delphi 7
• Delphi 2007
• Delphi 2010

・ Delphi 7
　Win9x 上にインストールできる最後の Delphi。Delphi 2 ～ Delphi 6 迄のソースコードをほぼ改変なしでコンパイルできる。

• Kylix 3 が製品に付属
• QuickReport (無償版) が利用可能
• RaveReport が利用可能
• Indy 10 をインストールする事が可能
• XP 対応
• Win9x でも使えるリモートデバッガが Pro 版にも付いている

・ Delphi 2007
　最後の ANSI 対応版 Delphi。Delphi 7 用のソースコードをほぼ改変なしでコンパイル可能。

• QuickReport (無償版) が利用可能
• Vista 対応

・ Delphi 2010
　最新の Unicode 対応版 Delphi。

• Windows 7 対応

・ 細かいこと
　Delphi 7 は過去に作ったアプリケーションのメンテ用に。VistaAltFix を使わないと、Vista 以降の Windows で動作させた場合に、問題が発生する事があります。

　Delphi 2007 は、過去に作ったアプリケーションのマイグレーション用、または連携するアプリケーションが ANSI にしか対応していない場合に。Delphi 2007 以前で作成したアプリケーションでは、"隠されたアプリケーションウィンドウ" の影響で、Vista の最小化されたアプリケーションのタスクバーでの挙動が違ったり、Windows 7 の "エアロシェイク" が動作しなかったりします。

　Delphi 2010 は、Unicode アプリケーション作成用です。Windows 9x で動作するアプリケーションは基本的に作れません。Windows 2000 にインストールする事も基本的にできません (Delphi 2009 なら Windows 2000 にインストールできます)。

　このように、Delphi 7 / 2007 / 2010 の 3 つがあれば、古い Windows から最新の Windows までまんべんなくカバーできます。Win9x を考慮しなくていいのなら、過去のアプリケーションのメンテ用として Delphi 2007 があればいいですね。今ならまだ Delphi 2007 は入手可能ですし、Delphi 2010 以降のアップデート版購入も可能になりますので、Delphi 2007 を 今のうちに押さえておくのも選択肢の一つかもしれません。

09/12/12

・ 新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 (ITPro)
　ほほう。新しい常用漢字が S-JIS では対応できないってか。つーか、ツッコミ所はそこじゃなく、"新しい常用漢字の一部はサロゲートペア領域に存在する" ってトコじゃなかろうか？適当に WideString で "1文字=1Word (16bit)" で処理してると "アイタタタ" てな事になるって事か。ま、たった1文字だけが BMP 領域外にあるってのもおかしな話ではあるけれど、実用上はそんなに問題になる事はないと思う。

　言葉足らずだったので追記。"実用上はそんなに問題になる事はない" の意味だけれど、S-JIS のシステムをたった数文字のために Unicode ベースに変更するのは多くの場合ナンセンスだし、 Unicode 対応といいながら実際には UCS-2 (BMP) にしか対応していないシステムだったとしても、たった数文字のためにシステムを改修するなんて事はまずやらないだろう、と。 BMP 以外のすべての Unicode 文字を扱えるシステムは緩やかにしか増えていかないだろうから、"実用上はそんなに問題になる事はない" と思っている。だって、"常用漢字かそうでないかを意識して漢字を使う" のって、ごくごく限られたケースじゃないの？

　...いかんな。何を書いても誤解されそうな気がする。"Unicode で BMP 範囲外の文字(UTF-8 での 4バイト文字、UTF-16 でのサロゲートペア) に対応しなくてもいい" と言っているのではなく、むしろ逆なのだけれども、 "UTF-8 使ってるから UTF-16 のサロゲートペアなんて関係ない" とか言っちゃうヒトがいる限り "BMP 以外のすべての Unicode 文字を扱えるシステムは緩やかにしか増えていかない" と予測している、って事。

・ Delphi の Tips

• 88. とりあえず、デベロッパーキャンプの資料を読んでみようか。

・ MECSUtils ver1.38
　"JIS2004 問題 (新常用漢字問題)" に絡んで MecsMappingFix_JISX0213ToJISX0208() を追加。また、

• MecsMappingFix_UnicodeToCP932()
• MecsMappingFix_UnicodeToJISX0208()

09/12/16

・ 原チャリ
　ギア付(カブとかじゃなくて)の原チャリにメチャ久しぶりに乗ったが、全然体が覚えていない。ギアチェンジのタイミングは耳で覚えてるけど、原付スクーターの癖が染み付いてしまっていて、どうしても手でブレーキをかけてしまう。 ちゃんと練習しないと、そのうち前方一回転するハメになるな...コリャ。

・ freeml
　前身が Delphi-ML だって事で惰性で参加しているけど、"書き込みしにくい"。メーラーで読む分にはいいけれど、Web だと

• 引用がデフォルトで非表示。表示するのをデフォルトにする方法が不明。
• "メールの詳細（メール表示）" にしても、\記号の表示がおかしい。
  (2個になったり表示されなかったり)
• "シングルクォーテーション" が "シングルクォーテーション×2" になる。
• "文字エンコード" が "EUC-JP" なので、Unicode 文字を記述できない。

　freeml はユーザ登録が必要だけれども、ディスカッションフォーラム なら、そもそも製品登録している時点でアカウントは存在するし、ハンドル/匿名が使いたければ、Dephi Q&A 掲示板 があるし (ディスカッションフォーラム で匿名が実現できない訳ではない)。

　freeml の仕様は (技術系の ML に使うには) 中途半端に感じる。質問する側はどのコミュニティでも構わないかもしれないけれど、ソースコードを例示して回答する側からすれば、ディスカッションフォーラム が圧倒的に便利だ。インデントされたソースコードをそのままコピペできるので、質問者にも有益だと思うのだがなぁ...。

・ ディスカッションフォーラム で、ソースコードを強調構文表示するには？
　普通にソースコードを貼りつけると、半角SPは纏められてしまっちゃうので、

{code: delphi}
procedure TForm1.Edit_Change(Sender: TObject);
var
  MaxLen: Integer;
begin
  MaxLen := SendMessage((Sender as TCustomEdit).Handle, EM_GETLIMITTEXT, 0, 0);
  if MaxLen <= 0 then
    Exit;
  with (Sender as TCustomEdit) do
    begin
      if Length(Text) <= MaxLen then
        Exit;
      if ByteType(Text, MaxLen) = mbLeadByte then
        Dec(MaxLen);
      Text := Copy(Text, 1, MaxLen);
      SelLength := 0;
      SelStart  := MaxLen;
    end;
end;
{code}

　このように "{code: 言語}～{code}" で括るといい。"言語" の所は正直なんでもいい。面倒なら "{code}～{code}" でもいいのだけれど、閉じタグが "{/code}" でないので判りにくいという事もあってメモ代わりに "言語" が記述される事が多いみたいだ (言語別の強調構文表示が未実装なだけかもしれないけれど...)。

・ Baidu Type -文字入力システム- Beta版
　なんかデジャヴだな。しかし、XP でしか動作しないってのは致命的かも。

09/12/21

・ いやいや、そうじゃないだろう？
　ここで語られているドキュメントの話。

　QC#78374...2ヶ月放置されていた QC ですが、これが修正された日付は 12/07 なのですよ。解ります？12/07 なんですよ。

　それから...例えば、Delphi 2009 で採用されたリソースコンパイラ CGRC.EXE の日本語版解説はありません。Delphi 2009 の時のものですよ、これ。加えて言えば、

　Delphi 2009 の readme.htm にこう書かれていますね、"ERC.EXE は誤った名前" だと。それがどうして Delphi 2010 の readme.htm にも引き継がれているのでしょうかね？一年経っても修正できなかったと？DocWiki でも未だに 英語版以外は直っていない というのはどういう事なんだ、と？

　"Delphi 2009 の ドキュメントの品質を改善しないまま DocWiki に移行したので、DocWiki 移行自体に手間が掛かってしまい品質が Delphi 2009 同等かそれ以下になった" ってのがホントの所じゃないですか。 "何か不具合があった時に早急に修正する事が可能という DocWiki 化の建前" すら崩れてしまってるのなら、"僕から罵倒されても文句は言えない" 事は当然理解してらっしゃいますよねぇ？

　"こちらで最新のドキュメント..." と紹介のある docs.embarcadero.com にある Delphi 2010 の CHM ファイルは日本語版のみ RTL/VCL が存在せず、存在するものも TOC から文字化けしていてマトモに使えたもんじゃないです...2007 のも 2009 のも (自前で CHM ヘルプを作る方法はこちら)。ちなみに、私はマトモに使える Delphi 2007 / 2009 の CHM ヘルプを持っていますが、2010 のはありません。元になる HTML-Help2 のヘルプがひどいので作る気になれないからです。

　"いいライター" 以前に、欠損してるコンテンツの補充が必要だと思います。欠損するくらいなら、未翻訳の英語版コンテンツが含まれていた方が遥かにマシだと思います。ただでさえ、中身のないコンテンツ(説明になってないコンテンツ)が未だに相当量存在するのですから。

09/12/22

・ C# でクロス開発
　RZ-H220 の開発のために久々に C# をいじる。すっかり忘れてやんの。

　しかし、C#...つーか、VS は IDE が重くてイライラするなぁ。"Delphi / C++ Builder の IDE が重い" とか言っちゃうヒトは VisualStudio 触った事があるのだろうかと思ってしまう。クロス開発はエミュレータでデバッグできる範囲であればいいけど、実機でしかテストできない場合には面倒な事この上ない。

・ "Project X"
　"コンパイラをフロントエンドとバックエンドに分ける" といっていたアレ。言語層をフロントエンドで処理し、プラットフォームをバックエンドで処理するって事だと認識しているのだけれど、僕の考えが間違っていなければ、中間言語へのトランスレートが必要な気が (内部的にであっても)。ただ、この方法だと "言語" の追加や "バイナリが動作するプラットフォーム" の追加は容易になるわね。

　...そうなると Prism の統合が頭をよぎるけど、"PreRequires な .NET コンポーネントが BDS 2006 並になる" ＆ "またもや .NET の縛りを受ける" 事になるけど。流石にそれはやらない...よね？

・ "Project Chromium"
　品質向上プロジェクト。多分、軽量な O/R マッパとかの小物も幾つか追加される。予定されていたソースコードフォーマッタは Delphi 2010 に搭載されちゃったし。

・ "Project Commodore"
　64bit コンパイラ。

・ 勝手な予想
　"フロントエンド/バックエンド式の新しいコンパイラ (Project X の一部)" + "Project X (クロスコンパイラ・バックエンド/ライブラリ)" または "Project Chromium" または "Project Commodore" が "次期 Delphi / C++ Builder" になるのでは？

　一番手っ取り早いのは "フロントエンド/バックエンド式の新しいコンパイラ" + "Project Chromium"。これなら Delphi 2010 の延長線上で開発できる...ユーザが食いつくかどうかは別として (「サービスパックとして提供しろ」と主張するヒトも居そうだし)。

　以前のような "タイムラインに乗ったロードマップ" が出てこないので、どの方向で進めるのかを決めあぐねている印象がある。進捗率が高いのは多分 "Project X"。"Project Chromium" はいきなり出てきた感があるので、"Project X" の "Win32 以外のクロスコンパイラ(バックエンド)" が 間に合わなかった時のための保険 に見える。

　64bit コンパイラを先に作ったって、再度 "フロントエンド/バックエンド式" に作り替えなければならないのならリソースの無駄になるって事だから、最低でも "Project X" の "フロントエンド/バックエンド式コンパイラ" は最優先で開発されるハズだとみている。いい意味で予想が裏切られるといいなぁ。