(57)【要約】【課題】  ３２ｂｉｔアプリケーションプログラムが呼び出す６４ｂｉｔプリンタードライバーにおいて、３２ｂｉｔアプリケーションプログラムのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成するプリンタードライバーを提供する。【解決手段】  ３２ｂｉｔアプリケーションは３２ｂｉｔアプリケーションのウィンドウハンドルをオペレーティングシステムが提供するＡＰＩを介して６４ｂｉｔプリンタードライバーに通知し、６４ｂｉｔプリンタードライバーは新規６４ｂｉｔプロセスを生成し、３２ｂｉｔアプリケーションのウィンドウハンドルを新規６４ｂｉｔプロセスに通知し、新規６４ｂｉｔプロセスは通知された３２ｂｉｔアプリケーションのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する。【選択図】  図５
2012146240.tif 000002
【特許請求の範囲】
【請求項１】
６４ｂｉｔオペレーティングシステム上で動作する３２ｂｉｔアプリケーションと６４ｂｉｔプリンタードライバー間のデータ通信方法において、前記３２ｂｉｔアプリケーションは前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記オペレーティングシステムが提供するＡＰＩを介して前記６４ｂｉｔプリンタードライバーに通知する工程を有し、前記６４ｂｉｔプリンタードライバーが新規６４ｂｉｔプロセスを生成し、前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記新規６４ｂｉｔプロセスに通知する工程を有し、前記新規６４ｂｉｔプロセスは通知された前記３２ｂｉｔアプリケーションのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する工程を有することを特徴とするアプリケーションとプリンタードライバーのデータ通信方法。
【請求項２】
前記３２ｂｉｔアプリケーションと前記６４ｂｉｔプリンタードライバーは独立したプロセスで動作し、前記６４ｂｉｔプリンタードライバーはｓｐｌｗｏｗ６４プロセスで動作することを特徴とする請求項1に記載のデータ通信方法。
【請求項３】
前記６４ｂｉｔプリンタードライバーは名前付きオブジェクトを生成し、少なくとも前記名前付きオブジェクトの名前あるいは名前を生成するための名前情報を前記新規６４ｂｉｔプロセスに通知する工程と、前記６４ｂｉｔプリンタードライバーは前記名前付きオブジェクトに格納された前記返却値を参照する工程と、前記新規６４ｂｉｔプロセスの処理の終了通知を受信する工程と、前記新規６４ｂｉｔプロセスは前記６４ｂｉｔプリンタードライバーに処理終了を通知する工程を有することを特徴とする請求項１に記載のデータ通信方法。
【請求項４】
前記名前付きオブジェクトは名前付き共有メモリであり、前記ＯＳが提供するＡＰＩはＥｘｔＥｓｃａｐｅ関数であることを特徴とする請求項３に記載のデータ通信方法。
【請求項５】
前記新規６４ｂｉｔプロセスはｒｕｎｄｌｌ３２プロセスであることを特徴とする請求項１に記載のデータ通信方法。
【請求項６】
前記新規６４ｂｉｔプロセスの処理の終了通知を受信する工程は、サブスレッドを作成
し、サブスレッド内でイベント名称から作成されたイベントが終了されたかどうかを見張る工程を有し、前記新規６４ｂｉｔプロセスは前記６４ｂｉｔプリンタードライバーに処理終了を通知する工程は、イベント名称からイベントの終了を発行する工程を有する請求項３に記載のデータ通信方法。
【請求項７】
６４ｂｉｔオペレーティングシステム上で動作する３２ｂｉｔアプリケーションと６４ｂｉｔプリンタードライバー間のデータ通信において、前記３２ｂｉｔアプリケーションは前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記オペレーティングシステムが提供するＡＰＩを介して前記６４ｂｉｔプリンタードライバーに通知する手段を有し、前記６４ｂｉｔプリンタードライバーが新規６４ｂｉｔプロセスを生成し、前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記新規６４ｂｉｔプロセスに通知する手段を有し、前記新規６４ｂｉｔプロセスは通知された前記３２ｂｉｔアプリケーションのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する手段を有することを特徴とするアプリケーションとプリンタードライバーのデータ処理装置。
【請求項８】
６４ｂｉｔオペレーティングシステム上で動作する３２ｂｉｔアプリケーションと６４ｂｉｔプリンタードライバー間のデータ通信方法において、前記３２ｂｉｔアプリケーションは前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記オペレーティングシステムが提供するＡＰＩを介して前記６４ｂｉｔプリンタードライバーに通知する手順と、前記６４ｂｉｔプリンタードライバーが新規６４ｂｉｔプロセスを生成し、前記６４ｂｉｔアプリケーションのウィンドウハンドルを前記新規６４ｂｉｔプロセスに通知する手順と、前記新規６４ｂｉｔプロセスは通知された前記３２ｂｉｔアプリケーションのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する手順とをコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
アプリケーションプログラムと、プリンタードライバーとプリンタードライバーによって生成される新規プロセスの間でのデータ通信方法及びプログラムに関する。
【背景技術】
【０００２】
印刷を行うアプリケーションプログラムは、一般的にオペレーティングシステム（以下ＯＳと略す）が提供するＡＰＩを介して、プリンターの印刷に関わる様々な情報を取得し、その情報に基づいて印刷設定の通知を行ったり、プリンター機能の実行を行う。
【０００３】
Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフト社）においてアプリケーションプログラムがこれらのプリンターの印刷に関わる様々な情報を取得し、その情報に基づいて印刷設定の通知を行ったり、プリンター機能の実行を行う従来の手法としては、アプリケーションプログラムがＥｘｔＥｓｃａｐｅ関数というＡＰＩを利用するという技術が一般的である（特許文献１参照）。
【０００４】
このＥｘｔＥｓｃａｐｅ関数を利用する技術は、アプリケーションプログラムとプリンタードライバーとの間で独自のデータの受け渡しを行い、アプリケーションからプリンタードライバーで用意されている機能を呼び出すといった目的で用いられる。
【０００５】
例えば、プリンタードライバーが独自の画像処理を行う為のインターフェースを備えているかどうかをアプリケーションプログラムが確認し、サポートされていれば独自の画像処理の設定を行うために、アプリケーションプログラムからプリンタードライバーに用意されている設定/実行機能ダイアログを表示するという様な処理を行う際にＥｘｔＥｓｃａｐｅ関数が使用されている。
【０００６】
もう1つ例を挙げれば、アプリケーションプログラムがプリンターのヘッドクリーニングを行う機能がサポートされているかの情報を確認し、サポートされていればプリンタードライバーで用意されているヘッドクリーニング機能の設定/実行機能ダイアログを表示させ、ヘッドクリーニングを実行させるといった際にも使用される。
【０００７】
Ｗｉｎｄｏｗｓ（登録商標）には、３２ｂｉｔ版ＯＳと６４ｂｉｔ版ＯＳが存在しており、プリンタードライバーはＯＳと密接に動作する為、３２ｂｉｔ版ＯＳには３２ｂｉｔプリンタードライバー、６４ｂｉｔ版ＯＳには６４ｂｉｔ版プリンタードライバーが用いられる。また、Ｗｉｎｄｏｗｓ（登録商標）のプリンタードライバーにはＧＤＩプリンタードライバーとＸＰＳプリンタードライバーという２種類のドライバが存在するが、それらのＯＳ環境、プリンタードライバーの種類に関わらず、アプリケーションプログラムがベンダー独自情報を取得し、プリンタードライバーの機能を実行することが可能な手法が従来の方法の中で示されてきた。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−１４０２８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に代表される従来の方法では、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムが６４ｂｉｔプリンタードライバーに対して、プリンターの印刷に関わる様々な情報を取得し、その情報に基づいて印刷設定の通知を行ったり、機能の実行を行うことができないという問題があった。具体的には、従来の手法では３２ｂｉｔアプリケーションプログラムが６４ｂｉｔプリンタードライバーに用意されている設定/実行機能ダイアログを表示させることができない問題が考慮されていない。例えば、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムが６４ｂｉｔプリンタードライバーに対して、プリンタードライバーで用意されているヘッドクリーニング機能の実行ダイアログを、３２ｂｉｔアプリケーションプログラムを親ウィンドウに指定して表示させることができない。
【００１０】
表示できない理由は、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムからＥｘｔＥｓｃａｐｅ関数を用いて６４ｂｉｔプリンタードライバーでデータの受け渡しを行う際、６４ｂｉｔプリンタードライバーは３２ｂｉｔアプリケーションプログラムとは別のｓｐｌｗｏｗ６４プロセスというプロセスで動作するが、このｓｐｌｗｏｗ６４プロセスで３２ｂｉｔウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを表示できないというＯＳ制限があるためである。
【００１１】
このＯＳ制限を回避するために、３２ｂｉｔアプリケーションプログラムのウィンドウハンドルを親ウィンドウハンドルに指定せずに、別のウィンドウハンドル、例えばデスクトップウィンドウハンドルを親ウィンドウハンドルに指定する方法も考えられるが、それではアプリケーションダイアログの裏側にダイアログが表示される可能性がある。また、プリンタードライバー機能のダイアログを表示しながら、アプリケーションダイアログも動作可能の状態(一般的にモードレスダイアログと呼ばれる)となる問題も発生することになる。モードレスダイアログで動作すれば、アプリケーションプログラムからあるプリンタードライバーの機能が実行されている最中に、アプリケーションプログラムから別のプリンタードライバーの機能が実行されるといった問題が発生するため好ましくない。例えば、ヘッドの位置調整機能の処理最中に、ヘッドのクリーニング機能が実行されるといったような、プリンタードライバーの仕様として想定外の動作とならないように振舞われるべきである。そのために、アプリケーションプログラムのウィンドウハンドルを親ウィンドウハンドルに指定して、アプリケーションプログラムからプリンタードライバーに用意されている設定/実行ダイアログが表示されている場合には、アプリケーションダイアログは動作できないようにする(一般的にモーダルダイアログと呼ばれる)ことが望ましい。
【００１２】
本発明は上記課題を解決するためになされたもので、３２ｂｉｔアプリケーションプログラムが、３２ｂｉｔアプリケーションプログラムのウィンドウハンドルを親ウィンドウハンドルに指定し、６４ｂｉｔプリンタードライバーに用意されている設定/実行機能ダイアログを表示させることができるようにすることを目的とする。そして、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムが６４ｂｉｔプリンタードライバーに対して、プリンターの印刷に関わる様々な情報を取得し、その情報に基づいて印刷設定の通知を行ったり、機能の実行を行うことができる手段を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上述のような課題を解決するため本発明の情報処理システムは以下の構成からなる。
【００１４】
６４ｂｉｔオペレーティングシステム上で動作する３２ｂｉｔアプリケーションと６４ｂｉｔプリンタードライバー間のデータ通信方法において、前記６４ｂｉｔアプリケーションは前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記ＯＳが提供するＡＰＩを介して前記６４ｂｉｔプリンタードライバーに通知する工程を有し、前記６４ｂｉｔプリンタードライバーが新規６４ｂｉｔプロセスを生成し、前記３２ｂｉｔアプリケーションのウィンドウハンドルを前記新規６４ｂｉｔプロセスに通知する工程を有し、前記新規６４ｂｉｔプロセスは通知された前記３２ｂｉｔアプリケーションのウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する工程を有することを特徴とするアプリケーションとプリンタードライバーのデータ通信方法。
【発明の効果】
【００１５】
本発明によれば、３２ｂｉｔアプリケーションプログラムが、３２ｂｉｔアプリケーションプログラムのウィンドウハンドルを親ウィンドウハンドルに指定し、６４ｂｉｔプリンタードライバーに用意されている設定/実行機能ダイアログを表示させることを可能とする効果を奏する。そして、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムが６４ｂｉｔプリンタードライバーに対して、プリンターの印刷に関わる様々な情報を取得し、その情報に基づいて印刷設定の通知を行ったり、機能の実行を行うことができる手段を提供することを可能とする効果を奏する。
【図面の簡単な説明】
【００１６】
【図１】画像処理装置の構成例を示すブロック図
【図２（ａ）】ＧＤＩプリンタードライバー内のモジュールと処理フローを示す図
【図２（ｂ）】ＸＰＳプリンタードライバー内のモジュールと処理フローを示す図
【図３】アプリケーションプログラムがＥｘｔＥｓｃａｐｅ関数を呼び出した時のプリンタードライバーの処理の流れを説明する為の模式図
【図４】プリンタードライバーに用意されている設定及び実行をユーザが行う際に表示される設定実行ダイアログの一例
【図５】全体処理のタイミングチャート一例
【図６】名前付き共有メモリに格納されるデータの構造の模式図
【図７】サブスレッド処理のフローチャート
【図８】ＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数の処理のフローチャート
【図９】イベント終了監視処理のフローチャート
【発明を実施するための形態】
【００１７】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１８】
図１は画像処理装置の構成例を示した図である。
【００１９】
ホストコンピュータ１００には、インクジェットプリンタなどのプリンター１０４が接続されている。
【００２０】
ホストコンピュータ１００は、ワードプロセッサ、表計算、インターネットブラウザなどのアプリケーションプログラム１０１を有する。印刷を行う場合、アプリケーションプログラム１０１によって発行される出力画像を示す各種描画処理命令群（イメージ描画命令、テキスト描画命令およびグラフィクス描画命令）は、オペレーティングシステム(ＯＳ)１０２を介して、プリンタードライバー１０３へ入力される。プリンタードライバー１０３は、それら描画命令群を処理して印刷データを作成しプリンター１０４に印刷させるソフトウェアである。
【００２１】
ホストコンピュータ１００は、上記のソフトウェアはＨＤＤ１０５、またはＲＯＭ１０８に記憶されておりＲＡＭ１０７に読み出されて、ＣＰＵ１０６に実行される。なお、図１に示すホストコンピュータ１００として一般に普及しているIBM AT互換機のパーソナルコンピュータを使用し、ＯＳ１０２としてMicrosoft社の Windows(登録商標)を使用することを想定する。そして、そのようなパーソナルコンピュータに、印刷機能を有する任意のアプリケーションプログラム１０１をインストールし、プリンター１０４を接続した形態を想定する。
【００２２】
ホストコンピュータ１００では、アプリケーションプログラム１０１により、文字などのテキストに分類されるテキストデータ、図形などのグラフィクスに分類されるグラフィクスデータ、写真画像などに分類されるイメージ画像データなどを用いて出力画像データが作成される。そして、出力画像データに基づく画像を印刷する場合、アプリケーションプログラム１０１は、ＯＳ１０２に印刷出力要求を行い、テキストデータ部はテキスト描画命令、グラフィクスデータ部分はグラフィクス描画命令、イメージ画像データ部分はイメージ描画命令で構成される描画命令群をＯＳ１０２に発行する。
【００２３】
ＯＳ１０２はアプリケーションプログラム１０１から印刷出力要求を受けると、プリンタードライバー１０３に描画命令群を渡す。プリンタードライバー１０３はＯＳ１０２から渡される印刷出力要求および描画命令群を処理して、プリンター１０４が印刷処理可能な印刷データを作成し、その印刷データをプリンター１０４に送る。ホストコンピュータ１００とプリンター１０４は例えばUSB（Universal Serial Bus）のような双方向通信が可能なインターフェースにより接続される。
【００２４】
次に、図２は本発明の実施形態における印刷システムのソフトウェア（主にプリンタードライバー）の構成を示すブロック図である。
【００２５】
まず、図２（a）に示すＧＤＩプリンタードライバーの構成について説明する。アプリケーションプログラム１０１は文書を作成し、その文書を印刷するためにユーザーインターフェースモジュール２０３にプリンタシステムの機能を問い合わせた後、ＯＳの印刷サービス２０２を含む印刷システムに印刷開始を通知する。ここでＯＳの印刷サービス２０２は、アプリケーションプログラム１０１から印刷開始の通知を受けると、ユーザーインターフェースモジュール２０３にアプリケーションプログラム１０１による印刷開始の印刷イベントを通知する。続いてアプリケーションプログラム１０１は印刷対象の文書の印刷データをＯＳの印刷サービス２０２に供給し印刷処理を続行する。ＯＳの印刷サービス２０２を経由した印刷データはスプールファイル２０４に格納される。プリントプロセッサ２０５は、スプールファイル２０４から印刷データを読み出し、その印刷データはレンダリングモジュール２０６を介した後、ランゲージモニタ２０７に送られる。ランゲージモニタ２０７は、プリンター１０４と双方向通信を行いながら、印刷データをプリンター１０４へと送信する。ランゲージモニタ２０７は随時、プリンター１０４が保持しているステータスの情報を受信する。またランゲージモニタ２０７は、プリンター１０４から受信した情報や送信する印刷データを元に、現在のプリンターや印刷の状況をステータスモニタ２０８に伝える。ステータスモニタ２０８は、プリンターや印刷の状況を表示するのみでなく、何らかの理由により印刷が中断されている場合は、対処選択肢をユーザに提示し、それに対するユーザからのレスポンス入力を受け取り、ランゲージモニタ２０７に伝達する。上記のソフトウェアはＨＤＤ１０５、またはＲＯＭ１０８に記憶されておりＲＡＭ１０７に読み出されて、ＣＰＵ１０６に実行される。
【００２６】
次に、図２（ｂ）に示すもう一方のプリンタードライバー(ＸＰＳプリンタードライバー) の構成について説明する。アプリケーションプログラム１０１からＯＳの印刷サービス２０２を介してユーザーインターフェースモジュール２０３を呼び出すことで、印刷に関する各種設定をユーザに行わせることができる。アプリケーションプログラム１０１からユーザ操作により印刷指示がなされると、その指示内容はＯＳの印刷サービス２０２に送られる。具体的には仮想化された印刷領域であるＤＣ（Ｄｅｖｉｃｅ  Ｃｏｎｔｅｘｔ）が作成され、アプリケーションプログラム１０１へ供給される。そして、アプリケーションプログラム１０１により文書データの描画処理がＤＣに対して行われる。描画内容はＭＸＤＣ２１１によりＸＰＳ形式に変換され、その結果、ＸＰＳ形式の印刷データが生成される。ＸＰＳ形式の印刷データは、ＯＳの印刷サービス２０２によって、印刷ジョブ毎にスプールファイル２１２として一時的に記憶装置にスプールされる。ここで、ＸＰＳ形式の電子文書を作成することができるアプリケーションプログラムの場合は、ＸＰＳ形式の印刷データをスプールすることも可能である。
【００２７】
スプールファイル２１２に格納されたデータはＯＳの印刷パイプラインサービス２１３により呼び出されたフィルターパイプライン２１４に供給される。フィルターパイプライン２１４は、図示しないＸＰＳプリンタードライバーのパイプライン構成ファイルに記述されている任意の数のフィルターによって構成される。プリンター１０４が解釈可能な印刷コマンドがＸＰＳ形式では無い場合、少なくとも、スプールされたＸＰＳ形式のデータを印刷コマンドに変換する為のフィルターが必要となる。図２（b）ではフィルターパイプライン２１４はレイアウトフィルター２１５とレンダーフィルター２１６で構成される。レイアウトフィルター２１５はスプールファイルからＸＰＳ形式の印刷データを取得し、印刷設定に基づき必要に応じ印刷データを編集し出力する。印刷データを加工する必要が無い場合は、取得した印刷データをそのまま出力する。レイアウトフィルター２１５の出力は、レンダーフィルター２１６に供給される。レンダーフィルター２１６は、供給されたＸＰＳ形式の印刷データの各ページのレンダリング処理を行い、必要な画像処理を行ったうえで、印刷コマンドに変換して出力する。レンダーフィルター２１６が出力した印刷コマンドはプリンター１０４に供給され、プリンター１０４が印刷動作を実行する。
【００２８】
次にＯＳが提供するＡＰＩであるＥｘｔＥｓｃａｐｅ関数の動作の一例を図３に示す。ＥｘｔＥｓｃａｐｅ関数を利用することにより、アプリケーションプログラム１０１とプリンタードライバーはデータの受け渡しを行うことができる。ＯＳの印刷サポート機能３０１はＯＳにより提供される機能であり、アプリケーションプログラム１０１が呼び出したＡＰＩ関数の処理を行い、必要に応じてプリンタードライバーを呼び出す機能を有する。ユーザーインターフェースモジュール２０３とレンダリングモジュール２０６はプリンタードライバーを構成するモジュール群に含まれる。ユーザーインターフェースモジュール２０３は、印刷に関する各種項目の設定をユーザに行わせ、印刷設定を作成する機能やプリンターのメンテナンス機能(例えばヘッドクリーニングなど)を実行するためのユーティリティ機能を有する。レンダリングモジュール２０６は、アプリケーションプログラム１０１の描画指示を、画像に変換したり、あるいは、ページ記述言語に変換したりする機能を有する。
【００２９】
アプリケーションプログラム１０１は、例えば画像処理、ユーティリティ機能といった機能に関する情報を得る為や実行機能を呼ぶ出す為に、ＥｘｔＥｓｃａｐｅ関数の引数に、ベンダー独自のＥｓｃａｐｅコードを指定する。また、同時に、後述するＥｓｃａｐｅ処理に必要なデータをＥｘｔＥｓｃａｐｅ関数の引数で渡す。アプリケーションプログラム１０１がＥｘｔＥｓｃａｐｅ関数を呼び出すと、ＯＳの印刷サポート機能３０１は、プリンタードライバーのユーザーインターフェースモジュール２０３のＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数３１３を呼び出す。ＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数３１３はアプリケーションプログラム１０１がＥｘｔＥｓｃａｐｅ関数を呼び出した時の引数を参照することができ、引数に応じた処理を行う。ＧＤＩプリンタードライバーの場合、ＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数３１３の処理が終了すると、ＯＳの印刷サポート機能３０１は、プリンタードライバーのレンダリングモジュール２０６のＤｒｖＥｓｃａｐｅ関数３２３を呼び出す。ＤｒｖＥｓｃａｐｅ関数３２３はアプリケーションプログラム１０１がＥｘｔＥｓｃａｐｅ関数を呼び出した時の引数を参照することができる。ＤｒｖＥｓｃａｐｅ関数３２３は引数に応じた処理を行い、返却データを生成することができる。Ｅｓｃａｐｅ処理部３２３により生成された返却データは、ＯＳの印刷サポート機能３０１を介してアプリケーションプログラム１０１に返却される。ＸＰＳプリンタードライバーの場合、ＭＸＤＣ２１１のＤｒｖＥｓｃａｐｅ関数３２３が呼び出される。ＭＸＤＣ２１１はマイクロソフト社により提供されているため、ベンダー独自で定めたＥｓｃａｐｅコードは未知のＥｓｃａｐｅコードとして処理される。従って、ＧＤＩプリンタードライバーとは異なり、ＭＸＤＣ２１１ではベンダー独自で定めたＥｘｔＥｓｃａｐｅ関数の処理はできないということになる。
【００３０】
プリンタードライバーは一般的に、３２ｂｉｔＷｉｎｄｏｗｓ（登録商標）上の３２ｂｉｔアプリケーションプログラム、或いは６４ｂｉｔＷｉｎｄｏｗｓ（登録商標）上の６４ｂｉｔアプリケケーションプログラムがＥｘｔＥｓｃａｐｅ関数を呼び出した場合、アプリケーションプログラムと同一プロセスで動作する。一方、６４ｂｉｔＷｉｎｄｏｗｓ（登録商標）上の３２ｂｉｔアプリケーションプログラムがＥｘｔＥｓｃａｐｅ関数を呼び出した場合、６４ｂｉｔプリンタードライバーはアプリケーションプログラムの３２ｂｉｔプロセスとは異なるｓｐｌｗｏｗ６４プロセスで動作する。
【００３１】
＜実施形態１＞
ここから実際に本発明の動作説明に移る。
【００３２】
(設定/実行機能ダイアログ)
まず、ユーザーインターフェースモジュール２０３がユーザに提供する設定/実行機能ダイアログについて説明する。図４はヘッドのクリーニング機能を実行するための設定/実行機能ダイアログ表示例である。クリーニング設定/実行機能ダイアログ４０１は表示エリア４１１〜４２２で構成される。
【００３３】
まずユーザは、クリーニングを実行するヘッドを選択する。ブラックのヘッドをクリーニングしたい場合はチェックボックス４２１、カラーのヘッドをクリーニングしたい場合はチェックボックス４２２をそれぞれチェックオンする。ヘッドを選択後、クリーニングを実行したい場合は、実行ボタン４１１をクリックすることで、クリーニングが実行される。キャンセルボタン４１２を押せばクリーニングを実行せずにクリーニング設定/実行機能ダイアログ４０１を閉じることができる。ヘルプボタン４１３はクリーニング設定/実行機能ダイアログ４０１の各設定項目に関する説明文を別ウィンドウで表示させることができる。
【００３４】
本提案では、この様な通常はプリンタードライバーから実行される設定/実行機能ダイアログを、アプリケーションプログラムから呼び出し実行させることを目的としている。
【００３５】
(全体処理フロー)
次に、６４ｂｉｔＯＳで動作する３２ｂｉｔアプリケーションプログラムがＥｘｔＥｓｃａｐｅ関数を用いて、６４ｂｉｔプリンタードライバーに対して、印刷設定の通知や、機能の実行を行う全体の処理の流れについて説明する。図５は名前付き共有メモリ、新規６４ｂｉｔプロセス(６４ｂｉｔｒｕｎｄｌｌ３２プロセス)、そしてＥｘｔＥｓｃａｐｅ関数を用いて、３２ｂｉｔアプリケーションプログラム１０１が６４ｂｉｔプリンタードライバーの設定/実行機能ダイアログを表示し、機能処理を行うタイミングチャートの一例である。
【００３６】
最初に、３２ｂｉｔアプリケーションプログラム１０１が、ベンダーが用意したサポートモジュール５０１を呼び出す(５０２)。このサポートモジュール５０１は、後に説明するユーザーインターフェースモジュール２０３の処理の終了を監視し、アプリケーションプログラム２０１の代わりにＥｘｔＥｓｃａｐｅ関数を呼び出す処理を行う目的で用意している。３２ｂｉｔアプリケーションプログラム１０１が、このサポートモジュール５０１を呼び出す際には、３２ｂｉｔアプリケーションプログラムのウィンドウハンドル、及びサポートモジュール５０１でＥｘｔＥｓｃａｐｅ関数を呼び出すために必要であるベンダー独自のＥｓｃａｐｅコードをＥｘｔＥｓｃａｐｅ関数の引数に指定しておく。
【００３７】
次に、呼び出されたサポートモジュール５０１が、ＥｘｔＥｓｃａｐｅ関数の処理結果を受け取るための準備処理を行う。ｓｐｌｗｏｗ６４プロセスで動作するユーザーインターフェースモジュール２０３は６４ｂｉｔｒｕｎｄｌｌ３２プロセスを生成後、６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理終了前に、３２ｂｉｔアプリケーションプログラム１０１まで制御を返却してしまうと、６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理結果を３２ｂｉｔアプリケーションプログラム１０１に返却できない。そのため、３２ｂｉｔアプリケーションプログラム１０１に６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理結果の返却を行うために、６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理終了前に制御を３２ｂｉｔアプリケーションプログラム１０１に返却させず処理結果をサポートモジュール５０１で受け取ることができるようする必要がある。そのために、サポートモジュール５０１で６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理終了を監視する。
【００３８】
監視する方法としては、サポートモジュール５０１がサブスレッドを作成し、作成したサブスレッド内で６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理の終了を監視する。サブスレッドを作成し、作成したサブスレッド内で処理終了を監視する理由は、サポートモジュール５０１が６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理終了を監視すると、そこで制御が常に奪われてしまう。制御が常に奪われると、３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルを親ウィンドウハンドルとしてダイアログを生成するメッセージが受信できず、ダイアログを表示できないという問題が生じる。この問題を回避するために、サブスレッドを作成し、作成したサブスレッド内で６４ｂｉｔｒｕｎｄｌｌ３２プロセスでの処理の終了を監視する。
【００３９】
ここからは、以上で説明したサポートモジュール５０１がＥｘｔＥｓｃａｐｅ関数の処理結果を受け取るための実際の準備処理を詳細に説明していく。サポートモジュール５０１はＥｘｔＥｓｃａｐｅの処理結果を格納するために用いる共有メモリを作成する（５０３）。具体的には、名前付き共有メモリの名称を決定し、決定した名称で名前付き共有メモリを作成する。次に、６４ｂｉｔｒｕｎｄｌｌ３２プロセスが６４ｂｉｔプリンタードライバーの印刷設定の通知や、機能の実行を行う処理の終了を知らせるイベント名称を決定し、イベントを作成する（５０４）。名前付き共有メモリの名称とイベント名称は、複数のアプリケーションプログラムからの実行を考慮に入れて、プロセスＩＤとスレッドＩＤ等を利用して一意の名称になるように決定することが望ましい。名前付き共有メモリの作成、イベントの作成を行った後、イベントの終了を監視するためのサブスレッドを作成する（５０５）。
【００４０】
サブスレッドは、ＯＳが提供しているＣｒｅａｔｅＴｈｒｅａｄというＡＰＩ関数を用いても良いし、またはウィンドウプロシージャを新たに作成する方法を用いても良い。また、その他方法を用いても当然構わない。サブスレッド内で３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルを引数に指定してＥｘｔＥｓｃａｐｅ関数呼び出しを行うことにより、６４ｂｉｔｓｐｌｗｏｗ６４プロセスで動作するユーザーインターフェースモジュール２０３のＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数の呼び出し（５０６）を行う。ＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数を呼び出されたユーザーインターフェースモジュール２０３は、印刷設定の通知や、機能の実行の処理を行わせるための、６４ｂｉｔｒｕｎｄｌｌ３２プロセスを生成する（５０７）。６４ｂｉｔｒｕｎｄｌｌ３２プロセスではＤＬＬファイルやＥＸＥファイルなどのファイルから任意の関数を指定して呼び出すことができる。ここでは、ユーザーインターフェースモジュール２０３のアプリケーションプログラム１０１から指定された実行すべき機能を呼び出すための関数を呼び出す。この際にも３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルを引数に指定しておく。ＧＤＩプリンタードライバーの場合、６４ｂｉｔｒｕｎｄｌｌ３２プロセスを生成後、次にレンダリングモジュール２０６のＤｒｖＥｓｃａｐｅ関数の呼び出しが行われる（５０８）。ここでは処理はなにも処理を行わず、制御をそのまま返却する（５０９）。ＸＰＳプリンタードライバーの場合、マイクロソフト社により提供されているＭＸＤＣ２１１のＤｒｖＥｓｃａｐｅ関数が呼び出されるため、ベンダー独自で定めたＥｘｔＥｓｃａｐｅ関数の処理はできないので、ＧＤＩプリンタードライバーと同様に何も処理を行わない。その後、６４ｂｉｔｒｕｎｄｌｌ３２プロセス上で動作するユーザーインターフェースモジュール２０３での処理の終了を監視する（５１０）。
【００４１】
監視する方法としては、５０４で作成したイベントの終了通知が発行されていないかを一定時間ごとに確認するポーリング処理を行う方法が一例として挙げられる。
一方、６４ｂｉｔｓｐｌｗｏｗ６４プロセスで動作するユーザーインターフェースモジュール２０３から呼び出された６４ｂｉｔｒｕｎｄｌｌ３２プロセス上で動作するユーザーインターフェースモジュール２０３は、指定された任意の関数の処理を行う。指定された機能の設定/実行ダイアログの表示を行い、ダイアログの処理結果に応じた機能処理を実行する（５１１）。なお、設定/実行ダイアログの表示する際には、３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルを親ウィンドウハンドルに指定してダイアログを生成する。ダイアログの表示を行うのは６４ｂｉｔｓｐｌｗｏｗ６４プロセスではなく、６４ｂｉｔｒｕｎｄｌｌ３２プロセスなので、ＯＳ制限に触れることなくダイアログを表示することができる。また、親ウィンドウハンドルを３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルに指定することで、ダイアログ表示中はアプリケーションダイアログを動作させることができないモーダルダイアログとして表示することを可能とする。処理終了後、名前付き共有メモリにアクセスを行い、処理結果を名前付き共有メモリに格納する（５１２）。格納後、イベント終了通知の発行を行い（５１３）、６４ｂｉｔｒｕｎｄｌｌ３２プロセスを終了する。
【００４２】
サポートモジュール５０１のサブスレッドは、監視処理によりイベント終了の発行がなされたことを確認すると、サブスレッドの破棄を行う（５１４）。サポートモジュール５０１は、ＥｘｔＥｓｃａｐｅ関数の処理結果(戻り値)は無視し、名前付き共有メモリにアクセスし、名前付き共有メモリ内の情報をＥｘｔＥｓｃａｐｅ関数の処理結果とする（５１５）。名前付きメモリを削除し（５１６）、３２ｂｉｔアプリケーションプログラム１０１に処理結果を返却する（５１７）。
【００４３】
（名前付き共有メモリに格納されるデータの構造）
次に名前付き共有メモリに格納されるデータの構造について説明する。図６は本実施例における名前付き共有メモリに格納されるデータの構造の一例を示す図である。名前付き共有メモリ６０１はメンバ６１１から６５１で構成される。
【００４４】
メンバ６１１は名前付き共有メモリ６０１のサイズを示す。メンバ６１３は名前付き共有メモリに利用者が付加するシグネチャである。このシグネチャはアプリケーションプログラムとプリンタードライバーが共通で識別出来るものにしておくと良い。
【００４５】
メンバ６１５は入力データの位置を示すオフセットであり、名前付き共有メモリ６０１の先頭からのバイト数などで表される。メンバ６１７は入力データのサイズであり、後述するメンバ６３１のサイズをバイト数等で表す。入力データについては後述する。
【００４６】
メンバ６１９は出力データの位置を示すオフセットであり、名前付き共有メモリ６０１の先頭からのバイト数などで表される。メンバ６２１は出力データのサイズであり、後述するメンバ６４１のサイズをバイト数等で表す。出力データについては後述する。
【００４７】
メンバ６２３は生成可否情報であり、ユーザーインターフェースモジュール２０３が情報の生成に成功したか否かを示す情報が格納される。
【００４８】
メンバ６３１は入力データであり、機能情報の種類等のアプリケーションプログラム１０１がプリンタードライバーに渡すデータが格納される。ここで、メンバ６３１の内容を細分化し、複数の項目を入力データとしてもよい。例えば、３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルや名前付きメモリにアクセスするための名称や、イベント名称といった複数の情報を格納することができる。
【００４９】
メンバ６４１は出力データであり、ユーザーインターフェースモジュール２０３が生成した情報が格納される。ここで、メンバ６４１の内容を細分化し、複数の項目を出力データとしてもよい。本件では、５１１の処理結果を格納するのに使用している。
【００５０】
メンバ６５１は名前付き共有メモリ６０１の未使用領域である。
【００５１】
（サポートモジュールのサブスレッド処理フロー）
サポートモジュール５０１で行われるサブスレッド処理の詳細を説明する。詳細な処理の流れを示した処理フローを図７に示す。サポートモジュール５０１はサブスレッド作成後、ＥｘｔＥｓｃａｐｅ関数の解釈を行い、ＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数を呼び出す（Ｓ７０１）。６４ｂｉｔｓｐｌｗｏｗ６４プロセスで動作するユーザーインターフェースモジュール２０３でのＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数処理後、ＤｒｖＥｓｃａｐｅ関数を呼び出す（Ｓ７０２）。その後、６４ｂｉｔｒｕｎｄｌｌ３２プロセスでのプリンタードライバーの印刷設定の通知や、機能の実行を行う処理の終了を監視する（Ｓ７０３）。処理終了確認後サブスレッドを破棄し（Ｓ７０４）、サブスレッド処理を終了する（Ｓ７０５）。
【００５２】
（ユーザーインターフェースモジュールのＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数の処理）
次に、ユーザーインターフェースモジュール２０３のＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数の処理について説明する。図８はＤｒｖＤｏｃｕｍｅｎｔＥｖｅｎｔ関数の処理のフローチャートの一例である。
【００５３】
まず、Ｓ８０１で処理を開始する。続いてＳ８０２で、通知されたイベントの種類がＥｓｃａｐｅイベントかどうかを判断し、ＥｓｃａｐｅイベントならＳ８０３に移り、Ｅｓｃａｐｅイベントで無ければＳ８１０に移る。Ｓ８０３ではＥｓｃａｐｅイベントで渡されたＥｓｃａｐｅコードがベンダー独自Ｅｓｃａｐｅコードかどうかを判断し、ベンダー独自ＥｓｃａｐｅコードであればＳ８０４に移り、ベンダー独自ＥｓｃａｐｅコードでなければＳ８０５に移る。Ｓ８０４では、プリンタードライバーの印刷設定の通知や、機能の実行を行う処理を行わせるために、６４ｂｉｔｒｕｎｄｌｌ３２プロセスを生成する。６４ｂｉｔｒｕｎｄｌｌ３２プロセスを生成する際に、ユーザーインターフェースモジュール２０３がユーザに提供する設定/実行機能ダイアログをモーダルダイアログで表示するために必要な３２ｂｉｔアプリケーションプログラム１０１のウィンドウハンドルを引数として渡す。Ｓ８１０ではＥｓｃａｐｅイベント以外の各種イベントに応じた処理を行い、Ｓ８０５に移る。Ｓ８１０の各種イベントと、イベントに応じた処理の内容は本発明に関連が無いため詳細は説明しない。最後にＳ８０５で処理を終了する。
【００５４】
（サポートモジュールのサブスレッド処理内のイベント終了監視処理）
次に、サポートモジュール５０１のサブスレッド処理内で行うイベント終了監視処理について説明する。図９はイベント終了監視処理のフローチャートの一例である。
【００５５】
まず、Ｓ９０１で処理を開始する。次に対象イベント、ここでは図５の５０４にて作成されたイベントの処理終了の通知が発行されたかどうか確認する（Ｓ９０２）。発行されていなければ、Ｓ９０３にて一定時間待機し、その後、Ｓ９０２のイベントの処理終了の通知の発行の確認に戻り、通知が発行されるまで繰り返す。Ｓ９０３の待機時間は、特に決められていないが、あまりに短いとＰＣの処理が遅くなるといった弊害も発生する可能性もある。逆にあまりに長いと、処理終了の通知の確認が即座に行われないといったこともある。待機時間はこれらのことを考慮しつつ、環境や状況に応じた適切な時間にすることが好ましい。Ｓ９０２にてイベントの終了通知の発行が確認されたならば、Ｓ９０４にてイベント終了監視処理を終了する。
【００５６】
＜実施形態２＞
本発明の目的は前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００５７】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【００５８】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。
【００５９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【００６０】
１０１  アプリケーションプログラム
１０２  ＯＳ
１０３  プリンタードライバー
２０３  ユーザーインターフェースモジュール
２０６  レンダリングモジュール
２１１  ＭＸＤＣ
３０１  ＯＳの印刷サポート機能
５０１  サポートモジュール
【図１】
2012146240.tif 000003
【図２（ａ）】
2012146240.tif 000004
【図２（ｂ）】
2012146240.tif 000005
【図３】
2012146240.tif 000006
【図４】
2012146240.tif 000007
【図５】
2012146240.tif 000008
【図６】
2012146240.tif 000009
【図７】
2012146240.tif 000010
【図８】
2012146240.tif 000011
【図９】
2012146240.tif 000012