(57)【要約】装置製造会社により提供される中間ソフトウエア層は、汎用アプリケーションにより提供されるコマンドリスト及び動作を処理し、それらを種々の入力機構に割り当て、装置のスクリーンに表示する適切なメニューを構築することが望ましい。アプリケーションが複数のウィンドウ、画面又はウィンドウ枠をサポートするところでは、中間層はフォーカスのあるアプリケーション部分を識別し、ユーザ入力に従って得られる動作を調整することができる。したがって、計算装置は、当該装置用に特別に設計されていない汎用アプリケーションが、個々の装置が有するこれら固有の入力メソッドを利用することができるように動作する。本発明は、入力を提供する固定の枠組みを持たず、キーボードに（そのあり場所では）個定数の入力ボタンを持たない移動電話などの装置に適用されることが望ましい。
2008504623.tif 000002
【特許請求の範囲】
【請求項１】
計算装置の制御方法であって、前記計算装置が特に該計算装置用に作成されていない１以上の汎用アプリケーションを含み、該１以上の汎用アプリケーションのユーザインタフェースは独立の入力を必要とする１以上の画面、ウィンドウ枠又はウィンドウをサポートし、該１以上の汎用アプリケーションがコマンドを受理するために使用すべき該計算装置上で利用可能な入力メソッドに関する知識を持たない場合に、前記方法は、
前記計算装置の入力メソッドに関する知識を有するソフトウエアエンティティを含み、
前記ソフトウエアエンティティが、前記入力メソッドの知識を持たない前記１以上の汎用アプリケーションに、該入力メソッドを利用させるためのアプリケーションプログラムインタフェース（ＡＰＩ）を提供する
ことを特徴とする方法。
【請求項２】
前記ソフトウエアエンティティは、
１つのアプリケーションに対する全てのコマンドを管理し、かつ、ユーザと協働するための予め定められたソフトキー又はメニュー制御を含む単体クラスであることを特徴とする請求項１に記載の方法。
【請求項３】
前記１以上の汎用アプリケーションは、前記ソフトウエアエンティティへの対応付けを必要とするコマンドリストを提供することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記１以上の汎用アプリケーションは、前記ソフトウエアエンティティへの対応付けを必要とするコマンドリストを提供する制御部品を含むことを特徴とする請求項１乃至３の何れか１項に記載の方法。
【請求項５】
前記ソフトウエアエンティティは、フォーカスのある複数の前記アプリケーション又は前記制御部品を検出し、使用されるべき前記コマンドリストを、フォーカスのある該アプリケーション又は該制御部品によって提供されるコマンドリストに適合させることを特徴とする請求項４に記載の方法
【請求項６】
前記制御部品は、前記ソフトウエアエンティティによって優先付けされることを特徴とする請求項４又は５に記載の方法。
【請求項７】
請求項１乃至６の何れか１項に記載の方法に従って動作する計算装置。
【請求項８】
請求項１乃至６の何れか１項に記載の方法に従って計算装置を動作させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算装置を動作させるための方法に関する。特に、本発明は、入力機構を使用し、特定のメニュー及びユーザダイアログを含む汎用ソフトウエアを計算装置に実行させる方法に関する。
【背景技術】
【０００２】
ここで使用される用語「計算装置」は、あらゆる形式の電子計算装置を含むように拡張して解釈される。また、用語「計算装置」は、データ記録装置と、携帯機器及びパーソナルコンピュータを含むあらゆるタイプ又は形式のコンピュータと、通信装置と、他形式の無線情報装置及び有線情報装置とを含む。また、ここで通信装置は、移動電話機と、スマートフォンと、通信機能、画像記録機能及び／又は再生機能、及び単一装置内の計算機能を有する通信機器とを含む。
【０００３】
多くの計算装置は入力機構を含み、それによりユーザは、コマンドを与えるか、又はデータを入力するかの何れかにより装置を制御するソフトウエアと協働することができる。
【０００４】
これらの入力装置の中で最も一般的な入力装置はキーボードである。キーボードは、特定項目のデータに常に対応付けられる特定のキーを有するという特徴がある。キーボードは、長年に亘ってプログラム可能なキー又は専用機能キーの追加によって拡張されてきた。これらのキーは、これまでと違って１つのキーを押すことにより、複雑なコマンドや一連の文字の入力を可能とする。
【０００５】
キーよりむしろ１９６０年代後期におけるマウスの発明により普及したポインティングデバイスを介した新たな入力形式は、制御部品として知られるスクリーンの領域を使用する。制御部品には、装置にコマンドを発行するためにスクリーン上のカーソルを使用して、クリックすることができる１以上の部品を含むアイコン、ダイアログ、又はメニューが表示される。このタイプのスクリーンを基本としたユーザ入力は、マウスに加えてタッチスクリーン、ライトペン及びジョイスティックなどの他のタイプのポインティングデバイスにより使用することもできる。
【０００６】
あらゆる計算装置のためのユーザインタフェース・ソフトウエアは、スクリーン上に正確に表示されるメニュー、アイコン及びダイアログを含む。特に、異なるモデルの小型の携帯装置（移動電話機など）は異なるメニュー構造、テキストプロンプト及びメニューを必要とする。通常、これらは、利用可能な入力メソッド及びディスプレイ特性に調整される。入力が必要な場合、メニューはユーザが利用可能な入力メソッドに適する必要がある。マウスのないユーザにはクリックを要求するダイアログを提示すべきでなく、キーの押下が必要な場合、ユーザにはその個々の装置で利用できないキーの押下を求めてはならない。
【０００７】
現在、かなり多くの多様な装置があり、どのようにこの多様性に対処するかは、ユーザインタフェース（ＵＩ）の設計者に対して明確な問題を提示するものであり、設計者には装置のパラメータが何であるかを前もって知る方法がない。
【０００８】
上記問題を解決するために使用することができる幾つかの可能な選択肢がある。
・普及する産業界標準の設計。
・特定の装置に対するＵＩの設計。
・異なる装置系への独立のソフトウエアバージョンの提供。
・ユーザインタフェースに複数のバージョンを含み、装置のハードウエアを認識することができる場合、使用するバージョンの選択を動作時まで遅らせる。
・最小公分母に対する設計。
・バーチャルマシンなどの標準の中間ソフトウエア層の設計。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した解決方法はいずれも、主に以下の理由によりソフトウエアユーザ、ソフトウエア作成者、又は一般のユーザのいずれにとっても理想的ではない。
・普及する産業界標準のための設計は、新しい、革新的特徴を持つ技術を組み込む装置には向かず、ソフトウエアがこれらの装置上で動作するように設計されないため、その経済的可能性が低下し、進歩が抑制される。
・特定の装置に対するＵＩの設計は、製品が利用可能な市場を制限し、ユーザの不満を募らせる。
・異なる装置系への独立バージョンのソフトウエアの提供は、作成者にとって非効率的であり、作成者が複数の同じ製品のバージョンを作成する必要がある。これは、ユーザにとっても紛らわしいことでありえ、最終的に間違ったバージョンを持つ虞がある。
・複数のＵＩを含み、動作時に使用するものを決定することも非常に非効率的である。作成者は、使用されそうにないＵＩを作成し、それをソフトウエアに含む必要がある。移動電話機などの計算装置では、これにより、また僅かなメモリリソースを使い果たす。
・最小公分母の設計によりユーザは、可能な最良のインタフェースを有することが不可能になる。
・バーチャルマシン（ＶＭ）に対する設計によりハードウエアの相違を抽象化することができる。バーチャルマシンは各装置に対して異なる中間ソフトウエア層を提供する。しかし、それぞれのバーチャルマシンはバーチャルマシンを使用するソフトウエアに対して同じアプリケーション・プログラミングインタフェース（ＡＰＩ）を提供することとなる。
【００１０】
ここで指摘する困難はデスクトップＰＣにとって現時点では特に重要ではない。これは、入力メソッド及びスクリーンが標準化され、およそ１５年の間多くは変化していないからである。しかし、これは、計算装置全てには当てはまらない。
【００１１】
特にセルラー電話機などの移動通信装置の形式における計算装置の入力の特徴は、製造会社ごとに異なり、さらに、同じ製造会社のモデルごとにも異なる。モーション社（Motion Ltd）における研究によるブラックベリー（Blackberry）などの少数の装置は、英数字キーパッドを有し、あるものにはキーパッドは全然なく、単にタッチスクリーンがある（ノキア７７００、又はフリップにより開いて動作する場合のソニー・エリクソンＰ８００及びＰ９００など）。多くの移動電話機は、標準として数字キーパッドを備えるが、その場合でも製造会社毎に異なるキーパッドに加えて、いくつかの特別のキー又はボタンがあり、その配置の便宜性は非常に異なる。また、タッチスクリーンを備える移動電話機や、備えない電話機もある。ある電話機にはジョグホイールがあり、あるものには４方向又は８方向のいずれかでありうるジョイスティックがある。電話機はジョグホイール及びジョイスティックの両方を有することができる。さらに白黒のスクリーンディスプレイにおける制御部品のための最適スクリーンの設計は、カラースクリーンディスプレイでは最適ではないであろう。スクリーンの大きさ及び解像度と、ピクセルの大きさとは、また装置間で大きく異なる。全てこれらの要因はユーザインタフェースの設計方法に影響する。
【００１２】
上述の問題を解決する最も適切なよく知られた提案は、サンマイクロシステム社のジャバＭＩＤＰ（移動情報装置プロファイル）のメニューシステムにより実装されたバーチャルマシンである。注目すべきは、上記の問題が、http://jaba.sun.com/j2me/docs/alt-html/midp-style-guide7/midp-char.htmlなどの文献において特に述べられていることであり、この文献では、以下のように述べている。
【００１３】
「例えば、幅１００、高さ１２８、４レベルのグレースケール・ディスプレイ及びＩＴＵ−Ｔの電話機キーパッドを持つ移動電話機に関するアドレス帳を考えよう。アプリケーションでは２つのソフトボタンをスクリーン底部に持つ垂直方向の配置がありうる。次に、幅２４０、高さ１００、２５６色のディスプレイ、ペン及びタッチスクリーンを有する装置へアドレス帳を移す。アプリケーションがＵＩの詳細を担えば、垂直方向の配置は不便であり、適切でないであろう。」。
【００１４】
ジャバＭＩＤＰメニューシステムでは高水準ＬＣＤＵＩ（液晶ディスプレイ・ユーザインタフェース）ＡＰＩにより問題を解決しようとする。これは、アプリケーションにそのアプリケーションのスクリーン制御部品を提供させずとも、いくつかのアプリケーションコマンドを、装置の特定のキーに対応付けることができる。しかしながら、ジャバ・バーチャルマシンは、本質的に理想的又は汎用的なハードウエア環境の抽象化であり、アプリケーションは全てこのバーチャルマシンに適合しなければならない。例えば、バーチャルマシンは１つのウィンドウを持つ簡単なメニューシステムのみをサポートするが、これは融通性のない制限であり、複数のウィンドウ枠を必要とする画面、ダイアログ及びポップアップを持つ融通性のあるアプリケーションを作成することを実質的に不可能とする。
【００１５】
そのようなバーチャルマシンはある点で種々の装置系に独立バージョンのソフトウエアを提供する解決方法に類似するが、各装置に独立バージョンを提供する負担がソフトウエア提供者からバーチャルマシンの提供者に移り、その負担は一度のみですむので、不利なことは何もない。しかしながら、バーチャルマシンには最小公分母に対する設計での解決方法と同じ不利がある。ハードウエアの相違が抽象化されるため、バーチャルマシンの特性が別の最小公分母となり、固有のハードウエアの特徴を有利に使用できない。
【００１６】
したがって、今日まで、汎用ソフトウエアアプリケーションが動作する各装置に対して、当該汎用ソフトウエアアプリケーションが最良の操作性を提供できるような装置を構築する満足な方法がなかった。
【００１７】
本発明の目的は、複数の装置系で利用可能な機能を最大にする汎用ソフトウエアを適用するための改善された方法を提供することにある。
【課題を解決するための手段】
【００１８】
本発明の第１の態様によれば、計算装置を動作させる方法であって、計算装置は、特に計算装置用に作成されていない１以上の汎用アプリケーションを含み、１以上の汎用アプリケーションのユーザインタフェースは独立の入力を必要とする１以上の画面、ウィンドウ枠又はウィンドウをサポートし、１以上の汎用アプリケーションがコマンドを受理するために使用すべき計算装置上で利用可能な入力メソッドに関する知識を持たない。本方法は、計算装置の入力メソッドに関する知識を有するソフトウエアエンティティを含み、ソフトウエアエンティティは、入力メソッドの知識を持たない１以上の汎用アプリケーションに、当該入力メソッドを利用させるためのアプリケーションプログラムインタフェース（ＡＰＩ）を提供する。
【００１９】
本発明の第２の態様によれば、第１の態様の方法に従って動作するように構成される計算装置が提供される。
【００２０】
本発明の第３の態様によれば、第１の態様の方法に従って計算装置を動作させるためのコンピュータプログラムが提供される。
【発明を実施するための最良の形態】
【００２１】
以下では、添付の図面を参照して本発明の実施形態の一例について説明する。本質的に本発明は、アプリケーションから抽象化され、ハードウエア製造会社から提供される装置に括り付けのソフトウエアエンティティに委ねられる入力機能（メニューバー／メニューのウィンドウ枠／ソフトウエア又はハードウエアボタンなど）へのアプリケーションコマンドの配信を可能にすることにより、上述した問題の解決方法を提供する。本発明の記載では、このソフトウエアエンティティをコマンド処理フレームワーク（ＣＰＦ）として称する。
【００２２】
ＣＰＦとバーチャルマシン（ＶＭ）との入力を扱うメソッドの重要な違いは、ＶＭではハードウエアの相違を隠すように設計され、一方ＣＰＦではその相違を使用することができるように設計されることである。したがって、２つの機構の方法論は非常に異なり、互いに厳密な対照をなす。
【００２３】
ＵＩＱテクノロジーＡＢのＵＩＱ（登録商標）ユーザインタフェース・プラットホームにおいて実装される場合のＣＰＦの機能を以下に説明する。この機能は、シンビアンソフトウエア社の次世代移動電話機のオペレーティングシステムであるシンビアンＯＳ（登録商標）オペレーティングシステム上で動作するように設計される。ＵＩＱインタフェース・プラットホームを使用するシンビアンＯＳプログラミングに関する当業者がこの短い説明を容易に理解するように、このオペレーティングシステムにおいて使用されるプログラミングメタファーに関する完全な解説は、リチャード・ハリソン（Richard Harrison）の「移動電話機のためのシンビアンＯＳ  Ｃ＋＋」(ISBN 0470856114)などの標準的なテキストにおいて容易に得ることができる。したがって、これらのメタファーについては本明細書で特に記載しない。
【００２４】
コマンド処理フレームワークは、単体ＣＰＦマネージャクラス（CQCpfManager）により実装される。このクラスは、単体アプリケーションにおけるコマンドを全て管理する。このインスタンスは、アプリケーションの開始時に作成される。クラス定義を含むヘッダファイルを以下に詳述する特定コードの例において示す。
【００２５】
CCoeControlは、自身のコマンドのセットを望む場合、InitializeResourcesForLを呼び出さなければならない。標準CQikViewBaseを利用するＵＩＱプログラムは、ConstructLにおいて、これを達成することができる。CommandModelListが生成される場合、CCoeControl又はそのコンポーネントの制御部品のいずれかがＣＰＦマネージャにコマンドを追加することができる。
【００２６】
注意すべきは、コンポーネントの制御部品にフォーカスがある場合（即ち、コンポーネントの制御部品が、現在、アクティブな制御部品であり、入力が全てアクティブな制御部品に経路指定される場合）に、親の制御部品のコマンドが利用可能であることを望まないコンポーネントの制御部品は、アプリケーションユーザインタフェースの制御部品のスタックにあるはずであり、それ故自身のCommandModelListを生成すべきである。
【００２７】
ＣＰＦマネージャは制御部品を持たないが、ソフトキー制御部品などの標準の制御部品及びメニュー制御部品を採用することができる。CCoeControlが制御部品の採用を望む場合、MCpfControlOwnerインタフェースを実装し、ポインタを供給することができ、ポインタにおいてＣＰＦマネージャは使用することを望む追加ＣＰＦ制御部品を取り出すことができる。
【００２８】
ＣＰＦにより、アプリケーション開発者は全てのシステムプログラムに適用するような標準的な方法でアプリケーションのリソースファイルにおいてコマンドを記述する。しかしながら、アプリケーションの画面のConstructLにおいて、画面は、リソース定義がＣＰＦマネージャのインタフェースに渡されるように設定される。したがって、これが、アプリケーション開発者が結びつける必要がある唯一のインタフェースであり、このインタフェースは、装置製造会社がバイナリ適合性を気にすることなく相互動作の制御部品を取り替えることを可能にする追加の利益をもたらす。
【００２９】
製造会社が装置を製造する場合、ソフトキー制御部品及びメニュー制御部品などの、ユーザとの相互動作のための制御部品が定義され、構成される。ＣＰＦマネージャがフォーカスの変更を検出すると、最上位のフォーカスされた制御部品（例えば、画面）が決定され、対応するコマンドリストが取り出され、現在のアクティブなＣＰＦ制御部品（例えば、ソフトキー制御部品又はメニューバー制御部品）に渡される。同時にアクティブな２つ以上の制御部品がありうるので、これらの制御部品はＣＰＦマネージャが決定する順序付けプロトコルに従って優先付けされる。代表的なプロトコルでは、例えば、優先度の低い制御部品にコマンドを提供する前に、優先度の高い制御部品にコマンドを使用する機会を与えるように定めることができる。
【００３０】
したがって、本発明によれば、例えばプログラム可能な機能キー又はタッチスクリーンを持つ装置上で開発者のアプリケーションが実行可能であるかなど、アプリケーション開発者は入力メソッドの利用可能性について気にする必要はない。さらに、これらのアプリケーションがＣＰＦを使用すれば、装置製造会社又はネットワーク運用会社は装置にロードすることができるアプリケーションの外観を制御することができる。
【００３１】
アプリケーション開発者の観点から、ＣＰＦの動作を添付の図面に示す。図１は、スクリーン制御部品と装置におけるアプリケーションのためのコマンドリストとの関係を示す。各スクリーン制御部品は１以上の入力をコマンドリストに与える。この例では、画面制御部品は４つの項目をコマンドリストに与え、それ故ユーザはスクリーンの表示を取り消し、入力表示を編集し、入力表示を取り消すか、又は支援のためのヘルプコマンドを選択することができる。図１に例示するように、コマンドは入力の電話番号にフォーカスを当て、３つの選択肢がユーザにとって利用可能である。選択肢の１つが選択されると、その特定のコマンドはフォーカスを失い、電話番号に対するコマンドリストの入力はリストから削除される。コマンドリスト自体を図２に示す。
【００３２】
図３から図６は、異なる入力メソッドを持つ装置における利用可能な入力メソッドへのコマンドのＣＰＦによる対応付け方法を示す図である。
【００３３】
図７は、キー及び制御部品への割り当てのためのコマンドタイプによる分類方法を示す図である。
【００３４】
図８は、図５に示すような入力メソッドを有する装置へのコマンドの宛先を特定するためのコマンドタイプの使用方法を示す図である。
【００３５】
要するに本発明は、計算装置を制御する手段を提供することにより、アプリケーションが動作する装置の入力特性を知ることなく個別仕様のアプリケーションを開発することを可能にし、制御部品の提供により装置に対して特別に設計されたものでなく汎用アプリケーションが、それにもかかわらず個々の装置が有するこれら固有の入力メソッドを利用することができる。この発明の好ましい実装は移動電話機などの装置であり、装置は入力を提供する固定の枠組みを持たず、そのキーボードは（そのあり場所では）個定数の入力ボタンを持たない。この発明では、好ましくは装置製造会社により提供される中間ソフトウエア層は、汎用アプリケーションの設計者により提供されるコマンドリスト及び動作を処理し、それらを種々の入力機構に割り当て、スクリーンに表示する適切なメニューを構築する。アプリケーションが複数のウィンドウ、画面又はウィンドウ枠をサポートするところでは、中間層はフォーカスのあるアプリケーション部分を識別し、ユーザ入力に従って得られる動作を調整することができる。
【００３６】
ＵＩＱ（登録商標）ユーザインタフェース及びシンビアンＯＳ（登録商標）オペレーティングシステムを使用して本発明を実行するためのコードの例は、以下の通りでありうる。
// QCpfManager.h
//
// Copyright (c) Symbian Software Ltd 2004. All rights reserved.
// Created for UIQ 3.0
#ifndef QCPFMANAGER_H #define QCPFMANAGER H
#include ＜e32base.h＞
#include ＜coemain.h＞
class CQikAppUi;
class CEikonEnv;
class CCoeControl;
class CQCpfCommand;
class MQCpfControl;
class MQCpfControlOwner;
class CQCpfCommandList;
class MQCpfCommandListOwner;
class CQCpfCommandModel;
/**
@publishedAll
@prototype
The facade class of the Command Processing Framework.
（コマンド処理フレームワークＣＰＦのfacadeクラス）
*/
class CQCpfManager : public CCoeStatic, public MCoeFocusObserver
{
public:
/**
* Reasons for panic in CpfCtl
*/
enum TCpfPanic
{
ECpfIllegalControlPriority = 1,
ECpfCommandModeINotFound,
ECpfInva1idCommandType,
ECpfNoDefaultCommandList
};
public:
IMPORT_C static CQCpfManager* StaticL
(CQikAppUi& aAppUi, CEikonEnv& aEnv) ;
IMP0RT_C static CQCpfManager* Static();
IMPORT_C -CQCpfManager();
// Methods for initialize and cleanup
（初期化及びクリーンアップ処理のメソッド）
IMPORT_C void InitializeResourcesForL
(CCoeControl& aStackedControl) ;
IMPORT_C void InitializeResourcesForL
(CCoeControl& aStackedControl, MQCpfControlOwner* aCustomCpfControlOwner) ;
IMPORT_C Tint ResetAndDestroyResourcesFor (CCoeControl& aStackedControl) ;
// Methods that work on all screenmodes
（全てのスクリーンモードで機能するメソッド）
IMPORT_C void AddCommandModelListL
(CCoeControl& aCpfUser, MQCpfCommandListOwner& aOwner, Tint aCpfCmdMdlListResourceld) ;
IMP0RT_C void SetDimmed
(CCoeControl& aCpfUser, Tint aCommandld, TBool aBool) ;
IMPORT_C void SetChecked
(CCoeControl& aCpfUser, Tint aCommandld, TBool aBool) ;
IMP0RT_C void SetRadioed
(CCoeControl& aCpfUser, Tint aCommandld, TBool aBool) ;
IMPORT_C void Setlnvisible
(CCoeControlk aCpfUser, Tint aCommandld, TBool aBool) ;
// Methods that operates on one specific screenmode
（特定のスクリーンモードで動作するメソッド）
IMPORT_C void AddCommandListL
(CCoeControl& aCpfUser, MQCpfCommandListOwner& aOwner, Tint aResourceld, Tint aScreenMode=0) ;
IMP0RT_C void DeleteCommandList
(CCoeControl& aCpfUser, Tint aResourceld, Tint aScreenMode=0) ;
IMPORT_C void AddCommandL
(CCoeControl& aCpfUser, CQCpfCommand* aCommand, Tint aScreenMode=0) ;
IMPORT_C Tint DeleteCommand
(CCoeControl& aCpfUser, Tint aCommandld, Tint aScreenMode=0) ;
IMPORT_C void InvalidateL() ;
IMPORT_C CQCpfCommand* Command
(CCoeControl& aCpfUser, Tint aCommandld, Tint aScreenMode=0) ;
// Methods primarily intended for dynamic reordering of
// menuitems for a specific screenmode
（特定のスクリーンモード用のメニューアイテムを動的に並び替えることを目的とする第１のメソッド）
IMPORT_C CQCpfCommand* Remove
(CCoeControl& aCpfUser, Tint aCommandld, Tint aScreenMode=0) ;
IMP0RT_C Tint InsertCommandBefore
(CCoeControl& aCpfUser, Tint aCommandld, CQCpfCommand* aCommand, Tint aScreenMode=0) ;
IMPORT_C Tint InsertCommandAfter
(CCoeControlk aCpfUser, Tint aCommandld, CQCpfCommand* aCommand, Tint aScreenMode=0) ;
IMP0RT_C void SortCommands
(CCoeControl& aCpfUser, Tint aScreenMode=0) ;
// Internal methods（内部メソッド）
RPointerArray＜MQCpfControl＞& StandardCpfControls () ;
static Tint CompareCpfControls
(const MQCpfControl& aCtrl, const MQCpfControlk aCtrl2) ;
void SetTypeSortOrder(CQCpfCommand& aCmd) ;
CQikAppUi& AppUi () ;
private:
CQCpfManager() ;
CQCpfManager(CQikAppUi& aApp?i, CEikonEnv& aEnv) ;
void ConstructL() ;
const Tint Index(CCoeControlSc aCpfUser)/*const*/;
CQCpfCommandModel* LookupCommandModelL(CCoeControlSc aCpfUser) ;
void Dolnvalidate() ;
void SetupFromResourceL() ;
void RegisterStandardCpfControlsL() ;
private:    // from MCoeFocusObserver
void HandleChangelnFocus () ;
void HandleDestructionOfFocusedltemO ;
private:
/**
The array of CommandModels used by the application.
Sorted on the address of the owner/user to enable fast check
if a CCoeControl has a CommandModel or not.
（アプリケーションで使用されるCommandModelsの配列
この配列は、CCoeControlがCommandModelを保持しているか否かを
高速にチェックさせるために、オーナ／ユーザのアドレスにソートされる）
*/
RPointerArray＜CQCpfCommandModel＞ iCommandModels;
/**
Store a pointer the currently top focused control
(on appui's control stack) . Change of top focused
control usually indicate that another CommandModel
shall become the active CommandModel.
（現在、最上位のフォーカスされた制御部品
（アプリの制御スタック上で）のポインタを格納）
*/
CCoeControl* iCurrentlyTopFocusedControl;
/**
A reference to the control environment supplied at construction.
To avoid use of the slower CEikonEvn::Static() retrieval.
（構造体で提供される制御環境値への参照
遅いCEikonEvn::Static()での検索の使用を避けるため）
*/
CEikonEnvk iEnv;
/**
A reference to the AppUi supplied at construction.
To avoid use of the slower CEikonEvn::Static() retrieval.
（構造体で提供されるAppUiへの参照
遅いCEikonEvn::Static()での検索の使用を避けるため）
*/
CQikAppUi& iAppUi;
class CInvalidateEvent;
friend class CInvalidateEvent;
CInvalidateEvent* iOutstandinglnvalidate;
RArray＜TInt＞ iCmdTypeSortOrder;
/**
Array of the standard cpfcontrols like menucontrol and
softkeys.
（メニュー制御部品やソフトキーのような標準ＣＰＦ制御部品の配列）
*/
RPointerArray＜MQCpfControl＞ iStandardCpfControls;
};
#endif // QCPFMANAGER_H
本発明について特定の実施形態を参照して説明したが、当然変形については、添付の特許請求の範囲により規定される本発明の範囲内で、行うことができる。
【図面の簡単な説明】
【００３７】
【図１】移動電話機形式の計算装置のためのスクリーン制御部品とアプリケーションコマンドリストとの間の関係を示す図である。
【図２】アプリケーションコマンドリストの一例を示す図である。
【図３】２つのソフトキー及び戻りキーを有する装置において利用可能な入力メソッドにアプリケーションコマンドを対応付けるためのコマンド処理フレームワーク（ＣＰＦ）の使用方法を示す図である。
【図４】２つのソフトキー及び戻りキーを有する装置における利用可能な入力メソッドへのアプリケーションコマンドのＣＰＦによる対応付け方法を示す図である。
【図５】タッチスクリーンベースの入力機構を有する装置における利用可能な入力メソッドへのアプリケーションコマンドのＣＰＦによる対応付け方法を示す図である。
【図６】３つのソフトキー及び戻りキーを有する装置における利用可能な入力メソッドへのアプリケーションコマンドのＣＰＦによる対応付け方法を示す図である。
【図７】装置におけるキー及び制御部品へのアプリケーションコマンドの割り当て方法を示す図である。
【図８】タッチスクリーンベースの入力機構を有する装置におけるコマンドの宛先を特定するためのアプリケーション・コマンドタイプの使用方法を示す図である。
【図１】
2008504623.tif 000003
【図２】
2008504623.tif 000004
【図３】
2008504623.tif 000005
【図４】
2008504623.tif 000006
【図５】
2008504623.tif 000007
【図６】
2008504623.tif 000008
【図７】
2008504623.tif 000009
【図８】
2008504623.tif 000010
【国際調査報告】
2008504623.tif 000011
2008504623.tif 000012
2008504623.tif 000013