JP3915876B2

JP3915876B2 - 文字列データの処理方法および処理装置

Info

Publication number: JP3915876B2
Application number: JP2000403300A
Authority: JP
Inventors: 順一大塚; 季之杉本
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 2000-12-28
Filing date: 2000-12-28
Publication date: 2007-05-16
Anticipated expiration: 2020-12-28
Also published as: US20020194073A1; CN1365046A; ATE299606T1; DE60111916D1; EP1220093A3; ES2243384T3; KR100600217B1; DE60111916T2; CN1149471C; HK1049048A1; JP2002202892A; KR20020055426A; EP1220093B1; US7055155B2; EP1220093A2

Description

【０００１】
【発明の属する技術分野】
本発明は、コンポーネント化されたオブジェクトソフトウェアを用いた処理方法およびシステムに関するものである。
【０００２】
【従来の技術】
オブジェクト指向プログラミングによるコンポーネントベースのプログラムあるいはソフトウェア（オブジェクト）は、オペレーティングシステム上で稼動する再利用可能なソフトウェアであり、オブジェクトを用いて多種多様なシステムが開発されている。たとえば、マイクロソフト社が提供するオペレーティングシステム（ＯＳ）であるウィンドウズ（登録商標）でサポートするＣＯＭ（コンポーネントオブジェクトモデル：Component Object Model）は、クライアントであるアプリケーションプログラム（コンテナアプリケーション）がオブジェクトを使用可能とする環境を提供する広範囲な機能を有するシステムである。
【０００３】
したがって、ＣＯＭで利用可能なオブジェクトによりシステム開発を行うと、ソフトウェアの部品化と再利用が容易になり、ユーザーがシステムを構築し、メンテナンスしていく費用を低減できる。また、既存のソフトウェア資産を継続あるいは承継できるので、システム開発も容易となり、それに伴う費用も削減できる。さらに、コンポーネントベースでオブジェクトが開発できるので、多種多様なサブシステムあるいは周辺装置により構成される複雑な構成のシステムの開発も容易になり、ネットワーク環境下で稼動するシステムの開発には欠かせないものとなっている。
【０００４】
ＰＯＳシステムは多種多様な周辺装置により組み立てられるシステムの１つであり、パーソナルコンピュータなどの中心となるホストコンピュータにディスプレイ、プリンタ、スキャナ、ドロワ、カードリーダなど様々な入出力装置が接続されることによりシステムが構築される。本願出願人は、特開平９−１０６３５５号などにより、オブジェクトを用い構築されたＰＯＳシステムであってパーソナルコンピュータベースのフレキシブルな構成のＰＯＳシステムについて開示している。
【０００５】
図１に、オブジェクト分散型のＰＯＳシステム１０の概要を示してある。このＰＯＳシステム１０は、各メーカが提供するＰＯＳアプリケーションプログラム１１と、プリンタ２１、スキャナ２２あるいはドロワ２３などの周辺装置（デバイス）の種類単位（デバイスクラス単位）に供給されるコントロールオブジェクト１２と、周辺装置毎、すなわち、デバイス毎に供給されるサービスオブジェクト１３とを備えている。したがって、ＰＯＳアプリケーションプログラム１１がプリンタ２１から出力するときは、データがプリンタのコントロールオブジェクト（ＣＯ）１２に渡され、さらに、出力するプリンタのメーカおよび機種に対応したサービスオブジェクト（ＳＯ）１３に渡され、ＯＳ１４を介してプリンタ２１に供給される。また、ＰＯＳアプリケーションプログラム１１は、ＯＳ１４を介してパーソナルコンピュータのハードウェア資源であるディスプレイ１５やキーボード１６も周辺装置として使用できるようになっている。
【０００６】
図１に示したＰＯＳシステム１０では、コントロールオブジェクト１２およびサービスオブジェクト１３を備えたオブジェクト制御システム１９がＰＯＳアプリケーションプログラム１１に対してプリンタ２１などの周辺機器に対して機種依存性のないインターフェイスを提供する。また、コントロールオブジェクト１２は周辺機器のデバイスクラス毎に開発されているので、その範囲でプログラム１１を実行するときにＯＳ１４にサポートされているＣＯＭによりインスタンスが形成され、プログラム１１にバインドされる。さらに、サービスオブジェクト１３はデバイス毎にコントロールオブジェクト１２に対してデバイスに依存しないユニホームなインターフェイスを提供しており、対応するデバイスがコントロールオブジェクト１２を介して呼ばれるとインスタンスが形成されてバインドされる。たとえば、マイクロソフト社のＣＯＭを基盤とするシステムであれば、コントロールオブジェクト１２としてはプログラム１１にイベントを返すことが可能なＡｃｔｉｖｅＸコントロール（ＯＬＥコントロール）を採用でき、サービスオブジェクト１３としてはＡｃｔｉｖｅＸコントロールに対してサーバとなるＡｃｔｉｖｅＸサーバ（ＯＬＥオートメーションサーバ）を採用できる。そして、オートメーションによりバインディングされたこれらのオブジェクト間、すなわちアプリケーションを実行するためにバインドされたオブジェクトのインスタンス間のデータ通信をＣＯＭがサポートしている。
【０００７】
オートメーションはＣＯＭのＩＤｉｓｐｔｃｈインターフェイスに依存しており、オブジェクト間の通信はＩｎｖｏｋｅというメソッドを実行することにより行われる。このため、オブジェクト指向のプログラミング言語であるマイクロソフト社が提供するＶｉｓｕａｌＣ++（以下ＶＣ++）（登録商標）によるＯＬＥオートメーション機能を用いたシステムの開発環境を提供するＭＦＣ（Microsoft Foundation Class Library）では、アプリケーションあるいはクライアント側のオブジェクトからＩｎｖｏｋｅ関数をコールする複雑さをカバーするためにCOleDispatchDriverと言うベースクラス（オブジェクト）が用意されている。したがって、クライアント側のオブジェクトは、このクラスから派生させたインターフェイスオブジェクトのメンバー関数であるＩｎｖｏｋｅＨｅｌｐｅｒをコールすることにより、サーバ側のオブジェクトに対しデータを転送することができる。
【０００８】
図２に、本例のＰＯＳシステム１０において、データが転送される様子を模式的に示してある。まず、アプリケーション１１はプリンタ２１で文字データを印刷するために、プリンタのコントロールオブジェクト１２の印刷を行うためのメソッドを呼んで文字データを渡す。コントロールオブジェクト１２は、プリンタ２１に対応したサービスオブジェクト１３のメソッドを呼ぶために、インターフェイスオブジェクト１８であるCOleDispatchDriverクラスのメンバー関数InvokeHelperを呼ぶ。そして、このインターフェイスオブジェクト１８を介してデータがサービスオブジェクト１３に転送され、ＯＳ１４を介してプリンタ２１により出力される。
【０００９】
【発明が解決しようとする課題】
しかしながら、このＰＯＳシステム１０において、バーコードデータのようにｎｕｌｌデータ（１６進「００」、以降においては文字列データは全て１６進で示す）が文字列データの途中に含まれる可能性があると、その文字列がプリンタ２１に再現されないという問題がある。たとえば、プリンタのコントロールオブジェクト１２はPrintBarCodeというメソッドを備えているが、そのDataパラメータに以下のデータ（16進表記）を指定した場合に次のようなプロセスでデータが受け渡しされてしまう。
【００１０】
アプリケーション１１で次の文字列データＡ０がコントロールオブジェクト１２に渡される。
Ａ０： 7B 41 00 30 31 32 33 34 35 36 37 38 39・・・（１）
コントロールオブジェクト１２では、文字列データＡ０を受け取るが、受け取る文字列データの形式は、ＬＰＣＴＳＴＲ型で宣言されている。ＬＰＣＴＳＴＲ型は、文字列の終端が「００」で定義された８ビットのＡＮＳＩ規格によるコードであり、さらにシフトＪＩＳで文字が定義される文字列データである。したがって、文字列中に「００」があることは許容されていない。バーコードのようにキャラクタではなくバイトデータを画像データとして印刷しようとしない場合は、印刷可能なキャラクタに「００」は含まれておらず、プリンタ用のオブジェクトにおいては文字列データの定義としてＬＰＣＴＳＴＲ型は一般的なものである。
【００１１】
一方、ＣＯＭの環境では、ＣＯＭがプログラム−オブジェクト間およびオブジェクト−オブジェクト間のデータ転送をサポートしており、ＣＯＭを介して文字列データを受け取るときは文字数データ付きの基本文字列データであるＢＳＴＲ型で渡されるので、以下のようなデータとなる。
Ａ１： 0D 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00
・・・（２）
ＢＳＴＲ型の文字列データは、先頭の４バイトにはデータの長さの情報が格納され、文字列データの最後（文字数には含まれない）が「００」で終了するデータである。そして、ポインタからの文字数によりデータ領域が管理されるので、文字列データ中に「００」があっても文字列データとして取り扱われる。
【００１２】
ここで、コントロールオブジェクト１２がサービスオブジェクト１３のプリント出力用のメソッドを呼ぶために、ＭＦＣのライブラリとして用意されているインターフェイスオブジェクト１８であるCOleDispatchDriverクラスのメンバ関数InvokeHelperを呼び、InvokeHelperはさらに、InvokeHelperVを以下のように呼ぶ。
void COleDispatchDriver::InvokeHleperV(DISPID dwDispID, WORD wFlags, VARTYPE vtRet, Void* pvRet, const BYTE*, pbParamInfo, va＿list argList)
・・・（３）
引数は、それぞれ、dwDispIDが呼び出されるメソッドまたはプロパティを識別し、wFlagsがIDispatch::Invokeの呼び出しコンテキストを示すフラグであり、vtRetが戻り値の型を指定し、pvRetが戻り値またはプロパティ値を受け取る変数のアドレスを指定し、pbParamInfoがこれに続く引数の型を指定するバイト列のＮＵＬＬで終わる文字列へのポインタを指定し、argListが引数のリストを指定する。
【００１３】
これにより、COleDispatchDriver::InvokeHelperVは、文字列データを以下のように変換する。
【００１４】
LPCSTR lpsz = va＿arg(argList, LPSTR);
pArg->bstrVal = ::SysAllocString(T2COLE(lpsz));
if (lpsz != NULL && pArg->bstrVal == NULL)
AfxThrowMemoryException();
pArg->vt = VT＿BSTR; ・・・（４）
ここでは、コントロールオブジェクト１２から渡された文字列データlpszが８ビット（マルチバイト）のシフトＪＩＳ（以降ではＴキャラクタ）であるＬＰＣＴＳＴＲ型で宣言されているので、文字変換マクロT2COLEが自動的に選択され、ＣＯＭを介してデータ転送する基本的な文字列（転送文字列）である１６ビット（ワイドキャラクタ）のＵＮＩＣＯＤＥに変換する。まず、最初の行では、引数のリストからDataパラメータを取り出し、次の行で実際にデータの変換が行われる。文字変換マクロT2COLEでは、AfxA2Whelperが呼ばれ、その関数内のMultiByteToWideCharにより、データは以下の１６ビット単位のワイドキャラクタのデータに変換される。
Ａ２： 7B 00 41 00 00 00 ・・・（５）
すなわち、コントロールオブジェクトで文字列データがｎｕｌｌデータを終端とするＬＰＣＴＳＴＲ型で宣言されているので、文字列データ中に含まれている「００」を文字列データの終端として変換される。このため、「００」以降のデータを含まない、「００」以降が削除された、終端が「００」のワイドキャラクタ（ＬＰＣＯＬＥＳＴＲ型）の文字列データとなる。そして、SysAllocStringにより、文字数（実際にはバイト数）データを備えたＢＳＴＲ型に変換されＣＯＭを介してサービスオブジェクト１３に転送される。
【００１５】
すなわち、サービスオブジェクト１３に転送されるデータは４バイトの文字数データが加わり以下のようになる。
Ａ３： 04 00 00 00 7B 00 41 00 ・・・（６）
サービスオブジェクト１３では、コントロールオブジェクト１２と同様に文字列データがＬＰＣＴＳＴＲ型で宣言されており、ＣＯＭにより、宣言された型の文字列データに合わせた８ビットのデータを受け取る。すなわち、サービスオブジェクトにおいては以下のような文字列データを受け取る。
Ａ４： 7B 41 00 ・・・（７）
サービスオブジェクト１３により制御されるプリンタ２１では、アプリケーションが指定したデータを印字することができない。ＣＯＭにより送られる文字列データはＢＳＴＲ型であり、上記の文字列データＡ４をＢＳＴＲ型でキャストして処理することも可能であるが、メモリを見るとデータは以下のようになっており、ＢＳＴＲ型としての文字列の長さの情報を持っているが、コントロールオブジェクトから転送されるときに切り捨てられたデータは残されていない。
Ａ５： 02 00 00 00 7B 41 00 ・・・（８）
このように、コントロールオブジェクト１２においてＬＰＣＴＳＴＲ型で宣言した文字列データでアプリケーションプログラム１１から「００」を含むデータを受信すると、それをサービスオブジェクト１３に転送してプリンタ２１で出力することができない。一方、コントロールオブジェクトやサービスオブジェクトにおいて文字列データの宣言された型を変更することは、オブジェクト間、あるいはアプリケーションとオブジェクト間で交換されるパラメータの仕様の統一を図り、ユニホームなインターフェイスをアプリケーションプログラムに提供するオブジェクト指向のＰＯＳシステムでは採用することができない。また、ユーザがすでに導入しているソフトウェア資産を保護するという点でも好ましくない。
【００１６】
また、バイナリコンバージョンを利用して「００」を強制的に他の値に変換してから転送し、次のオブジェクト内で元に戻すという方法がないわけではない。しかしながら、処理が複雑になることはもちろんであるが、オブジェクト内で、他のオブジェクトの変換処理とマッチした処理を行う必要があり、転送元のオブジェクトの仕様に依存することになる。したがって、ソフトウェアの部品化と再利用の可能性を高めるというオブジェクト指向プログラムとは相反する。さらに、バイナリコンバージョンされたデータを処理できないオブジェクトであれば、異なった文字列を出力する可能性がある。
【００１７】
このように「００」を含む文字列データの処理は難しい問題を含んでいるが、バーコードを含め、多種多様なデータが取り扱えるＰＯＳシステムを構築するためには「００」を含む文字列データがサービスオブジェクトに正確に転送され、プリンタなどのデバイスで出力できるようにすることが必要である。
【００１８】
そこで、本発明においては、コントロールオブジェクトあるいはサービスオブジェクトの文字列データの型の宣言を変更したり、複雑な処理を行わないで、「００」すなわちｎｕｌｌデータを含む文字列データであっても、正確にオブジェクト間で転送することができる文字列データの処理方法、処理システムおよびそれに用いられるオブジェクトプログラムを提供することを目的としている。
【００１９】
【課題を解決するための手段】
このため、本発明においては、アプリケーションプログラムを実行する際に、クライアント側となる第１のオブジェクト、たとえば上記のコントロールオブジェクトからサーバ側となる第２のオブジェクト、たとえば上記のサービスオブジェクトに対し、ＣＯＭなどのコンピュータのオペレーティングシステム上で稼動するインターフェイスオブジェクトを介して第１の文字列データを転送する際に、インターフェイスオブジェクトにおいて、第１のオブジェクトの第１の文字列データの宣言された型に関わらず第１の文字列データを、文字列データ中に含まれるｎｕｌｌデータも含めて文字数をカウントできる基本文字列データとして第１の文字列データの実効文字数を求め、オペレーティングシステムが転送可能な転送文字列データに第１の文字列データを実効文字数だけ変換する工程と、第２のオブジェクトにおいて、第１の文字列データの宣言された型に関わらず、第１の文字列データを基本文字列データとして処理を実行する工程とを有する文字列データの処理方法により処理するようにしている。
【００２０】
したがって、本発明の、アプリケーションプログラムを実行する際に、クライアント側となる第１のオブジェクトと、この第１のオブジェクトに対しサーバ側となる第２のオブジェクトと、第１のオブジェクトから第２のオブジェクトにオペレーティングシステムを介して第１の文字列データを転送可能なインターフェイスオブジェクトとを有する文字列データ処理システムにおいては、インターフェイスオブジェクトは、第１のオブジェクトの第１の文字列データの宣言された型に関わらず第１の文字列データを、文字列データ中に含まれるｎｕｌｌデータも含めて文字数をカウントできる基本文字列データとして第１の文字列データの実効文字数を求め、オペレーティングシステムが転送可能な転送文字列データに第１の文字列データを前記実効文字数だけ変換する手段を備えている。さらに、第２のオブジェクトは、第１の文字列データの宣言された型に関わらず、第１の文字列データを基本文字列データとして処理を実行する手段を備えている。
【００２１】
オブジェクトで宣言されている型に関わらず、文字列データを、その文字列データ中に含まれるｎｕｌｌデータも含めて文字数をカウントできる基本文字列データとして処理することにより、転送しようとする第１の文字列データ中に含まれるｎｕｌｌデータも含めて実効文字数を求めることができる。そして、オペレーティングシステムが転送可能な転送文字列データに第１の文字列データを実効文字数だけ変換することにより、文字列データがどのような型で宣言されていても、文字列データの途中に含まれる「００」のｎｕｌｌデータを文字列データの終端とせず、ｎｕｌｌデータも含めて正確に転送文字列データとすることができる。このため、標準化された転送文字列データでしかオブジェクト間のデータ転送をサポートできないようなＣＯＭなどのアーキテクチャあるいはその一貫として動作するシステム上であっても、ｎｕｌｌデータを含めて正確に文字列データを転送できる。
【００２２】
基本文字列データは、文字数データ付きの文字列データ、たとえばＣＯＭでサポートされているＢＳＴＲ型の文字列データを利用できる。また、オブジェクト間のみならず、アプリケーションプログラムとオブジェクト間におけるデータ転送であっても同様の問題が発生する可能性がある。したがって、第１のオブジェクトは、アプリケーションまたは文字列データを処理可能な周辺装置の種類単位のコントロールオブジェクトであり、第２のオブジェクトは、制御オブジェクトまたは周辺装置毎のサービスオブジェクトである。また、本発明はアプリケーションプログラムに対しても、アプリケーションプログラムを第１のオブジェクトとすれば適用することが可能である。したがって、第１のまた、本明細書において、オブジェクトとはアプリケーションを実行する際にＣＯＭのバインディングメカニズムによりバインディングされるオブジェクトのインスタンスも含まれており、特に記載していないかぎり、オブジェクトとインスタンスを区別していない。
【００２３】
このように、本発明の文字列データの処理方法および処理システムによれば、オブジェクトにおける文字列データの宣言された型が文字列データ中にｎｕｌｌデータが含まれないことを前提としたものであっても、その文字列データ中にｎｕｌｌデータが含まれた文字列データをオブジェクタ間で正確に転送できる。したがって、従来からのオブジェクトの文字列データの宣言された型を変更しないで、バーコードデータなどのｎｕｌｌデータが含まれる可能性がある文字列データを処理することができる。このため、本発明により、バーコードデータなどを含めた多種多様なデータ形式を正確にハンドリングすることができるオブジェクトベースのＰＯＳシステムを提供することができる。
【００２４】
また、本発明の文字列データの処理方法の各行程をコンピュータに実行させるためのプログラムをコンピュータ読み取り可能な磁気ディスクなどの適当な記録媒体に記録して提供することもできる。
【００２５】
【００２６】
【００２７】
【発明の実施の形態】
以下では、上記にて図１および図２に基づき説明した分散型オブジェクトで構築されるＰＯＳシステム１０に基づき本発明についてさらに説明する。まず、本発明をＰＯＳシステム１０に適用するために、ＭＦＣのCOleDispatchDriverクラスからCCoOleDispatchDriverクラスのインターフェイスオブジェクトを派生し、そのデータ変換部分を以下のようにオーバーライドする。
LPCSTR lpsz = va＿arg(argList, LPSTR);long lLen = ::SysStringByteLen((BSTR)lpsz);long lDestLen = lLen + 1;
LPWSTR pWideChar = (LPWSTR)CoTaskMemAlloc(lDestLen * 2 * sizeof(WCHAR));long lTrueLen;
if(lLen)[
lTrueLen = MultiByteToWideChar(CP＿ACP, 0, lpsz, lLen, pWideChar, lLen);]
else[
lTrueLen = MultiByteToWideChar(CP＿ACP, 0, lpsz, 0, pWideChar, lDestLen);]
pArg->bstrVal = ::SysAllocStringLen(pWideChar, lTrueLen);CoTaskMemFree((void*)pWideChar);
if (lpsz != NULL && pArg->bstrVal == NULL) AfxThrowMemoryException();
pArg->vt = VT＿BSTR;
・・・（９）
上記のデータ変換の処理では、まず、１行目でパラメータリストargListの中から文字列パラメータを取り出し、ＬＰＣＳＴＲ型としている文字列データlpszにセットする。以下、各行毎に順番に、文字列データlpszをＢＳＴＲ型にキャストし、文字列データの途中にｎｕｌｌデータがある場合も、それを含めた文字列データの長さ（文字数データ）を求める。さらに、文字数データlLenが０にならないように１を足し、さらに、ＣＯＭで転送される標準の文字コードである１６ビットのＵＮＩＣＯＤＥに対応してワイドキャラクタに変換するためのメモリを確保する。そして、文字列データlpszを文字数データlLenで長さを指定してワイドキャラクタに変換しＬＰＷＳＴＲ型の文字列データpWideCharに格納する。
【００２８】
その後、サービスオブジェクトにＣＯＭを介してデータを渡すために、ＢＳＴＲ型の引数pArgに文字数データlLenで長さを指定して変換する。このようにして変換が終了すると、確保したワイドキャラクタ用のメモリを開放する。また、その下でパラメータが不正な場合は例外を発生させる。そして、サービスオブジェクトに渡す文字列データpArgがＢＳＴＲ型であることを設定する。
【００２９】
したがって、本例のＰＯＳシステム３０は、システム全体の構成は図１と同様であるが、コントロールオブジェクト３１、インターフェイスオブジェクト３８およびサービスオブジェクト３３においては、図３に示すようにデータが転送される。まず、アプリケーションプログラム１１が、ステップ５１においてバーコードを印刷するためのメソッドであるPrintBarCodeメソッドを呼んで、上記と同様に以下のｎｕｌｌデータ（１６進「００」）を含む文字列データＡ０を渡すと、コントロールオブジェクト３２が以下のＢＳＴＲ型の文字列データＡ１を受け取る。
Ａ０： 7B 41 00 30 31 32 33 34 35 36 37 38 39・・・（１）
Ａ１： 0D 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00
・・・（２）
そして、本例のコントロールオブジェクト３２は、ステップ５２において、サービスオブジェクトにバーコードの文字列データを転送するために、COleDispatchDriverの代わりに、上記のように変換機能をオーバ−ライドしたインターフェイスオブジェクト３８であるCCoOleDispatchDriverクラスのInvokeHeplerVを呼ぶ。
void CCoOleDispatchDriver::InvokeHleperV(DISPID dwDispID, WORD wFlags, VARTYPE vtRet, Void* pvRet, const BYTE*, pbParamInfo, va＿list argList)
・・・（３）´
本例のインターフェイスオブジェクト３８においては、上述したように、ステップ５３で、コントロールオブジェクト３２から渡された文字列データlpszがＬＰＣＴＳＴＲ型で宣言されているが、ＢＳＴＲ型にキャストし、文字長さ（文字数）のデータを求める。そして、ステップ５４でＣＯＭを介して転送するために求められた文字数分を欠けることなくワイドキャラクタに変換し、さらに、ステップ５５でワイドキャラクタのＢＳＴＲ型の文字列データでサービスオブジェクトに転送する変数pArgにセットする。したがって、本例のインターフェイスオブジェクト３８では以下のように文字列データが変換される。まず、ステップ５４においては、文字列データの長さを指定して文字列変換関数MultiByteToWideCharによりワイドキャラクタに変換することにより文字列データＡ１は次の文字列データＡ２´に変換される。
Ａ２´： 7B 00 41 00 00 00 30 00 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 39 00 ・・・（５）
上記の文字列データＡ２に対し、本例では、文字列データの長さを指定しているため、文字列データに含まれるｎｕｌｌデータ（１６進「００」）以降のデータもワイドキャラクタに変換される。
【００３０】
さらに、このデータが、ステップ５５において、文字変換マクロSysAllocStringLenによりＣＯＭを介してデータを転送する文字列データのＵＮＩＣＯＤＥ（１６ビット）のＢＳＴＲ型の文字列データＡ３´に変換される。
Ａ３´： 1A 00 00 00 7B 00 41 00 00 00 30 00 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 39 00 ・・・（６）´
したがって、サービスオブジェクトには、ｎｕｌｌデータを含め、アプリケーションプログラム１１から供給された全ての文字列データが渡される。
【００３１】
一方、サービスオブジェクト３３においては、文字列データを受け取る引数ｐＤａｔａがｎｕｌｌデータを終端データとするＮｕｌｌ−ＴｅｒｍｉｎａｌのＬＰＣＴＳＴＲ型で宣言されるので、以下の文字列データＡ４を受け取る。
Ａ４： 7B 41 00 ・・・（７）
したがって、このままＬＰＣＴＳＴＲ型として文字列データを扱うと、やはりｎｕｌｌデータ以降のデータを処理することができない。しかしながら、上述したようにＣＯＭを介して文字列データが転送される場合は、メモリ上はＢＳＴＲ型で転送先のオブジェクトに送られる。したがって、サービスオブジェクトにおいては、その関数のプロトタイプでその引数の型がＬＰＣＴＳＴＲと宣言されているだけで、実際のデータはＢＳＴＲ型である。したがって、このデータの前後のメモリを見ると次のようになっている。
Ａ５： 0D 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00
・・・（８）´
したがって、本例のサービスオブジェクト３３においては、以下のように、ステップ５６において、ＬＰＣＴＳＴＲ型で宣言されている引数pDataをＢＳＴＲ型であるとして処理する。
lDataLen = SysStringByteLen((BSTR)pData);CString strBinaryData (pData, lDataLen);
・・・（１０）
すなわち、上記の処理では、ＬＰＣＴＳＴＲ型で宣言されている引数pDataをＢＳＴＲ型にキャストして文字数（文字列長さ）を求め、ＭＦＣのCStringクラスの変数strBinaryDataにpDataをその文字数（文字列長さ）IDataLenだけセットしてプリンタから印刷できるようにしている。したがって、アプリケーションプログラム１１から供給されたｎｕｌｌコードあるいはデータである１６進「００」を含む文字列がサービスオブジェクト３３からｎｕｌｌデータおよびそれ以降のデータが削除されることなくプリンタに伝達され、出力される。
【００３２】
このように、本例のコントロールオブジェクト３２からサービスオブジェクト３８にＣＯＭを介してデータを転送するインターフェイスオブジェクト３８はＭＦＣのベースクラスから派生させたものであるが、ｎｕｌｌ−ｔｅｒｍｉｎａｔｅの文字列データＬＰＣＴＳＴＲ型であっても、その文字列データを文字長さあるいは文字数のデータを含んだ「００」を取り扱えるＢＳＴＲ型のデータにキャストして本来の有効な文字数（実効文字数）を求め、その文字数に相当するデータを文字列データＬＰＣＴＳＴＲ型に関わらず、ワイドキャラクタに変換してＣＯＭで転送可能なＵＮＩＣＯＤＥの文字列データにしている。したがって、従来のＭＦＣクラスから派生したインターフェイスオブジェクトでは、ＰＬＣＴＳＴＲ型などのｎｕｌｌ−ｔｅｒｍｉｎａｔｅの文字列データとして宣言されている場合は、ｎｕｌｌデータ以降がＣＯＭを介してオブジェクト間を転送されるときに削除されてしまうのに対し、ｎｕｌｌデータを含む文字列データであっても正確にオブジェクト間で渡すことができる。アプリケーションプログラムを作成する際に、プログラマが独自にマーシャリングを行う代わりにＭＦＣクラスから派生したインターフィエスオブジェクトを使用する場合も同様であり、本発明に係るインターフェイスオブジェクトを利用することによりアプリケーションプログラムからコントロールオブジェクトに対してもｎｕｌｌデータおよびそれ以降のデータが落ちるのを防止できる。
【００３３】
また、上記のコントロールオブジェクトおよびサービスオブジェクトにおいては、文字列データは元来のＬＰＣＴＳＴＲ型で宣言されていても、ｎｕｌｌデータに関わる問題を防止できるので、アプリケーションプログラム１１に対しユニホームなＡＰＩを提供する分散型オブジェクトによるＰＯＳコントロールシステムの仕様を変更する必要はない。したがって、アプリケーションプログラム１１を提供する側、また、それを使用するユーザは、過去のソフトウェア資産を無駄にすることなく本発明によりｎｕｌｌデータも正確に取り扱うことができるＰＯＳコントロールシステム３９を利用することができる。
【００３４】
さらに、従来のｎｕｌｌ−ｔｅｒｍｉｎａｔｅの文字列データをそのままｎｕｌｌ−ｔｅｒｍｉｎａｔｅとして変換してしまうインターフェイスオブジェクトで「００」を含んだ文字列データを強引に取り扱おうとすると、バイナリコンバージョンを利用して「００」を強制的に他の値に変換してからオブジェクト間を転送し、オブジェクト内で元に戻すという方法がないわけではない。しかしながら、処理が複雑になることはもちろんであるが、オブジェクト内で、他のオブジェクトの変換処理とマッチした処理を行う必要があり、転送元のオブジェクトの仕様に依存することになる。したがって、ソフトウェアの部品化と再利用の可能性を高めるというオブジェクト指向プログラムとは相反するものとなるので採用しがたい。さらに、バイナリコンバージョンされたデータを処理できないオブジェクトであれば、異なった文字列を出力する可能性がある。これに対し、上記に説明した本発明の方法であれば、ｎｕｌｌデータおよびそれ以降のデータをそのままの状態で次のオブジェクトに転送できるので、それを受け取ったオブジェクトはｎｕｌｌ−ｔｅｒｍｉｎａｔｅの文字列データとして処理しても良く、あるいは上記のようにＢＳＴＲ型にキャストして「００」を含めて処理しても良い。このため、従来のオブジェクトに影響を及ぼすこともなく、ｎｕｌｌデータを取り扱うことができるコントロールシステムを構築できる。
【００３５】
本例のＰＯＳコントロールシステム３９を構築するコントロールオブジェクト３２、サービスオブジェクト３３およびインターフェイスオブジェクト３８は、図３に示した各ステップの処理を実行可能な命令を有するプログラムとしてＣＤ−ＲＯＭあるいはその他のコンピュータに読み取り可能な記録媒体に記録して提供することができる。そして、コンピュータ内のＯＳ１４により管理されるメモリ領域にインストールすることにより、各々のオブジェクトのメソッドあるいはプロパティなどが呼び出されると、各々のオブジェクトのインスタンスが生成され、バインドされてアプリケーションプログラムの所望の処理が実行される。
【００３６】
なお、以上では、バーコードなどの多種多様なデータを取り扱う可能性があるためにｎｕｌｌデータを実際に処理する可能性が高いＰＯＳシステムを例に本発明を説明しているが、文字列データを取り扱う他のシステムにおいても本発明を同様に適用できる。
【００３７】
【発明の効果】
以上に説明したように、本発明においてはバイナリコンバージョンを利用して文字列データを特殊な形式に変換することなくｎｕｌｌデータ（１６進「００」）を途中に含む文字列データであっても正確にオブジェクト間を転送できる。したがって、バーコードデータなどのｎｕｌｌデータを含む可能性のある文字列データを処理可能な方法および装置をオブジェクサービスによって提供することが可能となり、ＰＯＳシステムなどの多種多様なデータを取り扱う可能性のあるシステムを容易に構築できるソフトウェア開発手段を提供できる。
【図面の簡単な説明】
【図１】オブジェクトサービスによりＰＯＳシステムの概要を示す図である。
【図２】アプリケーションプログラムおよびオブジェクト間を文字列データが転送する様子を示す図である。
【図３】本発明のコントロールオブジェクト、インターフェイスオブジェクトおよびサービスオブジェクトの処理の概要を示す図である。
【符号の説明】
１０ＰＯＳシステム
１１アプリケーションプログラム
１２、３２コントロールオブジェクト
１３、３３サービスオブジェクト
１８、３８インターフェイスオブジェクト
１９、３９ＰＯＳコントロールシステム（オブジェクトサービス）

