技術メモ

一般的なVisualC++におけるUNICODEの取り扱い
特に、ここではASCII(SHIFTJIS)ファイルをUNICODEのアプリケーションで取り扱う
場合、注意すべき点をメモしておきたいが、そこに行きついた背景も説明できればと思う

背景として

VC++6.0までは、デフォルトASCIIで文字列を扱うことが普通だったが、
.NETの到来により、UNICODEが本格的に取り扱われるようになり、開発方法も変更を余儀なくされいいる

また、先にWindowsCEでは、UNICODEのみのサポートのみであったため、
デバッグ時、CEのコードをそのまま使って、Windows上で動作させたい場合、強制的に
UNICODEの開発を余儀なくされてしまう。
そこで、極力いままでの既存コードを活用しつつUNICODEを利用するための
注意事項を下記に記載する

１．MFCを使う
STLも利用できるのだが、マルチバイトの取り扱いをCStringで吸収してくれるので、
UNICODEを意識せずに文字列を取り扱える
C++CEを使用する場合、相性がよい

２．_T("")の使用
これも、１と同様、これで文字列定数を記述しておけば、ASCII,UNICODEの切り替えがよういになる

３．文字列を取り扱っている、ＣＲＴ関数群は、ASCII,UNICODE互換関数を使用する
これも１と同様
要は引数に文字列を使用している場合、互換用の関数が必ずよういされているので、こちらを使用する

４．外部ファイルにおけるファイルの取り扱い
基本は、ASCIIファイル形式（SHIFTJIS形式）で統一しておいても、上記の関数を使用することで、
ファイルを読み込むときに、シングルバイトもしくはマルチバイトでメモリには取り込んでくれる
ただし、２つほど注意が必要。
まず、テキストファイル読み込む場合は、必ずテキストモードで開くこと。
もし、バイナリーモードで開いた場合、シングルバイト、マルチバイトの切り替えは行われない
（バイナリーで開いているわけだから、当然といえば当然）
もう一つの注意点だが、SHIFTJISの部分は、自動的にUNICODEに変換されるわけではない
理由は、通常文字列のなかに、SHIFTJISが使用されているかがわかっていないためで、
これをわからせるために、ロケールの定義を行う必要がある。ロケール定義は、
_tsetlocale(LC_ALL, _T(""));により、ＯＳの規定ロケールが設定される。これをアプリケーションの
初期処理に定義しておくことで、アプリケーション内では、規定ロケールで動作することになる。
余談だが、WIndowsCE（少なくともCE5まで、6以降は確認していない）は、この定義が不要
ってか、おそらく文字列変換処理が強制的に行われる（UNICODEであることとオーバヘッドのため？）
なので、ロケール定義は行わないっというか_tsetlocale関数は存在しない
だから、これはUNICODEによるWindowsアプリを作成する場合のみ必要になる

2011/04/15 (Fri) UNICODE Comment(0)

GridViewで、更新処理を行う場合の注意点

これも、CommandFieldを使用した場合の更新処理で
（azure ストレージへの更新を行ったときにはまったけど、ObjectDataSource全般にかかわると思われる）

GridView上で、更新処理を行う際、ObjectDataSourceを経由して、更新メソッドをコールするが、
この時、更新したい値の引数は、必ずエンティティプロパティ名と同じにしておく必要がある（大文字小文字の区別無し）。
これで、更新メソッドの引数に値が渡されるようになる。

合わせて、もうひとつ注意点
GridView上で、表示されているフィールドのなかで、更新対象でないフィールド（更新メソッドの引数に定義されていない、エンティティプロパティは、GridViewの列編集で、必ずReadOnlyにしておくこと設定していない場合、更新メソッド内にその引数がないと判断して例外処理が発生する

2011/04/08 (Fri) ASP.NET Trackback() Comment(0)

GridViewのCommandFieldを使用する場合の注意点

GridViewのCommandField（編集、削除）などを使用して、
削除メソッド、更新メソッドを実行する場合、
検索キーとして、GridViewのDataKeyNamesプロパティを設定しておく必要がある
これを設定しておかないと、削除、更新メソッドをコールしたとき、
検索キーにnullが格納されて、コールしてしまう

2011/04/08 (Fri) ASP.NET Trackback() Comment(0)

Azureストレージのテーブル名に関して

Azureストレージのテーブル名は、
'_'は使えません。

・英数字のみ（先頭文字は英字のみ）
・大文字小文字は区別しない
・名前の長さは、３～６３文字の間

エンティティには、最大２５５のプロパティを持つことができる
（システム予約プロパティ３つも含む）

2011/04/08 (Fri) azure Trackback() Comment(0)

Azureストレージサービスによるログイン認証ページ作成に関して

ASP.NETで自動生成されるログイン認証ページは、データ管理をSQLServerで行っているため、
そのままでは、使用できない。

そこで、MSではサンプルレベルとして、AspProvidersライブラリを提供しているが、SDKに含まれていないことから、今後変更されることになると思われる。

参考文献
実装にあたり非常に役に立ちました
http://codezine.jp/article/detail/5630
このあたりは、まだ発展途上のため、新しい文献を参考にしないとひどい目にあいます。
ちなみに、わたしがダウンロードした。azureのサンプルは「WAPTKVS2010-February2011exe」
で一つ新しいもの？だったが、とくに問題なく動作した。

ただし、上記の説明はデバッグ環境（ローカル）での説明なので、ターゲットのストレージが「DataConnectionString」
でない場合、AspProvidersのConfiguration.csのDefaultStorageConfigurationString変数を
任意に名称に変更する必要がある。

また、AspProvidersが使用する。web.config定義のkeyも「DataConnectionString」から任意の名称に
変更する必要があり、value値は、ストレージ設定用に変更が必要
当然、AccontKeyなども変更が必要

web.config

</appSettings>

2011/04/06 (Wed) azure Trackback() Comment(0)