Character string processing method, processing system, and object program therefor

Abstract: Character strings containing null can be reliably passed between objects without using a complicated process and without changing the character string type declared by the control object or service object. An interface object (38) for passing character strings from a control object (32) to a service object (33) casts the character string received from the control object (32) as a BSTR type even if the received string is LPCTSTR type, determines the number of characters in the string, converts the string to wide characters without dropping any characters in the string, and creates a COM-standard BSTR type wide character string. Null (OxOO) and all following characters in the character string can therefore be reliably passed to the service object (33).

Description: The present invention relates to a character string processing method and processing system using software object components. Component-based programs (objects) written in an object-oriented programming language are reusable software objects that run on a particular operating system. Using objects makes it easier to develop a variety of systems and applications. The Component Object Model (COM) supported by the Microsoft Windows (R) operating system, for example, is a functionally rich system providing an environment in which client applications (container applications) can use and share objects. By developing systems based on COM objects, software products can be provided as reusable parts enabling individual users to build customized systems and reduce maintenance costs. This design model also enables the further development and evolution of existing software assets, making system development easier and reducing related development costs. The ability to develop objects on a component base also simplifies developing a complex system consisting of various subsystems or various peripheral devices, and has become essential to the development of systems operating under a network environment. A POS (Point-Of-Sale) system is one type of system that is assembled from a variety of peripheral devices. A typical POS system comprises a display device, a printer, scanner, cash drawer, card reader, and other input/output devices connected to a personal computer or other central host computer. In JP-A-9-106355 and JP-A-9-73395, we previously taught a flexible personal computer-based POS system built using objects. Fig. 1 shows the concept of a distributed object POS system 10. This POS system 10 comprises a POS application program 11 supplied by the system manufacturer; control objects (CO) 12 supplied for the particular type of device (device class), such as printer 21, scanner 22, cash drawer 23, or other type of peripheral device; and service objects 13 (SO) supplied for a particular device. For the POS application program 11 to print something from the printer 21, data is first sent to the printer control object 12, then to the service object 13 for the particular make or model of the printer from which data will be printed, and then from the operating system (OS) 14 to the printer 21. The POS application program 11 can also use the display 15, keyboard 16, and other hardware resources of the personal computer as peripheral devices of the POS application program 11 via the OS 14. The object control system 19 containing the control objects 12 and service objects 13 in the POS system 10 shown in Fig. 1 provides the POS application program 11 with an interface that is independent of the particular peripheral devices (such as the printer 21). Because the control objects 12 are developed for particular device classes, a control object instance is created by the COM supported by the OS 14 when the POS application program 11 is run, and the control object instance is bound to the POS application program 11. The service object 13 provides a uniform interface independent of the particular device to the control object 12; when a particular device is called by the control object 12, a service object instance is created and bound to the POS application program 11. In a COM based system, for example, ActiveX controls (OLE controls) that can return events to the program 11 can be used for control object 12, and an ActiveX server (OLE automation server) operating as a server for ActiveX controls can be used as the service object 13. The COM provides support for data communication between objects bound by automation, that is, between instances of objects bound in order to run the application program. "Automation server" is a software object containing both properties and methods, and "automation" is a mechanism, for publishing or manipulating objects. Automation is dependent upon the COM IDispatch interface, and communication between objects is accomplished by running the Invoke method. IDispatch is an interface for publishing ActiveX controls and ActiveX server methods and properties for use by a COM-compatible programming language. The Microsoft Foundation Class Library (MFC), which provides a developing environment with an automation function based on Visual C++ (R), an object-oriented programming language published by Microsoft, therefore provides the COleDispatchDriver base class (object) for handling the complexities of calling the Invoke function from the application program or client object. A client object can therefore send data to a server object by calling InvokeHelper, a member function of the interface object derived from this base class. In other words, a specific process must be run in order to use the Invoke function, and an InvokeHelper function containing this predefined process is provided to help call the Invoke function. This predefined process includes, for example, reading arguments from a list and running a process based on these arguments, converting the Invoke result to a method, or throwing exceptions when an illegal process is run. Fig. 2 schematically shows the flow of data from a POS application program 11 to a device (printer) 21. In order to print text data on the printer 21, the POS application program 11 calls the print method of the printer control object 12 and passes the text data to the print method. In order to call the service object 13 method for the printer 21, the control object 12 calls the InvokeHelper member function of the COleDispatchDriver class (the interface object (IFO) 18). The data is then passed through the interface object 18 to the service object 13, and through the OS 14 to the printer 21. A problem is that if a null character (0x00 in hexadecimal notation; all character data noted below is also in hexadecimal notation) such as sometimes contained in bar code data is present in the text data (character string), the character string will not be reproduced on the printer 21 of the POS system 10. The printer control object 12 in a POS system typically has a PrintBarCode method, and if a data string containing a null (0x00) character is specified as the data parameter of the PrintBarCode method, the data string is passed by a process such as follows. First, the POS application program 11 sends the following character string A0 to the control object 12. A0: 7B 41 00 30 31 32 33 34 35 36 37 38 39 The control object 12 receives character string A0 but receives it declared as a LPCTSTR type. An LPCTSTR is a pointer to a null-terminated (0x00) 8-bit ANSI (American National Standard Institute) string, as well as a character string of Shift JIS(Japanese Industrial Standard)-defined characters. A null (0x00) character is therefore not allowed in the middle of the string. When not trying to print byte data as image data, null (0x00) is not contained in the printable characters, and character string data is generally declared as a LPCTSTR type in the printer object. In a COM environment, however, COM supports application-object and object-object data transfers with character strings passed through COM as BSTR strings, that is, basic or binary strings containing a string length (character count) declaration. String A0 is thus converted to A1: A1: OD 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00 A BSTR string thus starts with the string length written to the first four bytes, and ends with 00 (which is not included in the string length (character count)). Note, however, that this 00 is not used as the terminating character. Data memory is managed based on the number of characters from the pointer so that even a null (0x00) contained in the character string is treated as character data. In order for the control object 12 to call the print output method of the service object 13, it first calls the InvokeHelper member function of the COleDispatchDriver class (interface object 18 provided as an MFC library), and InvokeHelper calls InvokeHelperV as follows: void COleDispatchDriver::InvokeHelperV(DISPID dwDispID, WORD wFlags, VARTYPE vtRet, Void* pvRet, const BYTE* pbParamlnfo, va_list argList) where the parameters are defined as follows. dwDispID: Identifies the method or property to be invoked. wFlags: Flags describing the context of the call to IDispatch::Invoke. vtRet: Specifies the type of the return value. pvRet: Address of the variable that will receive the property value or return value. pbParamlnfo: Pointer to a null-terminated string of bytes specifying the types of the parameters stored in the argList following pbParamlnfo. argList: list of parameters COIeDispatchDriver::InvokeHeIperV thus converts a character string as follows. LPCSTR lpsz = va arg(argList, LPSTR); pArg- > bstrVal = ::SysAllocString(T2COLE(lpsz)); if (lpsz != NULL && pArg-> bstrVal = = NULL) AfxThrowMemoryException(); pArg->vt = VT_BSTR; Because the character string Ipsz passed from control object 12 is declared by an 8-bit Shift JIS (multibyte character) LPCTSTR, the character conversion macro T2COLE is automatically selected and the characters are converted to 16-bit wide characters (Unicode), the basic transfer string type passed by COM. T2COLE is defined as a model library (ATL: Active Template Library) for creating ActiveX controls using Visual C++. The first line above reads the data parameters from the parameter list, and the data is then actually converted by the next line. The character conversion macro T2COLE invokes the AfxA2Whelper function wherein MultiByteToWideChar converts the data to wide characters as shown below. A2: 7B 00 41 00 00 00 That is, because control object 12 declares the character string using a null-terminated LPCTSTR type, the null (0x00) characters contained in the middle of the character string are interpreted as terminating a character string. The result is a character string of a wide character (LPCTSTR) type not containing any data following 00 and deleting everything after 00. The character string is then converted by SysAllocString to a BSTR type containing data about the number of characters (actually bytes) in the string, which is passed through COM to service object 13. The data passed to the service object 13 after the four string length bytes are added is thus: A3: 04 00 00 00 7B 00 41 00 00 00 Like the control object 12, the service object 13 also uses LPCTSTR to declare character data, and receives data in 8-bit units according to the declared character string data type by COM. The service object thus receives: A4: 7B 41 00 The printer 21 controlled by the service object 13 is thus unable to print the data specified by the application program 11, and only prints part of the specified data (that is, the received data, A4). While the string data sent by COM is BSTR type and character string A4 can be cast and processed as a BSTR type, the data in memory only contains the string length information of the BSTR type as shown below, and the data omitted when transferred from the control object 12 is lost. A5: 02 00 00 00 7B 41 00 It will thus be apparent that if control object 12 receives string data declared as a LPCTSTR type containing a null (0x00) character from the POS application program 11, this string data cannot be sent to service object 13 and properly output on the printer 21. Furthermore, changing the declared string data type in the control object or service object cannot be used in an object-oriented POS system desiring to provide a uniform interface to the application program and unify the parameters exchanged between objects and between the application program and objects. It is also not desirable from the perspective of protecting the current software assets of the user. There are methods for forcibly converting null (0x00) using binary conversion to some other value before data transfer, and then restoring null (0x00) in a following object. In addition to being complicated, however, the conversion processes used by the different objects must match, and the receiving object is therefore dependent upon the design (operation) of the sending object. This is obviously contradictory to a goal of object-oriented programming, that is, improving software reusability and modularity. Yet further, if the receiving object cannot process the binary converted data, it might output a completely different character string. Processing character string data containing null (0x00) thus presents some difficult problems. In order to build a POS system capable of handling bar codes and other different data types, however, it is necessary to be able to accurately send character data containing null (0x00) to the service objects for output by a printer or other device. The document EP 0 762 273 A1 discloses a method and system according to the pre-characterizing portion of claims 1 and 5, respectively. This prior art involves the problems explained in detail above. It is therefore an object of the present invention to provide a character data processing method, processing system, and program whereby character string data can be sent accurately between objects even when the character string contains null (0x00) data without changing the character string type declaration of the control object or service object or performing other complicated operations. This object is achieved by a method, system and program as claimed in claims 1, 5 and 9, respectively. Preferred embodiments of the invention are subject-matter of the dependent claims. The effective number of characters including null (0x00) data contained in the first character string passed as string of a first data type from the first object to the interface object can be determined by processing the character string as one of a basic string data type that contains string length information thereby enabling the number of characters, including null (0x00) characters, in the string to be counted regardless of the first data type declared by the first object. Furthermore, by converting only the actual number of characters in the first character string to a second character string that can be passed by the operating system, a character string containing null (0x00) characters that can be reliably passed without the null (0x00) characters terminating the string. Character string data containing null (0x00) can thus be reliably passed between objects even in integrated systems or architectures, such as COM, that only support passing standardized types of character string data between objects. The basic string data type is a data type that contains string length information, such as the COM-supported BSTR type string data. The above data transfer problems are not limited to object-object communication, and also occur when passing data between application programs and objects. These problems thus occur when the application program is written, for example, using MFC in Visual C++. (Note that these problems do not occur when the application program is written with Visual Basic (R) published by Microsoft because MFC is not used by such programming languages.) Therefore, the first object is the application program or a peripheral device class control object; and the second object is a control object or a peripheral device service object. The present invention can thus be applied to application programs by making the application program the first object. Therefore, an object as used below includes instances of objects linked by the COM binding mechanism when the application program is run, and unless otherwise specifically noted no distinction is made between an object and an instance. The character string data processing method and system of the present invention can thus reliably pass between objects character string data containing null (0x00) data in the string even when the character string type declared by an object presumes that no null (0x00) data is contained in the string. The method and system of the invention can therefore process bar code data and other character string data that could contain null (0x00) data without changing the data type conventionally declared by the object. An object-based POS system that can reliably handle bar code data and various other data types can thus be provided by means of the present invention. Other objects and attainments together with a fuller understanding of the invention will become apparent and appreciated by referring to the following description of preferred embodiments taken in conjunction with the accompanying drawings, in which: Fig. 1 describes the concept of an object service based POS system; Fig. 2 shows the process for transferring character strings between an application program and objects; and Fig. 3 shows the concept of the present invention for processing control objects, interface objects, and service objects. The present invention is described below based on a POS system 10 built from distributed objects as described with reference to Fig. 1 and Fig. 2. In order to apply the present invention to a POS system 10 it is first necessary to derive a CCoOleDispatchDriver class interface object from the MFC COleDispatchDriver class, and then override the data conversion part of the interface object as follows. This data conversion process operates as follows. First, the character string parameter is read from the parameter list argList and assigned to string Ipsz of type LPCSTR. The following lines then cast string Ipsz as BSTR type, and determine the length (character count) of the character string, including any null (0x00) characters that might be present in the string. To assure that string length ILen is never 0, 1 is added to ILen, and memory is reserved to convert the character string to wide characters, that is, Unicode characters (the standard character code used by COM). String Ipsz is then converted to wide characters using the string length specified by ILen, and the result is stored to LPWSTR type wide character string pWideChar. The string is then converted to BSTR type parameter pArg, using the string length specified by ILen, for transfer to the service object through COM. After the conversion is completed, the memory reserved for wide character conversion is released. An exception is thrown if an illegal parameter is encountered. The character string pArg passed to the service object is then set as type BSTR. The overall configuration of the POS system 30 is thus the same as shown in Fig. 1, but data is handled as shown in Fig. 3 in the control object 32, interface object 38, and service object 33. When the POS application program 11 invokes the PrintBarCode method, which is a method for printing a bar code, in step 51 and passes a character string A0 containing null (0x00) data as shown below, the control object 32 receives a BSTR type character string A1 as shown below. A0: 7B 41 00 30 31 32 33 34 35 36 37 38 39 A1: 0D 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00 In order to pass the bar code character string to the service object, the control object 32 invokes the CCoOleDispatchDriver class InvokeHelperV function, which is an interface object 38 overriding the conversion function as described above, instead of invoking COleDispatchDriver, void CCoOleDispatchDriver::InvokeHelperV(DISPID dwDispID, WORD wFlags, VARTYPE vtRet, Void* pvRet, const BYTE* pbParamlnfo, va_list argList) As shown above, the interface object 38 receives string Ipsz declared as type LPCTSTR from the control object 32, but casts string Ipsz as type BSTR to detect the string length (step 53). The interface object 38 then converts the string to wide characters without dropping the string length data for transfer via COM (step 54), and then sets parameter pArg transferred to the service object 33 based on the BSTR type wide character string (step 55). The interface object 38 in this embodiment thus outputs a character string as shown below. First, character string A1 is converted to character string A2' in step 54 by specifying the string length and then converting the string to wide characters using the MultiByteToWideChar string conversion function. A2': 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 All data following null (0x00) in string A1 is also converted to wide characters in this embodiment, in contrast to the above conventionally converted string A2, as a result of declaring the length of string A1. This wide character string is then converted in step 55 by the SysAllocStringLen character conversion macro to BSTR type string A3' of Unicode characters for transfer by COM. A3': 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 00 00 As a result of this conversion process all string data supplied from the POS application program 11, including null (0x00), is passed to the service object 33. However, the service object 33 receives the following string A4 because parameter pData for receiving the string data is declared as a null-terminated LPCTSTR type. A4: 7B 41 00 It will thus be obvious that if the character string is handled as the declared LPCTSTR type, all data following null (0x00) will be dropped and cannot be processed. However, when the string data is passed by COM as described above, the data is passed in memory as a BSTR type to the receiving object. This means that in the service object the parameter type is simply declared as LPCTSTR by the function prototype (function type definition) and the actual data is BSTR type. The actual data in memory before and after string A4 is as A5' as shown below. A5': 0D 00 00 00 7B 41 00 30 31 32 33 34 35 36 37 38 39 00 The service object 33 therefore processes the parameter pData declared as LPCTSTR type as BSTR type data in step 56. IDataLen = SysStringByteLen((BSTR)pData); CString strBinaryData (pData, IDataLen); That is, the parameter pData declared as LPCTSTR type is cast as BSTR type, the string length is detected, and MFC CString class variable strBinaryData is set to pData of string length IDataLen for printing. As a result, a character string containing null (0x00) supplied from the POS application program 11 is sent from the service object 33 to the printer without stripping null (0x00) and the following data, and can thus be output from the printer. While the interface object 38 for passing data from the control object 32 to the service object 33 through COM is thus derived from an MFC base class, it can cast a null-terminated character string of LPCTSTR type as BSTR type data containing string length information that can also contain the null character (00) so that the actual number of characters (effective string length) can be determined. That number of characters can therefore be converted to wide characters irrespective of the LPCTSTR string type, and the data can thus be converted to a standard Unicode string handled by COM. It will thus be obvious that the present invention can accurately pass character string data containing null (0x00) between objects whereas a conventional interface object derived from an MFC class strips all data following null (0x00) when the data is passed by COM between objects if the data is declared as a LPCTSTR type or other null-terminated string data. This is also the case when the programmer of an application program uses an interface object derived from an MFC class instead of marshalling (a mechanism for invoking a method, for example, through COM), that is, by using the interface object of the present invention the application program can send data including null (0x00) to the control object without dropping null (0x00) and the following data. It is also not necessary to change the specifications of a distributed object POS control system providing a uniform API to the application program because problems conventionally related to null (0x00) data when the character string is declared as LPCTSTR type can be prevented in the control objects and service objects. The present invention thus enables both the application program provider and the program user to take advantage of a POS control system that can reliably handle string data containing null (0x00) without wasting existing software resources. As noted above, there are methods whereby a conventional interface object can forcibly handle string data containing null (0x00) by using binary conversion to forcibly convert null (0x00) to another value, sends the converted data to another object, and the receiving object then restores null (0x00). However, not only is this a complicated process, the conversion operations of the sending and receiving objects must match, and the receiving object becomes dependent upon the sending object. This technique is difficult to implement, however, because it is contradictory to the software modularization and reusability goals of object-oriented programming. Furthermore, if the receiving object cannot handle binary converted data, it might output a completely different string. With the method of the invention described above, however, null (0x00) and the following data can be passed without binary conversion to the next object. The data can therefore be processed by the receiving object as null-terminated string data, or the data can be cast and processed as a BSTR type containing null (0x00). For example, a method for handling string data that will never contain binary data can process the data as a null-terminated string, while a method that could encounter binary data casts the string data as BSTR type for processing. A control system that can handle null (0x00) data while having no effect on existing objects can thus be provided. The control object 32, service object 33, and interface object 38 of this POS control system 39 can be recorded on a Compact Disc (CD) or other type computer-readable data storage medium as a computer program having commands for executing the various steps shown in Fig. 3. By installing the program in memory managed by the OS 14 of the computer and invoking the methods and properties of the objects, instances of the objects are generated and bound to execute the desired application program processes. It should be noted that while the invention has been described with reference to a POS system as exemplary of an application with a high likelihood of actually processing null (0x00) data because of the wide range of bar codes and other data handled by the typical POS system, the invention is not limited to a POS system and can obviously be used with other systems that handle string data. As will be appreciated from the preceding description, the present invention enables string data containing null (0x00) in the string to be passed accurately and reliably between objects without using binary conversion to convert the string data to a special format. The present invention can therefore provide as an object service a method and system for processing string data, such as bar code data, that can contain null (0x00) within the string. The invention can further provide a software development means enabling a POS system or other system that potentially handles a variety of data types.

