[Delphi:90691] Delphi 2009 体験版を使ってみて
中村拓男
Delphi 2009 は発注済みなのですが、まだ届かないので、「体験版(Trial版)」を
ちょっと(1時間くらい)使ってみました。まだしょうもないレベルの話ですが．．．
1) インストール
体験版をネットワークインストールしましたが、は、速いですね。1時間かかりませんでした。
2) ユニコード対応
ソースが無いので、ヘルプを覗いて見ましたが、Ansi～で始まる文字列処理関数が UnicodeString版と
AnsiString版で overload されているのがちょっとダサい。
＃移行を考えると仕方ないかもしれませんが．．．
Ansi～で始まらない同等にエイリアスの用意されていますが、こちらもUnicodeString版と
AnsiString版の overload が用意されています。これからは Ansi～を付けずに書いてね
ということなんでしょうね。
AnsiStringsユニットには SysUtils や StrUtulsと同名の AnsiString専用の文字列処理関数が詰まっています。
＃uses すると string = AnsiString になったりすると期待しましたが、なりませんでした(^^;
識別子のユニコード対応に興味があったのでちょっと試して見ましたが、
□ published なプロパティの名前 ⇒ OK
□ コンポーネント名 ⇒ OK
□ ユニット名 ⇒ OK
ヘルプでは相変わらず 英数 '_' のみになってますが真っ赤な嘘のようです。
漢字名のプロパティを持つ漢字名のコンポーネントを漢字名のユニットで作り、漢字名のパッケージに
登録したら、パレットにちゃんと漢字名のコンポーネントが表示されました。フォームに貼ったら、
オブジェクトインスペクタに漢字のプロパティ名が表示されたのはちょっとうれしかった。
もちろんちゃんと動きました。
3) ジェネリック
まだほとんど試してませんが、ジェネリックはコレクションライブラリが有ってのものなので
Generics.Collectionsユニットのヘルプを探して見ましたが有りません。
Generics.Collectionsユニット自体はちゃんと存在していてちゃんと使えます。
Doc-O-Matic がまだジェネリック対応していないのかな．．．．．製品版では
ヘルプが追加されていることを望みます。
＃ソースがあれば何とかなりますが．．．
4) ヘルプ
体験版のせいなのかもしれませんが、相変わらずヘルプはひどいですね。
□string = AnsiString になっている記述が残ってます(^^;
□ダイアログのヘルプが結構あちこちで切れています(;_;
□Delphiのコンパイラオプションが何故か C++プロジェクトオプションの下の階層にあります(;_;
□イベントからイベント型へリンクをたどってジャンプできるようになってました(^^
----------
東京都 日野市 中村拓男
Takefumi-o
>漢字名のプロパティを持つ漢字名のコンポーネントを漢字名のユニットで作り、漢字名のパッケージに
>登録したら、パレットにちゃんと漢字名のコンポーネントが表示されました。フォームに貼ったら、
>オブジェクトインスペクタに漢字のプロパティ名が表示されたのはちょっとうれしかった。
>もちろんちゃんと動きました。
これはすごいですね！
プロパティインスペクタが見やすくなるかも！？
別に現状でも何も問題はないのですが、
特殊な業界用語のプロパティは英語にすると
見つけられないこともあります。
いままでは「類別」を「Ruibetu」みたいにローマ字に
していました。
これはちょっとダサいですが見つけられないよりは
マシかなと思っていました。
こういう場合には使う価値がありますね。
ただ、プログラム中では漢字の変数をつかうと
すごい見づらくなりそうですね。
>体験版のせいなのかもしれませんが、相変わらずヘルプはひどいですね。
ヘルプにもう少し時間は割けられないのでしょうか？
=====================================
from: Takefumi-O
mail-address: takef...@gracix.com
url: http://www.gracix.com/
=====================================
中村拓男
Unicode 対応をもう少し調べて見ました。
1. Delphi言語の Unicode 対応
最初は AnsiString が UnicodeString と AnsiString に分かれたのかな？ くらいに
考えていたのですが、どうも AnsiString(長い文字列)の拡張という方向みたいですね。
まず AnsiString のメモリ上の形式が変わっています。
以前は
+-----------------------+-------------------+-------------------+
| 参照カウント(Integer) | バイト数(Integer) | 文字列 |
+-----------------------+-------------------+-------------------+
だったのが
+--------------------+------------------+-----------------------+-----------------+---------+
| コードページ(Word) | 要素サイズ(Word) | 参照カウント(Integer) | 要素数(Integer) | 文字列 |
+--------------------+------------------+-----------------------+-----------------+---------+
に変わってます。UnicodeString, AnsiString, UTF8String, RawByteString 等は全て同じ形式で
違うのはコードページと要素サイズだけです。
UnicodeString: コードページ = 1200, 要素サイズ = 2
UTF8String: コードページ = 65001, 要素サイズ = 1
AnsiString: コードページ = 932, 要素サイズ = 1 # 日本の場合
RawByteString: コードページ, 要素サイズは自由に設定できる。
結局
UnicodeString = type AnsiString(1200)
UTF8String = type AnsiString(65001)
AnsiString = type AnsiString(932) #日本の場合 又は type AnsiString(0)
と考えてよいわけで、長い文字列の総称としての AnsiString と デフォルトのコードページ
の文字列を指す AnsiString を分けて考える必要があります。
全ての種類の長い文字列は AnsiString であり、UnicodeString や AnsiString(AnsiString(0)) は
特定のコードページを持つ派生バージョンなわけです。Codegear の Blog や解説 にもこのあたりの
説明に混乱が見られます。最初はわけが判りませんでした。
＃ UniCodeString = type string(1200) でもよかったような気がするのでが、
＃ なぜ AnsiString という名前にこだわったのかは判りません。
□実験1
var
u8str: UTF8String;
str: UnicodeString;
:
:
Integer(str) := Integer(u8str);
:
:
などといけないことをして、UnicodeString に UTf8String を無理やり代入してもちゃんと
文字列処理ができるみたいです。実際の処理では、メモリ上のコードページを見て処理を行っているようです。
□RawByteString
UnicodeString や UTFString に文字列を代入すると、コードページが異なる場合は変換が起きますが、
RawbyteString は無変換で元のコードページのまま文字列を受け入れます。つまり RawbyteString は
どんなコードページの文字列も保持できる万能の文字列型と言えます。
SetCodePage関数で、RawByteStringの文字列のコードページを自由に変換できます。こいつは頼もしいですね。
□実験2
ヘルプの
「Code Page Identifiers」
ms-help://embarcadero.rs2009/Intl/unicode_81rn.htm
に載っている utf-32(12000) を SetCodePage に渡して RawButeString で utf-32 が使えるか試して見ましたが、
コードページは変化しませんでした。Windows がサポートしていないのだから 当たり前か．．．(^^;
2. IDE のUnicode 対応
1) ソースファイル
ソースコードのデフォルトは ANSI のままですが、ソース中に ShiftJIS に無い文字を使うと、
セーブ時に UTF-8 にするか聞いてきます。いいえを選ぶと文字化けしますが、はいを選ぶと当然正しく
セーブされます。
2) DFM
DFM のコードは ANSI のままで、UTF-8にはならないようです。
＃見落としているかも知れませんが．．．
但し、文字列は以下のように UTF-16のコードが数字で保存されます。
object Edit2: TEdit
Left = 104
Top = 216
Width = 121
Height = 21
TabOrder = 2
Text = #20013#26449 ← ここ '中村'
end
IDE でフォームをエディタで開いても漢字は表示されません。＃だ、ダサい！
Delphi 5 の頃の不評だった方式に戻っちゃってますが、
＃Delphi 5 でもIDEでは漢字が見えたと思いますが．．．
DFM の UTF-8 化を望みます。
中村拓男 さんは書きました:
>2) ユニコード対応
>
>ソースが無いので、ヘルプを覗いて見ましたが、Ansi～で始まる文字列処理関数が UnicodeString版と
>AnsiString版で overload されているのがちょっとダサい。
>＃移行を考えると仕方ないかもしれませんが．．．
>Ansi～で始まらない同等にエイリアスの用意されていますが、こちらもUnicodeString版と
>AnsiString版の overload が用意されています。これからは Ansi～を付けずに書いてね
>ということなんでしょうね。
>
>AnsiStringsユニットには SysUtils や StrUtulsと同名の AnsiString専用の文字列処理関数が詰まっています。
>＃uses すると string = AnsiString になったりすると期待しましたが、なりませんでした(^^;
>
>識別子のユニコード対応に興味があったのでちょっと試して見ましたが、
>
>□ published なプロパティの名前 ⇒ OK
>□ コンポーネント名 ⇒ OK
>□ ユニット名 ⇒ OK
>
>ヘルプでは相変わらず 英数 '_' のみになってますが真っ赤な嘘のようです。
>
>漢字名のプロパティを持つ漢字名のコンポーネントを漢字名のユニットで作り、漢字名のパッケージに
>登録したら、パレットにちゃんと漢字名のコンポーネントが表示されました。フォームに貼ったら、
>オブジェクトインスペクタに漢字のプロパティ名が表示されたのはちょっとうれしかった。
>もちろんちゃんと動きました。
>
----------
東京都 日野市 中村拓男
中村拓男
まだ、実践していませんが、いちいち翻訳するのが面倒なので、
コードの中で日本語の識別子を使いたくなってしまいます(^^;
以前、半分冗談で、試験用ツールを C# で全て日本語で書いたことが
有りましたが、意外とソースが見やすくて好評でした。
受信スレッド.接続する(in_ホスト名、in_ポート);
受信データ長 = 受信スレッド.受信する(this._受信バッファ, this._バッファ長);
if (受信データ長 == 0) ......
こんな感じです(^^;
また、JUnit/NUnitなどのテストケースのメソッド名を、テスト内容を表すながーい日本語で
書くというのは結構流行ってます。ツールでドキュメント化するとそのままテスト仕様書が
出来上がるので手間が省けます。
＃ドキュメント化ツールでメソッド名が化けたりして困りましたけど．．．
＃最近は大丈夫になりました。
Takefumi-o さんは書きました:
----------
東京都 日野市 中村拓男
Takefumi-o
> 以前、半分冗談で、試験用ツールを C# で全て日本語で書いたことが
> 有りましたが、意外とソースが見やすくて好評でした。
>
> 受信スレッド.接続する(in_ホスト名、in_ポート);
> 受信データ長 = 受信スレッド.受信する(this._受信バッファ, this._バッファ長);
> if (受信データ長 == 0) ......
こっ、これは・・・！(@ @
なんか大昔にジャストシステムが出してた日本語プログラム環境を
思い出しますね！（私が小学生の時ですね）
あれの実用版という感じがします。
> □RawByteString
>
> UnicodeString や UTFString に文字列を代入すると、コードページが異なる場合は変換が起きますが、
> RawbyteString は無変換で元のコードページのまま文字列を受け入れます。つまり RawbyteString は
> どんなコードページの文字列も保持できる万能の文字列型と言えます。
>
> SetCodePage関数で、RawByteStringの文字列のコードページを自由に変換できます。こいつは頼もしいですね。
この機能も非常にいいですね。
Webページやメールなどの処理が助かりそうです。
現状はコンバート関数や変換コンポーネントを使いまくって
なんだか非常にややこしいものになっていますので・・・
昨日まで買うつもりはぜんぜんなかったのですが、
なんだか非常に欲しくなってきた(;^^
dreamily
中村さんと DEKO さん(順不同・・・汗)の話には
全くついていけないのですが・・・
Delphi 2009 のインストールも終わり、少し触っているのですが
中村さんが検証されていた DFM の件は少し残念ですね。
正直、今回の Unicode 完全？！対応で
エディタモードでの日本語表示が視覚的に出来ると思っていました。
すでに Unicode 対応済みと言えば、対応済みなんでしょうけど・・・
実際問題として、データモジュールに
TSQLQuery を貼り付けては、 SQL 内で日本語を使い
TPageProducer を貼り付けては、 HTML 内で日本語を使い
ってしている愚か者ですから
いざ、修正したいときに、エディタモードで直接編集できないのが
ほんとツラい毎日です。
ファイル検索で日本語検索しても DFM は検索の対象にならないみたいで
結局は、ソースに直接ゴリゴリ書いていった方があとの保守が楽みたいな
全然、 Delphi ライクらしからぬプログラムを書いている毎日です。
Delphi Form Converter や DEKO さんが 提供してくれている
DFM コンバーターを活用して何とかやり過ごしてはいますが
直接編集できるように変更(退化？)して欲しかったです。
時期バージョンでも予定はないのかな？ (涙)
DEKO さんが提供してくれている DFM コンバーターの開発は終了しているようですが
GExperts の Editor Experts のように、 IDE 上から簡単に相互変換できるように
サポートしていただけると、私の使用環境ではぐっと効率が上がるのですが (願)
ところで、 Delphi 2009 は
一番の盛り上がりを見せないといけないバージョンだと思うのですが
ここの ML 以外に、どこかで盛り上がっていたりするのでしょうか？
Rave Reports も 7.5 から 7.6 に代わりましたけど本家は 8 ですし
日本語化もされていませんから、まだ日本語が化ける現象はあるんでしょうね。
たしか、 Delphi が Unicode 対応していないから
日本語対応もしないとか言っていたような気もしないわけではないのですが・・・
確認をしていないのでもしかすると
日本語が化けずに印刷できるのかも知れませんけど。
取り留めのない話になりましたが
Delphi2009 のスプラッシュ画面を変更したい今日この頃です。
この画面を毎日見るかと思うと志気が低下しそうです。 (涙)
ht_...@nifty.com
> DEKO さんが提供してくれている DFM コンバーターの開発は終了しているようですが
> GExperts の Editor Experts のように、 IDE 上から簡単に相互変換できるように
> サポートしていただけると、私の使用環境ではぐっと効率が上がるのですが (願)
物凄く遅い返信になりましたが、
http://homepage1.nifty.com/ht_deko/junkbox.html#DFMCONVEXP
http://homepage1.nifty.com/ht_deko/ft0903.html#090326
こんな感じのものがご所望でしたでしょうか？
# もう解決していたらゴメンナサイ。
--
by DEKO
-------------------------------------
http://homepage1.nifty.com/ht_deko/
ht_...@nifty.com
-------------------------------------
dreamily
DEKO さん・・・(激涙)
大ちゅき！(はぁ～と)
って、ふざけている？場合ではないのですが、久しぶりの投稿になります。
まだ、送れますよね？
アタフタとしていたので、3/5 以降受信していませんでしたら
返信が遅くなりました。
DEKO さんに作成していただいたとおり、私の嘆願通りでございます。m(_ _)m
このツール自体は、本メールより先に、DEKO さんのホームページの情報から知り
おぉ～、うるるん、ぷるるん？としながら、使わせていただきました。
くれぐれも追加された一行目を消さないようにいたします (＾＾)／
Delphiのメンテナンス契約も今回はバッサリと継続しなかったので
当面は、Delphi2009と仲良し子良しで頑張ってみる予定です。
DEKOさんのいる西南西の方に、足を向けて寝ないようにいたします。
# たしか、九州方面でしたよね？
# もし、東京とかでしたら、足の向きが違いますので個別に教えてください (笑)
本当に、ありがとうございました。
ps.
ところで・・・恐る恐る・・・やっぱり手動モード限定ですよね？(汗々)
エディタモードになる前に、フックしてデコードして・・・
エディタモードを終了するときに、フックしてエンコードして・・・
す、す、すいません、、、(汗々)
と、と、とにかく、DEKO さんのご尽力に一票。。。ということで (汗々)
改めて。。。
大変便利に活用させていただいます。
本当にありがとうございました。
> __________ NOD32 3973 (20090329) 情報 __________
>
> このメールはNOD32によって検査済みです。
> http://canon-sol.jp
>