Share via


BumpBar Class

Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)

Usage

'Usage
Dim bumpBar1 As New BumpBar()

Syntax

'Declaration
MustInherit Public Class BumpBar
    Inherits PosCommon
public abstract class BumpBar : PosCommon
public abstract ref class BumpBar : 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 via an automatic tone when a bump bar key is pressed.

Programming Model

The general model of a bump bar is:

  • 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 in conjunction with remote order displays.

    The subsystem can support up to 32 bump bar units.

    One application on one PC or POS terminal is typically used to manage and control the entire subsystem of bump bars. If applications on the same or other PCs and POS terminals must access the subsystem, then 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 attempts 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 where 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 are 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 below for usage.

Input – Bump Bar

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 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 further data events by setting the DataEventEnabled property to FALSE. This causes subsequent 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 gathering 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 DataEvents 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. See the ClearInput method description for more details.

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. Note that this translation must be end-user configurable. The default translated key value is the scan code value.

Output – Tone

The bump bar follows the general Output Model, with some enhancements:

  • 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 occurs:

  • 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 triggers an OutputCompleteEvent. A parameter of this event contains the output ID of the completed request.

    • Asynchronous methods do not return an error status due to a bump bar problem, such as a communications failure. These errors are only reported by an ErrorEvent. 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 due to an application error, while the last is a serious system resource exception.

    • If an error occurs while performing an asynchronous request, an ErrorEvent is fired. The EventUnits property is set to the unit or units in error. The EventString property is also set.

      Note   ErrorEvent updates EventUnits and EventString. If an error is reported by a broadcast method, then ErrorUnits and ErrorString are set instead.

The event handler can call synchronous bump bar methods (but not asynchronous methods), then 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. OutputCompleteEvents are not triggered for cleared output. When 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:

  • The application must claim the device before enabling 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 calling methods that manipulate the device.

  • When a ClaimDevice method is called again, settable device characteristics are restored to their condition at ReleaseDevice.

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.

Platforms

Development Platforms

Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Longhorn, and Windows 2000

Target Platforms

See Also

Reference

BumpBar Members
Microsoft.PointOfService Namespace