BumpBar Class (POS for .NET v1.12 SDK Documentation)
2/27/2008
Defines the programmatic interface for a UPOS Bump Bar device.
Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)
Syntax
'Declaration
Public MustInherit Class BumpBar
Inherits PosCommon
public abstract class BumpBar : PosCommon
public ref class BumpBar abstract : public PosCommon
public abstract class BumpBar extends PosCommon
public abstract class BumpBar extends PosCommon
Remarks
BumpBar supports broadcast methods that can communicate with one, a range, or all online bump bar units. BumpBar also supports bump bar input (keys 0-255).
BumpBar may also support bump bar enunciator output with frequency and duration, and tactile feedback through an automatic tone when a bump bar key is pressed.
Programming Model
The general model of a bump bar is as follows:
The BumpBar device class is a subsystem of bump bar units. The initial targeted environment is food service, to control the display of order preparation and fulfillment information. Bump bars typically are used together with remote order displays.
The subsystem can support up to 32 bump bar units.
One application on one computer or POS terminal is typically used to manage and control the subsystem of bump bars. If applications on the same or other computers and POS terminals must access the subsystem, this application must act as a subsystem server and expose interfaces to other applications.
All specific methods are broadcast methods. This means the method can apply to one unit, a selection of units, or all online units. The UnitsOnline property is a DeviceUnits enumeration, with each enumerator identifying an individual bump bar unit. (One or more of the constants Unit1 through Unit32 are bitwise ORed to form the bitmask.) The service object tries to satisfy the method for all unit(s) indicated in the UnitsOnline property. If an error is received from one or more units, the ErrorUnits property is updated with the appropriate units in error. The ErrorString property is updated with a description of the error or errors received. The method then returns with the corresponding error. In the case in which two or more units encounter different errors, the service object should determine the most severe error to return.
The ClearInput and ClearOutput methods (and the common method CheckHealth) are not broadcast methods and use the unit ID indicated in the CurrentUnitId property. (One of the enumerators Unit1 through Unit32 is selected.) See the description of these methods to understand how the CurrentUnitId property is used.
When the CurrentUnitId property is set by the application, all the corresponding properties are updated to reflect the settings for that unit.
If the CurrentUnitId property is set to a unit ID that is not online, the dependent properties contain non-initialized values.
The CurrentUnitId property uniquely represents a single bump bar unit. The definitions range from Unit1 to Unit32. These definitions are also used to create the bitwise parameter, Units, used in the broadcast methods. See the Examples section in this topic for usage.
The bump bar follows the general "Input Model" for event-driven input with some differences:
When input is received by the service object, it queues a DataEvent event.
This device does not support the AutoDisable property. So, the device does not automatically disable itself when a DataEvent is queued.
A queued DataEvent event can be delivered to the application when the DataEventEnabled property is true and other event delivery requirements are met. Just before delivering this event, the service object copies the data into properties and disables additional data events by setting the DataEventEnabled property to false. This causes later input data to be queued while the application processes the current input and associated properties. When the application has finished the current input and is ready for more data, it re-enables events by setting DataEventEnabled to true.
An ErrorEvent or events are queued if the service object encounters an error while collecting or processing input, and are delivered to the application when the DataEventEnabled property is true and other event delivery requirements are met.
The BumpBarDataCount property can be read to obtain the number of bump bar DataEvent entries for a specific unit ID queued by the service object. You can read the DataCount property to obtain the total number of data events queued by the service object.
You can delete queued input by calling the ClearInput method.
The Bump Bar service object must supply a mechanism for translating its internal key scan codes into user-defined codes that are returned by the DataEvent. Notice that this translation must be end-user configurable. The default translated key value is the scan code value.
The bump bar follows the general Output Model, with some improvements:
The BumpBarSound method is performed either synchronously or asynchronously, depending on the value of the AsyncMode property. When AsyncMode is false, BumpBarSound operates synchronously and returns its completion status to the application.
When AsyncMode is true, the following operations occur:
- The service object buffers the request, sets the OutputId property to an identifier for this request, and returns as soon as possible. When the device completes the request successfully, the service object updates the EventUnits property and raises an OutputCompleteEvent event. A parameter of this event contains the output ID of the completed request.
Asynchronous methods do not return an error status because of a bump bar problem, such as a communications failure. These errors are only reported by an ErrorEvent event. An error status is returned only if the bump bar is not claimed and enabled, a parameter is invalid, or the request cannot be queued. The first two error cases are because of an application error, while the last is a serious system resource exception.
If an error occurs when you perform an asynchronous request, an ErrorEvent event is raised. The EventUnits property is set to the unit or units in error. The EventString property is also set.
Note ErrorEvent updates the EventUnits and EventString properties. If an error is reported by a broadcast method, the ErrorUnits and ErrorString properties are set instead.
The event handler can call synchronous bump bar methods, but not asynchronous methods, can either retry the outstanding output or clear it.
The service object guarantees that asynchronous output is performed on a first-in, first-out basis.
You can delete all output buffered by the service object by setting the CurrentUnitId property and calling the ClearOutput method. OutputCompleteEvent events are not raised for cleared output. When it is possible, the ClearOutput method stops any output that may be in progress.
Device Sharing
The bump bar is an exclusive-use device. Its device-sharing rules are as follows:
The application must claim the device before the application enables it.
The application must claim and enable the device before accessing many bump bar-specific properties.
The application must claim and enable the device before it calls methods that manipulate the device.
When the Claim method is called again, settable device characteristics are restored to their condition at Release.
Inheritance Hierarchy
System.Object
Microsoft.PointOfService.PosDevice
Microsoft.PointOfService.PosCommon
Microsoft.PointOfService.BumpBar
Microsoft.PointOfService.BasicServiceObjects.BumpBarBasic
Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread-safe. Any instance members are not guaranteed to be thread-safe.