This help file supports version 1.0.0 of the M-S OLE for Retail POS (OPOS) Application Program Interface, which. is based on the Release 1.3 of the International Standard for OPOS. M-S’s implementation of the OPOS API supports its line of KSC and KSI Serial Cash Drawers..
This OPOS API runs on a Windows 95, Windows NT, or other OLE compliant 32-bit operating system
The latest revisions of the OLE for Retail POS Application Programmer’s Guide and Control Programmer’s Guide are on the Microsoft Web site at
http://www.microsoft.com/BUSINESS/solutions/ret/retoposoverview.asp
or on the Wincor-Nixdorf at:
http://www.wincor-nixdorf.com/eng/products/retail/software/filialloesungen/opos.html
For further details and help contact us at
Automation (originally known as OLE Automation) allows one software component to expose it's method and properties to another software component. As Automation is applied to OPOS, a Service Object (as in-process server, implemented using a .dll or an out-of-process server, implemented as an .exe) exposes it's methods and properties to a control object (an Active X control or .OCX). Since the control Object is the client of service object it is referred to as an automation controller.
ActiveX Controls are standalone COM components that perform specific tasks in a standard way. The ActiveX Controls specification defines the standard interfaces and conventions though which this can be accomplished.. ActiveX controls are not separate applications, but rather are servers (in-process servers in the
M-S OPOS software) that plug into your application, which acts as a Control Container. ActiveX controls also support interfaces defined for embedding, and allow access to their methods via Automation. Active X Controls allow new functions to be added to an existing object as a new interface, rather than having to alter or extend an existing one. ActiveX controls were originally known as OLE controls, and hence their file extensions are .OCX
The Cash Drawer OLE Control comprises of methods that allow for the device to be opened, closed, claimed and released. These methods are also common to other OLE Controls for other POS devices. The methods specific to Cash Drawers are OpenDrawer and WaitForDrawertoClose. OpenDrawer fires the cash drawer open, while WaitForDrawertoClose is an synchronous method that waits for the drawer to close before it continues.
TOP
Cash Drawer Interactive Check Health
The Interactive Check Health dialog box for the Cash Drawer gives you a choice of four buttons:
Clicking on the Check_Health button when its list box is set to Interactive brings up the Cash Drawer Interactive Check Health modal dialog box.
Click on the Open_Drawer button to open the cash drawer and click on
Wait_For_Drawer to wait for the drawer to close.
Click on the Update button to update the contents of the Drawer Is: text box, which indicates whether the drawer is Open or Closed.
Click on the Done button to close the dialog box.
The CheckHealthText messages include:
|
Message |
Appears When |
|
HCheck - Check Health not called |
application calls Open method (default) |
|
HCheck{Internal} Successful |
Internal CheckHealthText method runs successfully |
|
HCheck{External} Successful |
External CheckHealthText method runs successfully |
|
HCheck{Interactive} Successful |
Interactive CheckHealthText method runs successfully |
|
[Error] Device closed |
application calls Close Method. |
Clicking on the Check Health button activates a method that checks on the state of the device. The text box next to the button specifies the type of health check performed when you click on the
Check Health:
· Internal - a health check that does not physically change the device.
· External - a health check that may change the device. For instance, the check may output a set of test characters from a printer.
Cash Drawers do not support external Health test.
· Interactive - a health check that includes interactive tests. You select these interactive tests using an Interactive Check Health dialog box that also displays the test
results.
The Component Object Model (COM) standard defines interfaces that allow one software component to provide services to another at the machine code level. This opens the way for industry standard reusable software objects, or components, like the ones implemented by the OPOS standard. Since the OPOS standard is based on COM, different POS device manufacturers can produce device driver objects with standard interfaces, allowing you to move your POS application across hardware platforms without modification.
Objects that conform to the COM specification have the following characteristics that allow them to act as software components:
· Interface (rather than implementation ) inheritance. Supporting interface inheritance rather than implementation inheritance preserves COM’s general applicability. If implementation inheritance were used, it might allow a child object to break the encapsulation of its parent.
· Multiple interfaces consisting of multiple methods, allowing COM objects to be very complex.
· A standard binary interface - The COM standard defines a binary interface that links together objects after they have been compiled. This interface allows clients to use a new version of an object without
re-linking and recompiling.
· Language independence - Any compiler that supports the COM interface can create COM objects, allowing COM objects to be written in one language and then accessed by clients written in another. In other words, you can use any language capable of making calls via a COM interface to invoke the methods in a COM object.
· Versioning - COM’s approach to versioning , which allows independent updates to both clients and the objects they use, is among its most important features.
Use the OPOS Configurator to create and manage device instance profiles for a
M-S OPOS device instance and to set device instance common properties . You perform these tasks using the OPOS Configurator Window, which is divided into a Device Instance: box and a box that describes its Service Object.
The Device Instance List provides a drop down list of all of the device instances that have already been
created. Buttons in the Device Instance: box allow you to create a New device
instance or Delete a device instance. There are two others buttons
to Save new device parameters and the other to see the DIP switch settings
for the KSI Cash Drawers according to the given device parameters. The
DIPSETTINGS button is only visible when the device instance is a KSI Cash Drawer
device.
The first two text boxes in the bottom half of the dialog box always list the:
Service Object ID and the Service Handler.
The list boxes that appear immediately below the Service Handler box, and that are separated from it by a horizontal line, allow you to set properties for the device instance that you are creating.
NOTE: When you change the properties of a device instance in the Configurator, the
Configurator enters the changes into the registry when you press the Save
New Settings Button.
The top of the Configurator Window contains the standard File and Help pull-down menus.
Control Container
A control container is client software that knows how to use an ActiveX control. The specification for ActiveX Controls defines rules for creating control containers. A container acts as a client for the object that it contains. The container invokes the inner object’s methods to perform its own functions, but conceals the inner object from any of its own clients. To do this, the container’s interface contains methods that in turn call the contained object’s methods. . Visual Basic and Visual C++ are among the languages used to create control containers
TOP
Click on the New button to create (or instantiate) a device instance. Clicking on New brings up the New dialog box, which has a list box and a text box with which you can specify a new device instance. The Device
Type: list box lists of all of the peripheral device classes that are available in the present release. You type in a unique device name into the Device Name text box after selecting one of the device
Types from the Device Driver list box and then click on OK. The device name has to be unique to all of the device instances in all of the device classes, whether they were supplied by
M-S or not, since all of the device names are on the same level in the registry “tree.” When you create a new device instance, its name immediately appears in the box for the Device Instance: list. The device properties will automatically go to a set of default values, that you can change in the OPOS Configurator window.
Clicking on the Delete button brings up the Delete Device Instance Dialog box. Click the Yes button to delete the device instance whose name appears in the text box for the Device Instance: pull down list.
The device instance list provides a drop-down list of all of the device instances installed on the workstation. If you ran the Dfltdevs.reg file during installation, the device instances specified in the file will appear in the device instance list. If you did not run the Dfltdevs.reg file, the list will be empty, leaving it up to you to create your own list of device instances. Each one of these instances can be taken from one of the source objects in the present release. When you double click on one of the device instances in the list, your selection becomes the current (or active) device instance, and the bottom half of the dialog box changes to match that device instance. The device instance names must be unique, but they can be of any length, and can contain any combination of characters.
You use the OPOS Configurator to create Device Instance profiles in the registry under the corresponding device class, which is in turn under the OPOS root key specified by the OPOS specification, as shown in the registry path name below:
HKEY_LOCAL_MACHINE\SOFTWARE\OLEforRetail\ServiceOPOS\(Device Class)
(Device Class) can be a device class: Cash Drawer etc.
The OPOS Configurator requires that all device instance names be unique. Depending on the Device Instance that you have selected, the Configurator displays the profile properties which are specific to that driver.
The Configurator File Menu gives you two choices:
· Click on Refresh each time that you use another application to change OPOS profile values in the registry. Each time that that you run the
Configurator, it reads the M-S OPOS registry profile values from the registry, which is stored on your disk drive, into active memory. Refresh makes the
Configurator read new registry values into memory, so that they are accurately reflected in the OPOS Configurator window.
· Click on Exit to shut down the Configurator and delete the OPOS Configurator window.
Selecting About on the Help menu brings up a dialog box showing the version
number and copyright notice information for the OPOS
Configurator program.
The version is of the form: (major version number). (minor version number).
(revision)
The Service Object Identifier is a string entered in the registry that identifies the Programmatic Service ID of the service object for the Device Instance that has been selected. It is of the form MSSerialCashDrawer.SerialCashDrawer.KSCSerial or MSSerialCashDrawer.SerialCashDrawer. KSISerial The Service Object ID text box is read only.
An OPOS Control Object, or CO, is a standard ActiveX Control that is invisible to the user at runtime. It forms a hardware independent shell that exposes methods, properties, and events to your application for its device class. It in turn interacts with Service Objects (SOs) for the same device class. The CO interfaces for each class of devices have been specified in the OPOS standard so that all implementations of a CO will be compatible. This allows COs to be developed independently of the SO for the same device class, including development by different companies.
A device class is a category of POS devices that share a consistent set of properties, methods, and events.
A Device Instance is a profile associated with a specific M-S OPOS-Compliant Service-Object driver that is stored in the system registry and has values associated with it that control the behavior of the driver. The M-S OPOS Configurator supports only the M-S OPOS Service Object drivers supported by the present release.
The device instance list provides a drop-down list of all of the device instances installed on the workstation. If you ran the Dfltdevs.reg file during installation, the device instances specified in the file will appear in the device instance list. If you did not run the Dfltdevs.reg file, the list will be empty, leaving it up to you to create your own list of device instances. Each one of these instances can be taken from one of the source objects in the present release. When you double click on one of the device instances in the list, your selection becomes the current (or active) device instance, and the bottom half of the dialog box changes to match that device instance. The device instance names must be unique, but they can be of any length, and can contain any combination of characters.
You use the MS OPOS Configurator to create Device Instance profiles in the registry under the corresponding device class, which is in turn under the OPOS root key specified by the OPOS specification, as shown in the registry path name below:
HKEY_LOCAL_MACHINE\SOFTWARE\OLEforRetail\ServiceOPOS\Cash Drawer)
The OPOS Configurator requires that all device instance names be unique. Depending on the Device Instance that you have selected, the Configurator displays the profile properties which are specific to that driver.
Device Instance Registry Profile
Each device instance is associated with exactly one registry profile. The registry profile is located in the registry under a specific device class under the OPOS root key as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\OLEforRetail\ServiceOPOS\Cash Drawer
In accordance with the OPOS specification, all OPOS registry properties are implemented as string values. However, each property can take on a logical type of String or Number.
Registry profiles allow a single Service Object to control multiple devices of the same type. For instance, the
KSI has two integral cash drawer ports. You can create two instances of the KSI
Cash Drawer devices and configure each instance to represent a different port by setting the appropriate registry profile value.
TOP
Device Supported by Current Version
This version of the M-S OPOS API supports the following Models of MS Cash
Drawers:
· KSI
· KSC
In addition to an OPOS driver for each supported device class, this software also includes a set of utilities that
configure and test and monitor the API, and an installation program for these components.
This method provides a means for a service object to provide functionality to the application that is otherwise not supported by the standard control object for its device class. depending upon the service object's definition of the command, this method may be asynchronous or synchronous.
The current Version of the M-S-OPOS software does not support this method.
A notification from an object that something has happened. It is similar to a method call except that occurs from the object to the user. When a control needs to tell its container that something has happened, it fires an event. Thus an event is an asynchronous notification from control to container and its semantics are defined by the control. All events are predefined
Because of its physical or operational characteristics, an exclusive use device can only be used by one application at a time. The application must call the Claim method to gain exclusive access to the device before most methods, properties, or events are legal. Should two closely cooperating applications want to treat an exclusive-use device in a shared manner, then one application may claim the device for a short sequence of operations, then release it so that the other application may use it.
Using OPOS Test to Exercise an OPOS Control
Your application must follow a predefined sequence to use an OPOS control.
Your application must first call the control’s Open method. The parameter of this method selects a device name to associate with the Control. The Open method:
· Establishes a link to the device name.
· Initializes the properties Claimed, Device Enabled, DataEventEnabled,
FreezeEvents, as well as descriptions and version numbers of the OPOS Control layers. It may also initialize other class-specific properties.
After your application has opened the device using the Open method, your application may often need to call the Claim method to gain exclusive access to the device.. Claiming the device ensures that other applications do not interfere with the use of the device, and many devices must be Claimed before the Control allows access to its methods and properties. The application may Release the device when the device can be shared by other applications - for instance, at the end of a transaction.
Before using the device, the application must set the Device Enabled property to TRUE. Setting this property to TRUE makes the device operational, while setting it to FALSE disables the device. For example, if a magnetic stripe reader Control is disabled, then the reader will not accept a card swipe. Whether physically disabled or not, any input from the device will be discarded until the device is enabled.
After the application has finished using the device, the Close method should be called to release the device and associated resources. If the
Device Enabled property is TRUE, then Close disables the device. If the Claimed property is TRUE, then Close releases the lock. Before exiting, an application should close all open OPOS Controls.
In summary, your application needs to follow this general sequence when it uses a control:
· Open method: Call to link the Control Object to the Service Object.
· Claim method: Call to gain exclusive access to the device. Required for exclusive-use devices; optional for some sharable devices. (See
"Device_Sharing_Model", for more information).
· Device Enabled property: Set to TRUE to enable the device. (For sharable devices, the device may be enabled without first Claiming it.)
· DataEventEnabled property. Set it to TRUE to indicate that your application is ready to receive data with from the device.
· Use the device.
· DeviceEnabled property: Set to FALSE to disable the device.
· Release method: Call to release exclusive access to the device.
· Close method: Call to release the Service Object from the Control Object.
Regedit.EXE can append a default set of device instance profiles to the registry from the
Dfltdev.reg on the
installation disk.
After gathering all user input, the setup program tests for the existence of the file
Dfltdev.reg file on the first installation disk. If this file exists, setup gives you the option of running it with
Regedit.EXE. If you choose, setup runs Regedit.EXE with the Dfltdev.reg file as a command line parameter, so that it applies settings in the file to the system registry.
After the setup program is run the folder in which the program is installed contains following files
|
File |
Contents |
| Configurator.exe | Configuration Utility |
| M-SOPOSTest.exe | Test Utility |
| Readme.txt | Recent information of interest to users |
| License.txt | Text of Software License Agreement |
| OPOSReg.txt | OPOS registry information |
| Dfltdevs.reg | Default device instance registry values |
| WinReg.bas | Visual Basic Run Time Engine |
| Uninst.isu | Un-installation Utility |
After the setup Program runs, the Windows/System folder contains following files
| Filename | Contents |
| MSCashdrawerSerial.dll | Serial Cash Drawer in process Server |
| OPOS.ocx | Active X control |
1. Compact installations, which include the Service Objects in this release along with the
M-S OPOS Configurator utility so that you can create your own device instances.
2. Custom installations, which allow you to choose the components that you want. These components include:
////To add
3. Full installations, consisting of all of the components that are available in a custom installation.
Un-Installing the M-S OPOS utilities
Un-install the M-S OPOS software in the same way that you un-install other Windows-compliant
programs. Un-installing the software removes the:
· Active-X (ocx) control
· In process (dll) server
· Executables for each of the utilities
· Folders containing program icons
Un-installing the software also removes any shared DLL or control files that were not present before the OPOS utilities were installed. These include the Microsoft Foundation Class (MFC) DLLs and the Visual Basic run time engine. Since these components are marked as shared, their properties tab will have a checkbox
that says that the component is share able but no other component is using it.
In automation terms, a process performed by an object when it receives a message (request) telling it to do something.
A trigger board in the KSI Cash Drawers manufactured by the M-S Cash Drawer Corporation opens the drawer in response to a signal from the workstation’s RS232
serial port. The trigger board digitally analyzes all incoming signals to eliminate false openings caused by turning the power on or by noise induced on the control lines between the cash drawer and workstation. It monitors incoming control signals from the workstations, opens the drawer, and reports and handshakes signals back to the workstation.
Since the trigger board can be programmed to open upon receipt of a single or two consecutive identical ASCII characters, several drawers may be daisy-chained together on the same serial port. Ten DIP switches on the interface board determine which character the drawer will respond to, and how many consecutive characters are required. Numeric ASCII codes 0 through 127 (“NULL” through “DEL”) are valid. The DIP switches can also program the cash drawer interface to operate between 1200 and 9600 baud.
The KSC series of cash drawers being the first to be launched by M-S Cash Drawer Corp. do not have any DIP switch settings and can be operated by sending an opening character value greater than ASCII value 0.
The solenoids in the drawer draw power from an external 12 V DC adapter.
M-S provides OPOS drivers for all M-S Serial Cash Drawers with KSI or KSC
interface.
| Name | Rev. | May occur after | Comments |
| Direction Event | 1.0 | Open | Not Supported |
| StatusUpdateEvent | 1.0 | Open & Enable |
M-S serial Cash Drawer Methods
| Name | Rev. | May Occur After | Comments |
| Open | 1.0 | -- | |
| Close | 1.0 | Open | |
| Claim | 1.0 | Open | |
| Check Health | 1.0 | Open & Claim | |
| DirectIO | 1.0 | Open | Not Supported |
M-S Serial Cash Drawer Properties
|
Property |
Rev |
Type |
Initialized After |
Notes |
|
Binary Conversion |
1.2 |
Long |
Open |
|
|
Check Health Text |
1.0 |
String |
Open |
|
|
Claimed |
1.0 |
Boolean |
Open |
|
|
DeviceEnabled |
1.0 |
Boolean |
Open |
|
|
FreezeEvents |
1.0 |
Boolean |
Open |
|
|
PowerNotify |
1.3 |
Long |
Open |
|
|
PowerState |
1.3 |
Long |
Open |
|
|
ResultCode |
1.0 |
Long |
-- |
|
|
ResultCodeExtended |
1.0 |
Long |
Open |
|
|
State |
1.0 |
long |
-- |
|
|
ControlObjectDescription |
1.0 |
String |
-- |
|
|
ControlObjectVersion |
1.0 |
Long |
-- |
|
|
ServiceObjectVersion |
1.0 |
Long |
Open |
|
|
DeviceDescription |
1.0 |
String |
Open |
|
|
DeviceName |
1.0 |
String |
Open |
|
|
CapStatus |
1.0 |
Boolean |
Open |
|
|
DrawerOpened |
1.0 |
Boolean |
Open & Enable |
M-S Serial Cash Drawer Registry Values
The following table summarizes the registry values, which govern the behavior of a device instance of the Serial Cash Drawer. The settings control the serial communication interface and must be matched by the hardware settings of the physical device (i.e. the DIP switch settings).
|
Value |
Logical Type |
Default |
Description |
|
Serial Port |
String |
COM1 |
Serial Port to which the Cash Drawer is attached |
|
Parity |
String |
None |
The parity setting of the serial port. Only the first character of this property is actually tested. Valid values are N, O, E, M and S which correspond to None, Odd, Even, Mark and Space |
|
BaudRate |
Number |
9600 (KSI) 1200 (KSC) |
The baud rate of the serial port. This property can take on any numerical value in the range 2400-9600. |
|
DataSize |
Number |
8 |
The data size of the serial port communication. Valid values are 5, 6, 7, and 8. |
|
StopBits |
Number |
1 |
The stop bits of the serial port communication. Valid values are 1, 1.5, and 2. |
|
OpenChar |
Number |
7 |
The ASCII value of the character used to fire open the cash drawer. Valid values are any valid ASCII code 0-255. |
OLE (OBJECT LINKING AND EMBEDDING)
Object Linking and Embedding, or OLE, was first implemented to create and work with compound documents. To the user, a compound document appears in a single Window, as a single set of information, but in reality contains elements created by two or more different applications. Compound documents can be created by linking together two separate documents, or by completely embedding one document in another.
The creators of OLE realized that the compound-document problem was actually a specific example of a more generic problem: that is, how can software components provide services to one another? To address this issue, they created a set of software standards and technologies that could be used with much more than just compound documents, and the most important of these was COM.
Since COM supports the implementation of almost any software technology, it was soon incorporated into technologies that had nothing to do with compound documents, and OLE became a label applied to any COM based technology. In 1996, Microsoft introduced ActiveX as a term associated with the Internet. Because Microsoft based most of these technologies on COM, ActiveX became closely associated with OLE. As a result, the software community soon started to use ActiveX when they were referring to OLE, and now OLE once again refers to technologies associated with compound documents, and ActiveX refers to technologies built around COM.
What is OLE for Retail Point Of Sale?
Object Linking and Embedding (OLE) for Retail Point of Sale (POS) or OPOS, is an interface specification that defines an open driver architecture for hardware devices running under the Windows 95 or Windows NT operating systems. It reduces the time that it takes for you to develop your application, by providing a standard set of software objects which interface it to a wide variety of POS peripherals. These objects allow you to control POS devices without worrying about hardware implementation details, or future upgrades to a specific manufacturer’s hardware. These objects also make it easier for you to incorporate standard Microsoft Windows user interfaces and multitasking capabilities into your POS applications, and allow you to move your application to other hardware platforms with driver objects that comply with the OPOS standard.
Before you can understand OPOS, you need to be able to answer the following questions:
What is Object Linking and Embedding?
What is the Component Object Model?
What is an ActiveX Control?
And, to understand OPOS and its architecture, you must have answers to these questions:
How OPOS Interfaces Your Application to M-S POS Devices?
What Is An OPOS Control?
How Do OPOS Controls Drive Specific M-S POS Devices?
About M-S's OPOS Application Program Interface
This help file supports version 1.0 of the M-S OLE for Retail POS (OPOS) Application Program Interface, which. is based on the Release 1.2 of the International Standard for OPOS.
M-S’s implementation of the OPOS API supports its line of KSI and KSC serial
Cash Drawers
This OPOS API runs on a Windows 95, Windows NT, or other OLE compliant 32-bit operating system
Release 1.0, August 2001
M-S Cash Drawer Corp.
2085, E. Foothill Blvd.
Pasadena CA 91107
(800)-544-1749
The latest revisions of the OLE for Retail POS Application Programmer’s Guide and Control Programmer’s Guide are on the Microsoft Web site at:
http://www.microsoft.com/BUSINESS/solutions/ret/retoposoverview.asp
or on the Wincor- Nixdorf site at:
http://www.wincor-nixdorf.com/eng/products/retail/software/filialloesungen/opos.html
An OPOS Control consists of a Control Object for a device class, which provides the application interface, plus a Service Object, which implements the application interface to a specific device. Thus one Service Object is required to support each specific device instance of a Control Object's device class. Usually, we refer to the combination of a CO and an SO as a "Control." On occasion, when we must distinguish between the actions performed by the Control Object and Service Object the SO or the CO object is specified.
How OPOS Interfaces Your Application to M-S POS Devices?
A M-S OPOS Controls allows your application to communicate with POS Devices (Cash Drawers) via the Windows 95 (or NT) operating system and the M-S OPOS API. The M-S OPOS Controls adhere to the OPOS Control specification, which defines the Properties, Methods and Events that they will expose to your application. The controls are invisible at run time, and rely exclusively upon your application for service requests through methods and sometimes properties. The controls make responses to requests from your application via method return values and parameters, as well as properties and events.
The OPOS specification defines two layers of objects that are interposed between your POS application and the proprietary
M-S Cash Drawers. These intermediate layers include Control Objects, Active-X Controls (*.OCXs) defined by and implemented according to the OPOS standard, and Service Objects, in process servers (*.DLLs) which have been developed by
M-S to interface between the Control Objects and its proprietary Cash Drawers. Each service object drives one
specific group of device instances. For example, one control object represents the cash registers in the system, but there is one service object for each of the types of cash drawers connected to the system, and there is one specific device instance for each device driven.
The application passes a name of the device that it is calling to the Control Object, which uses it to load the corresponding Service Object and to establish an Automation Interface between itself and the Service Object. Parameters from the registry determine the operating characteristics of each device instance spawned by the Service Object.
How Do OPOS Controls Drive Specific M-S POS Devices?
The OPOS Control supplied by M-S include a Control Object and Service Object for Serial Cash Drawers. The Control Object have been implemented by M-S to conform to the OPOS standard. The Control Objects in turn communicate with Service Object, which M-S has developed to interface between the Control Object and its Cash Drawers. The Control Object and their associated Service Objects thus provide standard controls to your application for OPOS device.
A Programmatic ID, is a key that must appear in the "HKEY_CLASSES_ROOT" section of the registry. It must in turn have a sub-key named "CLSID", or Class ID, associated with the Programmatic ID The Class ID must be a key within the "HKEY_CLASSES_ROOT\CLSID" registry section. Sub-keys within this key specify the OLE Automation Server type and instruct OLE how to start the Server.
Properties
An attribute of a control, such as its background color or shape. an attribute, such as a color, zip-code section or the postal-code section of an address, or another object. A property is often hidden
M-S Device Instance Registry Profiles
Each device instance is associated with exactly one registry profile. The registry profile is located in the registry under a specific device class under the OPOS root key as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\OLEforRetail\ServiceOPOS\(Device Class)
where (Device Class) can be any POS device, in this case a Cash Drawer.
In accordance with the OPOS specification, all OPOS registry properties are implemented as string values. However, each property can take on a logical type of String or Number.
Registry profiles allow a single Service Object to control multiple devices of the same type. For instance,
for KSC or KSI class of Cash Drawers we can use either COM1 or COM2 ports so we
can have two device instances for the same class of Cash Drawers.
Common M-S OPOS Registry Values
Several registry values are defined as OPOS standard and found on all the device instances. In addition, there are several M-S OPOS common registry values. The table shows these common device instance registry values.
|
Value |
Logical Type |
OPOS Standard |
Description |
|
(default) |
String |
Yes |
The default value of a device instance key is the OLE Programmatic Class ID of the service Object that will drive the device instance. |
|
Service |
String |
Yes |
This property is set to the filename of the Dynamic Link Library(.DLL) that is the actual Service Object Control. |
|
Description |
String |
Yes |
A Description of the device instance |
|
Version |
String |
Yes |
The Version of the Service Object. This property Indicates what level of the OPOS compliance the service object meets. this can be used to resolve compatibility issues with the control object and host application. This release of the M-S OPOS drivers conforms to version 1.3.0 |
Shareable Device
More than one application can call the methods and access the properties associated with a shareable device. A shareable device may also fire its events to all applications that have opened it. A sharable device may still limit access to some methods or properties to an application that has claimed it, or may fire some events only to this application.
The Service Handler is the name of the in-process server that implements the service object. The Service Handler is implemented using a .DLL file installed in the System 32 directory. The Service Handler Text box is read only.
Service Object
A Control Object calls a Service Object to implement the OPOS-prescribed functions for a specific POS device in its device class. An SO is an Automation server that exposes a set of methods to a CO, to provide hardware dependent control for a specific instance of a device class . It can also call special methods exposed by the CO that fire events to the application.
A Service Object is usually implemented as a local in-process server (as a *.DLL), although it can also be implemented as a local out-of-process server (as a separate executable process, or *.EXE). An out-of-process server is often used when a device is shareable by more than one application, or when the it supports more than one device class. A Service Object may include multiple sets of methods in order to support specific hardware devices with multiple device classes.
The OPOS Test utility is a diagnostic tool which supports testing the device class supported by this release by giving you direct access to the properties and methods for each device instance that you create. You can use it to test device instances and their underlying hardware to eliminate them as a source of symptoms. You can use OPOS Test to exercise one device instance at a time in each device class. The OPOS Test utility is created using the M-S OPOS Control Objects as embedded ActiveX controls. If the user chooses to install the OPOS Test utility, the M-S OPOS Control Objects will be installed by default. The Test program is not a straightforward GUI test application for the M-S PC Workstation devices and their associated device instances. Rather it exposes the properties and methods for each device instance individually , so that you can test it in the same step-by-step sequence used by your application.
The File menu gives you two choices:
· Click on Refresh Device Instances to update the Device Instance: lists for each of the service object types after you have changed the registry using the OPOS Configurator or other registry utility.
· Click on Exit to shut down the OPOS Test program and close the OPOS Test program window.
The M-S OPOS setup program manually or automatically installs the standard OPOS Control Objects, M-S Service Objects and M-S Utility Applications on a workstation, while allowing the installer to choose which components to install using one of three types of installations .
NOTE: Installation puts the M-S OPOS folder in the program listings under Startup. The folder contains shortcuts to components that have been installed.
COM provides versioning by allowing the addition of new interfaces in subsequent versions of an object, while prohibiting changes to existing ones. Existing clients can ignore the new interfaces while using the existing ones, while updated clients can use all of them.
A COM object’s client must acquire a pointer to each interface that it needs to use. To add features to a new version of a COM object, you can simply offer the new features through a new interface. Since COM prohibits changes to the existing interfaces, older clients asking for pointers to those interfaces, but not the new ones, are unaffected. Only new clients know enough to ask for the interfaces that offer new features, so only new clients are affected by the new version.
If a newer client expects an object to provide certain functions, but the object has not been updated to offer it, the client requests a pointer to the interface through which the function would be available, but gets a NULL pointer in return. This gives the client an opportunity to interact with older objects without crashing.
Release 1.0, August 2001
M-S Cash Drawer Corp.
2085, E. Foothill Blvd.
Pasadena CA 91107
(800)-544-1749
© 2001-2002 M-S Cash Drawer Corp. All rights reserved.
