Windows Mobile 2003 Second Edition Software の開発者向け新機能入
March, 2004
Andy Sjostrom
適用対象
Windows Mobile™ 2003 Second Edition software for Pocket PC
Windows Mobile™ 2003 Second Edition software for Smartphone
Microsoft® .NET Compact Framework
Microsoft ActiveSync®
要約 : Windows Mobile 2003 Second Edition software の新機能について、開発者の観点から詳しく説明します。
トピック
.gif){kind=icon}
はじめに
Windows Mobile 2003 Second Edition の主な新機能
異なる画面方向に対応するアプリケーションの開発
異なる解像度に対応するアプリケーションの開発
特定解像度のリソースを使ったインストール
ActiveSync プログラミングモデルの拡張機能
Today 画面選択用 API
まとめ
はじめに
Windows Mobile 2003 Second Edition software は、引き続きお客様のニーズに最新の技術で応えてまいります。Second Edition は OEM ベンダ、携帯電話通信業者、ISV（独立系ソフトウェア ベンダ）パートナなどに対して新しいプラットフォームを提供し、特定のエンドユーザー ニーズに応えるために各種のハードウェアおよびソフトウェア ソリューションを実現できるようにします。Second Edition では、主要な市場での新しいハードウェア提供に結び付くような豊富な機能が提供されています。
「Second Edition」の名が示すように、このプラットフォームはパートナ各社が Windows Mobile 2003 での実績を基に開発を行えるよう、新機能を追加したものです。Windows Mobile 2003 Second Edition では開発者向けに、横長および縦横同サイズの画面、高解像度画面など新しい工夫が盛り込まれています。これは特定の画面配置や解像度を想定していた開発者にとっては新たな挑戦であるとともに、特定のニーズを満たす、あるいは既存のアプリケーション技術を拡張するための機会でもあります。たとえば、マッピング ソフトウェアで高解像度が得られるようになると、高解像度デバイスで詳細なマップが作成できるようになります。
本書では Windows Mobile 2003 Second Edition software の概要を開発者の観点から説明します。
以下に挙げた文書以外に、本パッケージには新しいヘルパー ヘッダやライブラリ、サンプル コードが含まれています。本パッケージ内の readme ファイルでは、本書に記載の API およびヘルパー関数のサポートを、既存の eMbedded Visual C++® 開発環境に追加する方法も説明しています。
• 異なる画面方向に対応するアプリケーションの開発
• 異なる解像度に対応するアプリケーションの開発
• 制御コードを使った、異なる画面方向および異なる解像度に対応するアプリケーションの開発
• 特定解像度のリソースを使ったインストール
• QVGA Smartphone ホーム画面
• Today 画面選択用 API
Windows Mobile 2003 Second Edition の主な新機能
以下に主な機能を挙げます。
1. Windows Mobile 2003 Second Edition for Pocket PC は、画面モードとして、縦画面、横画面、縦横同サイズのモードをサポートします。ユーザーは縦方向、横方向の画面配置を適宜切り替えることができます。横型専用、縦型専用、または縦横同サイズなど、複数モード間の切り替えをサポートしていないデバイスもあります。
2. Windows Mobile 2003 Second Edition は次のようなモード、解像度、dpi 実装をサポートしています。
Pocket PC
• 縦型 / 横型 QVGA (240 x 320、96 dpi)
• 縦型 / 横型 VGA (480 x 640、192 dpi)
• 縦横同サイズの画面 (240 x 240、96 dpi)
• 縦横同サイズの VGA (480 x 480、192 dpi)
Smartphone
• 縦型 (176 x 220、96 dpi)
• 縦型 QVGA (240 x 320、131 dpi)
1. デバイスは 1 つの dpi 実装に固定されます。ユーザーは 96 dpi から 192 dpi に、あるいはその逆に切り替えることはできません。
2. すべての新しい Windows Mobile 2003 Second Edition デバイスでは、.NET Compact Framework Service Pack 2 が ROM に組み込まれています。最初の .NET Compact Framework バージョンと Service Pack 2 では API の変更はありません。したがって、既存の .NET Compact Framework アプリケーションは従来どおり機能します。
3. ActiveSync プログラミングモデルに対する拡張機能は、Sync Service Providers（SSP）用の新しいインターフェイスを追加することで実現します。新しいインターフェイスによって、SSP によるユーザー対話機能が向上します。
4. 新しい Today 画面選択用APIは、ハードウェア キーパッドを使った内蔵およびカスタムの Today Screen プラグイン間のナビゲーションをサポートします。したがって Pocket PC の Today スクリーンを片手で操作することができます。
5. Windows Mobile 2003 Second Edition software のサポートを eMbedded Visual C++ 4.0 で可能にするには、新しいサービスパック、Service Pack 3 をインストールしなければなりません。
6. 新しいエミュレータ画像を使って、新しいプラットフォーム用のアプリケーションをテストすることができます。以下をダウンロードすることができます。
• Pocket PC
• Smartphone
7. Windows Mobile 2003 Second Edition 専用の SDK はありませんが、テクニカルアーティクルが Web サイトより提供されています。
異なる画面方向に対応するアプリケーションの開発
はじめに
デバイスによっては異なるデフォルト モード (縦型または横型) が設定されていたり、ユーザーがその場で画面方向を変更することができる場合もあるので、アプリケーション側でも各種の画面方向に対応する必要があります。
画面方向の処理
縦型モードだけをサポートしている既存のアプリケーションの場合、アプリケーション内部で画面方向を変更できれば最も簡単です (MSDNの「Rotating the Content of the Screen (画面内容の方向変更)」で説明している ChangeDisplaySettingsEx 関数を使用)。ただし、まずユーザーに確認してから変更するようにしましょう。
画面方向が変わると、アプリケーションに対して WM_SIZEメッセージ (全画面ウィンドウがある場合) と、wParam パラメータを SETTINGCHANGE_RESET に設定された WM_SETTINGCHANGE メッセージが送信されます。通常、WM_SIZE メッセージでは子ウィンドウ (コントロール) の位置やサイズを変更でき、WM_SETTINGCHANGE メッセージでは WM_SIZE メッセージでは指定できない、全画面子ウィンドウのサイズ変更やトップレベル ウィンドウでの MoveWindow の呼び出しなどを行います。
.NET Compact Framework 開発者は Form.Resize イベントだけを捕捉し、レイアウトやコンテンツに対する調整を行うだけでかまいません。
コンテンツの調整
画面のコンテンツの方向を変更する場合、いくつかの方法があります (推奨するものから順番に以下に挙げます)。
• 縦横同サイズでの設計 (縦横 240 x 240 ピクセルが常に表示された状態)
• レイアウト変更
• コンテンツ変更
最も簡単で好ましいのは、縦横同サイズ (240 x 240 または 489 x 480) で常に表示されるように設計する方法です。
この場合は方向が変更してもコードを実行する必要はありません。ただし画面のレイアウトによってはうまく機能しない場合があります。現行の画面方向に応じて、画面領域を有効活用しなければならない場合も少なくありません。
「縦横同サイズの設計」は可能かもしれませんが、ボタンを右側に移動して、リスト ビューのサイズを変更すると見やすくなります。縦横同サイズの設計またはレイアウト変更でほとんどの場合に対応できるはずです。それでも場合によっては、画面のコンテンツを変更しなければならないことがあります。
横型モードのカレンダーは 1 画面に 8 か月分しか表示できません。この場合はコンテンツを変更するしか方法がありませんが、アプリケーションのロジックに影響を及ぼす点に注意してください。縦型モードでは、12 か月のカレンダーを1画面で見ることができますが、横型モードでは次の画面にナビゲーションしなければ 1 年全体を見ることができません。
異なる画面方向に対応していないアプリケーション
4.20 以前のサブシステム バージョン番号 (実行可能ヘッダに記載) のアプリケーションは、レガシー (旧型) アプリケーションとして縦型モードのみサポートしています。この種のアプリケーションを横型モードでも使用できるようにするには、アプリケーションがダイアログ ベースの場合は垂直スクロール バーを横型モードで表示しなければなりません。スクロール バーを使って、画面から外れている部分を表示できるようになります。このような場合には警告メッセージが表示されます。
この警告を表示しないようにするには、VersionMin 値を 4.21 以上に変更する方法が最も簡単ですが、そうするとアプリケーションは Pocket PC 2002 や Windows Mobile 2003 を搭載している旧型のデバイスにアプリケーションをインストールできなくなります。このような問題を回避するため、BuildMax 値を設定情報 (.inf) ファイルの [CEDevice] 部分に追加します。
[ CEDevice ]
VersionMin = 3.00 ; Pocket PC 2002 へのインストールを許可
BuildMax = 0 x E 0000000 ; 正方形及び画面の回転をサポート
BuildMax 値を使って、アプリケーションが縦横同サイズの画面 ( BuildMax = 0 x A 0000000 )、画面の回転 ( BuildMax = 0 x C 0000000 )、または両方をサポートしていることを表すことができます。
まとめ
異なる画面方向に対応するアプリケーションにする方法にはいくつかあり、レガシー アプリケーションは横型モード (スクロール バーを使って) で機能しますが、特定の画面方向を実装することによってユーザーの使用感はかなり影響を受けてしまいます。詳細は、Windows Mobile ウェブサイトにある 「異なる画面方向に対応するアプリケーションの開発」 と 「.NET Compact Framework 用の画面方向および異なる解像度に対応するアプリケーションの開発」 を参照してください。
異なる解像度に対応するアプリケーションの開発
はじめに
dpi、すなわち「インチあたりのドット数」は、表示画面のシャープネス (鮮明さ) を表す単位です。同一領域内のドット数が多いほど、画像は鮮明になります。印刷用のメディアは長年にわたって高解像度技術を利用してきました。1200 dpi プリンタで印刷された書類のテキストは、300 dpi と同じ内容のものですが、はるかに鮮明なテキストが印刷されます。
Windows Mobile 2003 Second Edition software は従来の 96 dpi 以外に、192 dpi の実装もサポートしています。デバイスは 1 つの解像度に固定され、ユーザーは 96 dpi から 192 dpi、あるいはその逆に切り替えることはできません。したがって、たとえば業務アプリケーション開発でよく見られるように、限定された数の特定解像度のデバイスだけを対象にしている場合、該当する解像度だけを想定したコーディングが可能です。ただし、同じコードで異なる解像度を扱う必要がある場合、以下を参照して最適な方法を選択してください。
dpi 値が高くなると鮮明さが著しく向上します。異なる解像度に対応するようにアプリケーションをアップグレードすることで、高解像度デバイスでの表示が正しく行われるだけでなく、以下のような利点を得ることができます。
鮮明なテキスト
ほとんどコストをかけずに、大きな効果が得られる点です。異なる解像度に対応し、TrueType フォントを使用している各アプリケーションでこのような利点が得られます。
詳細なグラフィック
高解像度のビットマップを提供するための処理を行っておくと、アプリケーションは詳細なアイコンやグラフィックを高解像度で表示することができます。
主な注意点
異なる解像度に対応する Pocket PC および Smartphone 用のアプリケーションでは、次の 3 つの共通点に注意する必要があります。
レイアウト
96 dpi を想定し、ピクセル座標値で指定された部分やサイズがある UI エレメントは高解像度のデバイスでは正しく表示されません。一般に、すべての UI エレメントはスケール位置およびサイズで、またはコントロール、フォント、システム メトリックに対して相対的にレイアウトする必要があります。
Windows Mobile 関数 GetDeviceCaps を使って、LOGPIXELSX または LOGPIXELSY を第 2 のパラメータとして渡すことで、解像度を確認することができます。
ピクセル座標値を使った作業を継続することはできますが、次の技法を使って解像度に関する想定を行わないようにすることができます。
SCALEX および SCALEY マクロを使って 96 dpi 座標にスケーリングするか、必要に応じて GetSystemMetrics で返されたメトリックを使用します。
他のコントロールに対して相対的にサイズや位置を表します。
フォントに対して相対的にサイズや位置を表します。
ダイアログ ボックスはすでにフォント サイズを基にレイアウトを決定しているので、通常は高解像度での処理のために特別な修正は不要です。
テキストとフォント
TrueType フォントのスケーリングはスムーズですが、リニアなスケーリングではありません。したがって解像度を 10 倍上げても、文字列の長さがちょうど 10 倍になるわけではありません。長い文字列では特に、蓄積効果によって異なる解像度のテキストが相対的に短くなったり、切り取られたり、予想外の文字送りが行われたりすることがあります。したがって文字列が使用するスペースに関して何らかの想定を行う代わりに、Windows Mobile の GetTextExtent 関数を使用することが重要です。ダイアログのような固定レイアウトでは、どの解像度でもテキスト エレメントが正しく収まるように余分の幅を設けておく必要があります。さらにフォントごとに、異なるノンリニア スケーリング効果が生じるので、複数のフォントを1画面で使用している場合、解像度を変更すると互いに異なる比率で表示される場合があります。
異なる解像度に対応するには、アプリケーションはアイコンサイズやボーダー幅など、各種の画面要素に対してピクセル サイズの想定を行わないようにしなければなりません。Windows Mobile ベースの Smartphone や Pocket PC は、ユーザー システムに関する情報を提供するいくつかのシステム メトリックスを提供しています。たとえば、以下の情報は GetSystemMetrics Windows Mobile 関数で入手することができます。
• 画面サイズは、GetSystemMetrics ( SM_CXSCREEN ) または GetSystemMetrics ( SM_CXSCREEN ) を使って入手できます。
• ボーダー サイズは GetSystemMetrics ( SM_CXBORDER ) または GetSystemMetrics ( SM_CYBORDER ) を使って入手できます。
• 大小アイコン サイズは GetSystemMetrics ( SM_CXICON ) または GetSystemMetrics ( SM_CXSMICON ) を使って入手できます。
高解像度では、比例表示サイズを維持するために線幅を拡大する必要があります。異なる解像度に対応するには、描画するペン幅に合わせてアプリケーションをスケーリングする必要があります。
Windows Mobile の Graphics Device Interface (GDI)による太い線 (1 ピクセルを超える太さ) の描画の仕方では、正確な配置が困難なことがあります。Windows Mobile 関数 LineTo と Polyline への呼び出しでは、GDI が特定の原点をペン幅の中心として使用します。太さが奇数値の線の場合、線の太さは原点の両側に均等に配分されますが、太さが偶数値の場合は GDI が上側と左側に多めに配分します。
ペンの太さを想定せずに線の配置を行っているアプリケーションの場合は、高解像度でも何も変更は行わないため、ペン幅が太くなりますが、それでもおそらく処理は行われるはずです。しかし 1 ピクセルなど、特定のペン幅を想定している場合は、GDI によるレイアウトへの影響を想定しておく必要があります。
画像
本書ではすべてのラスタベースの画像ファイル (BMP / JPEG / GIF)、アイコン、カーソルを「画像」と呼びます。サイズはピクセル単位で固定されているので、異なる解像度に対応するアプリケーションでは特異な問題を発生します。画像のスケーリングでは、論理的には正しいサイズに拡大縮小できますが、高解像度の画面で見やすく表示するには、鮮明な画像を手動で作成し直す必要があります。
画像の拡大
表示する解像度が画像作成時に想定していたものと異なる場合、画像を正しい物理サイズで表示できるように拡大する必要があります。ただし、ペイントするたびに毎回画像を拡大するのか、拡大済みの新しいビットマップを作成しておくのかを決定しておかなければなりません。
ビットマップ ペインティング コードが入手可能な場合は、ペイント上で拡大するようにコードを変更しておくほうがメモリの消費量が少なくて済みます。ただしビットマップのスケーリングを認めていない関数やオブジェクトを使用している場合は (たとえば画像リスト用の関数など )、読み込み時に拡大しなければなりません。
スケーリングの代わりに、解像度ごとに別な画像を使用する方法もあり、最適な結果が得られます。
.ico フォーマットでは、複数の画像サイズを 1 ファイルに保存することができます。アイコンやカーソルを読み込む際、アプリケーションが GetSystemMetrics 関数の推奨するサイズを確認し、システムが最適な画像を選択する仕組みになっています。
Windows Mobile は高解像度表示でビットマップを固定コントロールに自動的にスケーリングします。ただし、ビットマップが含まれるコントロールよりもビットマップ サイズが大きい場合は、Windows Mobile は高解像度用に作成されたビットマップと見なします。したがって、固定コントロールを正しく機能させるために、特別な変更は必要ないものと思われます。
レガシー サポート
高解像度の Windows Mobile 2003 Second Edition ベースの Pocket PC は、古いアプリケーションとの下位互換性のためのエミュレーション レイヤーも提供しています。このエミュレーション レイヤーを使うと、レガシー アプリケーションで従来の 240 x 320 で表示されます。ただし、オペレーティング システムはすべてのグラフィックを実際の表示サイズにスケーリングします。フォントの高さはリニアにスケーリングされます。
GAPI を頻繁に使用するアプリケーションでは、古いバージョンの Pocket PC や Smartphone ハードウェアに基づいて画面サイズを想定しています。レガシー アプリケーションとの下位互換性を維持できるよう、エミュレーション レイヤーが GAPI に追加されました。デフォルトでは、このレイヤーは GAPI 描画を画面に合わせてスケーリングしますが、高解像度対応のアプリケーションではエミュレーション レイヤーを省略して、表示用ハードウェアに完全にアクセスできるように設定しておくことができます。GAPI を使用しているレガシー アプリケーションも、GAPI を使用していないアプリケーションと同じ下位互換性を得ることができます。
まとめ
エミュレーション レイヤーによって、新旧のアプリケーションが高解像度の Windows Mobile ベースの Pocket PC で問題なく機能するようになります。高解像度の利用、複数の解像度に対応可能なデバイスへの優れたサポート提供が最適に行えるような工夫を行いました。Windows Mobile ホームページにある 「異なる解像度に対応するアプリケーションの開発」 と 「.NET Compact Framework用の画面方向および異なる解像度に対応するアプリケーションの開発」 を参照してください。
特定解像度のリソースを使ったインストール
背景
異なる解像度に対応するアプリケーションを開発、販売する場合、高解像度のビットマップやその他のリソースを盛り込みたい場合があります。古いリソースと一緒にこれらを提供するのも 1 つの方法ですが、そうすると以下のような問題が生じます。
1. 両方のリソースがすべてのデバイスに含まれることになり、デバイス メモリを無駄に消費してしまうことになります。192 dpi デバイスでは 96 dpi は不要で、96 dpi では 192 dpi は不要です。
2. デバイスの解像度に応じて別なリソースを読み込むようにコードを修正する必要があります。
将来的にはさらに別な解像度 (192 dpi より高い解像度) が必要になるということを考えると、このような問題はさらに深刻です。
解決方法
解決策としては、リソースごとに異なる 2 つの DLL に保存し、デバイスへのインストール時に該当する DLL だけを使用するという方法があります。このために、『Developer Resources for Windows Mobile 2003 Second Edition』に SetupDPI.dll ライブラリが提供されています。
SetupDPI.dll
SetupDPI.dll は、デバイスの現在の解像度に応じてリソース ファイルをインストールし、名前を変更し、削除した後で起動します。ファイル リスト (インストール中に挿入されたもので、以下参照) を含むレジストリ キーを検索し、ファイル名の変更や削除を適宜行います。現在の解像度が 192 dpi の場合、RES_192.DLL が RES.DLL というファイル名に変更され、RES_096.DLL は削除されます。SetupDPI.dll ライブラリを使った例が、特定解像度のリソースを使ったインストールに関する文書に含まれている ResDLL サンプルとして提供されています。
コード変更
最初に、リソース ID が 2 つの DLL とアプリケーション自体で同一であることを確認する必要があります。同一のリソース固定ファイルを使用する方法をお勧めします (サンプルで示したように)。次にアプリケーションのインストール時にリソース DLL を開き、戻されたハンドルをリソースの必要時に必ず使用します。
#include "res_096\resource.h"
// ...
g_hInstRes = LoadLibrary(_T("RES.DLL"));
// ...
hBMP = LoadBitmap(g_hInstRes, MAKEINTRESOURCE(IDB_MYBITMAP));
セットアップ変更
セットアップ情報 (.inf) ファイルで、リソース ファイル リストを次のようにいくつかのレジストリ エントリとして追加する必要があります。
[AddRegSection]
HKLM,Software\Microsoft\SetupDPI,%InstallDir%\Res_096.DLL,65537,0
HKLM,Software\Microsoft\SetupDPI,%InstallDir%\Res_192.DLL,65537,0
まとめ
SetupDPI.dll を使用することによって、特定解像度のリソースをアプリケーションに簡単に追加することができ、コードやセットアップ ファイルへの影響も最小限に抑えることができます。詳細は『Developer Resources for Windows Mobile 2003 Second Edition』の 「特定解像度のリソースを使ったインストール」 と ResDLL サンプルを参照してください。
ActiveSync プログラミングモデルの拡張機能
はじめに
ActiveSync プログラミングモデルの拡張は、Sync Service Providers (SSP) 用に新しく 3 つのインターフェイスを提供することで実現しました。以下のような新しいインターフェイスによって、ユーザーとの対話機能が向上します。
• OnSSPEnable - SSP が ActiveSync Options ダイアログで Enable が設定された場合に呼び出されます。
• OnSSPDisable - SSP が ActiveSync Options ダイアログで Disable が設定された場合に呼び出されます。
• IReplStore 2 - IReplStore から派生した新しいインターフェイスで、これによって SSP は設定ダイアログを実際に有効にする前に表示できます。
新しい OnSSPEnable および OnSSPDisable インターフェイスによって、SSP はユーザーが Options ダイアログ内で Enable チェックボックスをクリックした場合に反応できるようになります。これは複数の SSP が互いに対話しなければならない場合や、SSP が別なプロセスに Enable / Disable の情報を伝えなければ成らない場合に便利です。IReplStore 2 インターフェイスでは、SSP はあらゆる場合に設定ダイアログを表示できます。SSP がこのインターフェイスを実装していない場合、Options ダイアログの表示前に SSP が Enable に設定されていなければ、ActiveSync は設定を表示しません。このインターフェイスは、ActiveSync 3.7.1 以上で使用できます。
インターフェイスの詳細
OnSSPEnable
SSP がエクスポートすることのできる新しい関数です。この関数は、SSP が ActiveSync Options ダイアログ内で Enabled に設定されている場合に呼び出されます。
OnSSPEnable は次のような引数と戻り値を使用します。
HRESULT WINAPI OnSSPEnable (HWND hwndParent);
• hwndParent : この関数を呼び出した場合に、SSP が表示するダイアログ ボックスの親として使用する HWND です。
備考 : IReplStore : Initialize 関数は、この関数より先に呼び出されていない場合があります。したがって、IReplStore : Initialize の呼び出しに依存するような内部変数の使用は避けてください。
OnSSPDisable
SSP がエクスポートすることのできる新しい関数です。この関数は、SSP が ActiveSync Options ダイアログ内で Disabled に設定されている場合に呼び出されます。
OnSSPDisable は次のような引数と戻り値を使用します。
HRESULT WINAPI OnSSPDisable (HWND hwndParent);
• hwndParent : この関数を呼び出した場合に、SSP が表示するダイアログ ボックスの親として使用する HWND です。
備考 : IReplStore : Initialize 関数は、この関数より先に呼び出されていない場合があります。したがって、IReplStore : Initialize の呼び出しに依存するような内部変数の使用は避けてください。
IReplStore 2
これは IReplStore から派生した新しいインターフェイスで、SSP はこれによって設定ダイアログを有効にする前に表示することができます。
まとめ
新しいインターフェイスによって SSP は、わかりやすく、使いやすい同期化機能を設計、開発できるようになりました。詳細は、『Developer Resources for Windows Mobile 2003 Second Edition』の 「ActiveSync プログラミングモデルの拡張機能」 を参照してください。
Today 画面選択用 API
はじめに
Windows Mobile 2003 Second Edition software for Pocket PC によって、ユーザーは Pocket PC の Today 画面プラグイン間、またはプラグイン内のナビゲーションを行うことができます。したがってユーザーはスタイラス ペンを使用しなくても、Today 画面を片手で使用できるようになりました。
プラグインでハードウェア キーパッドを使った Today 画面プラグイン間のナビゲーション機能をサポートできるようにするには、以下の方法を使用することができます (レジストリ キー "HKEY_LOCAL_MACHINE＿Software\Microsoft\Today\Items\" "yourpluginname" と "Selectability" の値を設定する) 。
• Selectability = 0 (または存在しない場合) は、プラグインが選択できず、通知は行われないことを示します。
• Selectability = 1 の場合は、Today 画面で選択を制御し、プラグインには通知が行われないことを示します。
• Selectablity = 2 の場合は、以下に記載した内容に従って、プラグインに通知が行われることを示します。
通知メッセージ
次の通知メッセージが Today プラグインに送信されます。
受信
• WM_TODAYCUSTOM_RECEIVEDSELECTION は、プラグインが選択内容を受信した場合に受け取ります。押し下げられた仮想キー (VK_DOWN または VK_UP) が wParam パラメータ内にあります。プラグインが変更を受け入れる場合は TRUE を戻す必要があります。
• WM_PAINT および WM_ERASEBKGND メッセージは、Selectability の値に関係なく再描画を行えるようにするために受信します。
• WM_TODAYCUSTOM_USERNAVIGATION は、ハードウェア ナビゲーション キーを押したときに受け取ります。押し下げられた仮想キー (VK_UP、VK_DOWN、VK_LEFT、VK_RIGHT) が wParam パラメータ内にあります。ナビゲーションを処理する場合は、戻り値は TRUE になります。
• WM_TODAYCUSTOM_ACTION は、ハードウェアの "Action" キーを押したときに受け取ります。
• WM_TODAYCUSTOM_LOSTSELECTION は、選択内容を失った場合にプラグインに送信されます。
送信
• TODAYM_DRAWWATERMARK (通常は WM_PAINT メッセージに対する応答として) を Today 画面に送信して、背景を描画することができます。
• TODAYM_TOOKSELECTION を Today 画面に送信して、プラグインが選択内容を受け入れたことを示すことができます (たとえばユーザー タップに対する応答として) 。Today 画面は TODAYM_RECEIVEDSELECTION メッセージで wParam を 0 に設定して、選択変更が正しく行われたことを示すことができます。
まとめ
Today 画面のプラグイン選択のための基本サポート機能追加に必要な変更はごくわずかです。またコードを大幅に変更しなくてもフル サポートが可能です。ただしコントロールの選択など、高度な機能をプラグイン内に盛り込んでおくことをお勧めします。詳細は、『 Developer Resources for Windows Mobile 2003 Second Edition 』の 「Today 画面選択用API」 を参照してください。
まとめ
新しい画面方向モードや解像度、ActiveSync プログラミングモデルの拡張機能、そして最新の .NET Compact Framework の ROM への組み込みなど、Windows Mobile 2003 Second Edition の新機能とプラットフォームの改善によって、ユーザーにさらに高い満足度を提供することができます。プラットフォームの改善によって OEM による新しいハードウェア設計、携帯通信業者による画期的なサービスの提供、そして ISV による高度なアプリケーションの新規開発が可能になります。
Windows Mobile 2003 Second Edition の新機能を使って、アプリケーションを拡張し、ユーザー満足度を高めましょう。