Claims: A character string data processing method for passing a first character string, declared as a first data type, through an interface object (18) running under a computer operating system from a first object (11; 12) serving as a client object to a second object (12; 13) serving as a server object for the first object (11; 12) when an application program (11) is run, wherein the interface objects (18) converts the first character string to a second character string of a basic string data type that contains string length information and passes the second character string to the second object (12; 13), the latter processing the second character string declared as basic string data type string; characterized by changing, in the interface object (18), the declared data type of the first character string from said first data type to said basic string data type that contains string length information, such that the number of characters including null data in the first character string is countable irrespective of said first data type, subsequently detecting an effective number of characters in the first character string, and then converting the effective number of characters in the first character string to said second character string that can be passed by the operating system. The method of claim 1, wherein the application program (11) can process character string data containing null data; the first object (11; 12) is the application program (11) or a peripheral device class control object (12), the peripheral device (21) being capable of processing character string data; and the second object (12; 13) is a peripheral device class control object (12) or a peripheral device service object (13), wherein a peripheral device class control object (12) is an instance of a class for controlling various peripheral devices of a computer and a peripheral device service object (13) is an instance of a class for controlling a particular peripheral device of the computer. The method of claim 2, wherein the character string data is bar code data. The method of claim 2, wherein the application program (11) is a POS application program. A character string data processing system comprising a first object (11; 12) serving as a client object, a second object (12; 13) serving as a server object with respect to the first object (11; 12), and an interface object (18) for passing a first character string from the first object (11; 12) to the second object (12; 13) upon execution of an application program (11), wherein the interface object (18) is adapted to convert the first character string to a second character string of a basic string data type that contains string length information and to pass the second character string to the second object (12; 13), the latter being adapted to process the second character string declared as basic string data type string; characterized in that the interface object (18) comprises means for changing the declared data type of the first character string from said first data type to said basic string data type that contains string length information, such that the number of characters including null data in the character string is countable irrespective of said first data type, detecting an effective number of characters in the thus changed first character string, and converting the effective number of characters in the first character string to said second character string that can be passed by the operating system. The system of claim 5 for use with an application program (11) that can process character string data containing null data; wherein the first object is the application program (11) or a peripheral device class control object (12), the peripheral device (21) being capable of processing character string data; and the second object is a peripheral device class control object (12) or a peripheral device service object (13), wherein a peripheral device class control object (12) is an instance of a class for controlling various peripheral devices of a computer and a peripheral device service object (13) is an instance of a class for controlling a particular peripheral device of the computer. The system of claim 6, wherein the character string data is bar code data. The system of claim 6, wherein the application program (11) is a POS application program. A computer program comprising a first code portion, a second code portion and an interface code portion that, when executed on a data processing system, implement a first object (11; 12) serving as a client object, a second object (12; 13) serving as a server object for the first object (11; 12) and an interface object (18), respectively, wherein said first object (11; 12) passes a first character string, declared as a first data type, to said second object (12; 13) by invoking said interface object (18), said passing comprising an executable command for running a process invoking the interface object (18); said interface object (18) converts the first character string to a second character string of a basic string data type that contains string length information, and passes the second character string to the second object (12; 13), the latter processing the second character string declared as basic string data type string; characterized in that the interface object (18) changes the declared data type of the first character string from said first data type to said basic string data type that contains string length information, such that the number of characters including null data in the character string data is countable irrespective of said first data type, then detects an effective number of characters in the first character string, and converts the effective number of characters in the first character string to said second character string data that can be passed by the operating system. The program of claim 9, wherein the first object (11; 12) is an application program (11) capable of processing character string data containing null data, or a peripheral device class control object (12), the peripheral device (21) capable of processing character string data, wherein a peripheral device class control object (12) is an instance of a class for controlling various peripheral devices of a computer. The program of claim 9 or 10, wherein the character string data is bar code data, and the application program (11) is a POS application program. The program of claim 9, 10 or 11, wherein the second object (12; 13) is a peripheral device class control object (12), the peripheral device (21) being capable of processing character string data, or a peripheral device service object (13), wherein a peripheral device class control object (12) is an instance of a class for controlling various peripheral devices of a computer and a peripheral device service object (13) is an instance of a class for controlling a particular peripheral device of the computer.. A computer-readable data storage medium carrying a program as described in any one of claims 9 to 12.

Inventors: OTSUKA JUNICHI, SUGIMOTO TOSHIYUKI, OTSUKA, JUNICHI, SUGIMOTO, TOSHIYUKI, Otsuka, Junichi, c/o Seiko Epson Corp., Sugimoto, Toshiyuki, c/o Seiko Epson Corp.
Applicants: SEIKO EPSON CORP, SEIKO EPSON CORPORATION
Application year: 2001
Main classification: G06F9
IPC codes: G06F9, G06K7, G06F13, G07G1