Claims

アプリケーションプログラムを実行する際に、クライアント側となる第１のオブジェクトからサーバ側となる第２のオブジェクトに対し、コンピュータのオペレーティングシステム上で稼動するインターフェイスオブジェクトを介して第１の文字列データを転送する際に、
前記インターフェイスオブジェクトにおいて、前記第１のオブジェクトの前記第１の文字列データの宣言された型に関わらず前記第１の文字列データを、当該文字列データ中に含まれるｎｕｌｌデータも含めて文字数をカウントできる基本文字列データとして前記第１の文字列データの実効文字数を求め、前記オペレーティングシステムが転送可能な転送文字列データに前記第１の文字列データを前記実効文字数だけ変換する工程と、
前記第２のオブジェクトにおいて、前記第１の文字列データの宣言された型に関わらず、前記第１の文字列データを前記基本文字列データとして処理を実行する工程とを有することを特徴とする文字列データの処理方法。
請求項１において、前記基本文字列データは、文字数データ付きの文字列データであることを特徴とする文字列データの処理方法。
請求項１において、前記アプリケーションプログラムは、ｎｕｌｌデータを含む文字列データを処理可能であり、前記第１のオブジェクトは、前記アプリケーションプログラムまたは文字列データを処理可能な周辺装置の種類単位のコントロールオブジェクトであり、前記第２のオブジェクトは、前記コントロールオブジェクトまたは前記周辺装置毎のサービスオブジェクトであることを特徴とする文字列データの処理方法。
請求項３において、前記文字列データはバーコードデータであることを特徴とする文字列データの処理方法。
請求項３において、前記アプリケーションプログラムはＰＯＳアプリケーションプログラムであることを特徴とする文字列データの処理方法。
請求項１乃至５項のいずれかに記載の文字列データの処理方法の各工程をコンピュータに実行させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
アプリケーションプログラムを実行する際に、クライアント側となる第１のオブジェクトと、この第１のオブジェクトに対しサーバ側となる第２のオブジェクトと、前記第１のオブジェクトから前記第２のオブジェクトにオペレーティングシステムを介して第１の文字列データを転送可能なインターフェイスオブジェクトとを有し、
前記インターフェイスオブジェクトは、前記第１のオブジェクトの前記第１の文字列データの宣言された型に関わらず前記第１の文字列データを、当該文字列データ中に含まれるｎｕｌｌデータも含めて文字数をカウントできる基本文字列データとして前記第１の文字列データの実効文字数を求め、前記オペレーティングシステムが転送可能な転送文字列データに前記第１の文字列データを前記実効文字数だけ変換する手段を備えており、
前記第２のオブジェクトは、前記第１の文字列データの宣言された型に関わらず、前記第１の文字列データを前記基本文字列データとして処理を実行する手段を備えていることを特徴とする文字列データ処理システム。
請求項７において、前記基本文字列データは、文字数データ付きの文字列データであることを特徴とする文字列データ処理システム。
請求項７において、前記アプリケーションプログラムは、ｎｕｌｌデータを含む文字列データを処理可能であり、前記第１のオブジェクトは、前記アプリケーションプログラムまたは文字列データを処理可能な周辺装置の種類単位のコントロールオブジェクトであり、前記第２のオブジェクトは、前記コントロールオブジェクトまたは前記周辺装置毎のサービスオブジェクトであることを特徴とする文字列データ処理システム。
請求項９において、前記文字列データはバーコードデータであることを特徴とする文字列データ処理システム。
請求項９において、前記アプリケーションプログラムはＰＯＳアプリケーションプログラムであることを特徴とする文字列データ処理システム。