PosExplorer Class
Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)
Usage
'Usage
Dim posExplorer1 As New PosExplorer()
Syntax
'Declaration
NotInheritable Public Class PosExplorer
public sealed class PosExplorer
public sealed ref class PosExplorer
public final class PosExplorer
public class PosExplorer
Remarks
PosExplorer is used by applications to acquire a list of installed POS devices, create instances of service objects for those devices, and receive Plug-n-Play events when the devices are connected or disconnected from the system.
When using PosExplorer, there are five possible usage scenarios from within an application. An application can:
Assume there is only one device of a type attached, or use only one device of a type and default devices are configured.
Use logical device names.
Dynamically attach all available input devices.
Handle all hardware configurations.
Use a combination of these scenarios for different device types.
Scenario 1
In this scenario, an application assumes one device of a type attached to the machine. For this scenario, you can get the device as follows:
Msr msr;
PosExplorer explorer = new PosExplorer();
DeviceInfo deviceInfo = explorer.GetDevice(DeviceType.Msr);
if (deviceInfo == null)
<report failure>;
else
msr = PosExplorer.CreateInstance(deviceInfo) as Msr;
msr.Open();
In this example, if more than one MSR device is attached to the system, GetDevice throws an exception. The advantage of this scenario is that no configuration is required.
Scenario 2
The code for this scenario is the same as that in Scenario 1; however, if there are multiple MSR devices attached and one is set as default, GetDevice will not throw an exception and will return a DeviceInfo object for the default MSR.
Scenario 3
An application may use logical device names. The names must be preconfigured (created) via WMI or Posdm before the application is run. The logical names the application uses for opening devices can be either hardcoded in the application or, better, can be defined in an application's configuration file <app name>.exe.config. In the latter case, the application reads the names from the config file by means of the .NET Framework ConfigurationSettings class. Because the names are defined in the XML configuration file, administrators can see and change them if necessary to avoid possible naming conflicts in case of multiple applications running on the same device in the same manner they configure other .NET applications. The following code gets the device:
string myMsrName = <get the name>;
Msr msr;
PosExplorer explorer = new PosExplorer();
DeviceInfo deviceInfo = explorer.GetDevice( DeviceType.Msr, myMsrName );
if( deviceInfo == null )
<report failure>
else
msr = PosExplorer.CreateInstance( deviceInfo ) as Msr;
msr.Open();
Scenario 4
For input devices, an application can enumerate and attach all available peripherals, provided it doesn't matter from which, for example, of two MSRs it receives card swipes from:
ArrayList msrs = new ArrayList ();
PosExplorer explorer = new PosExplorer();
DeviceCollection devices = explorer.GetDevices( DeviceType.Msr );
foreach( DeviceInfo deviceInfo in devices )
{
Msr msr = PosExplorer.CreateInstance( deviceInfo ) as Msr
msrs.Add( msr );
msr.Open();
}
Scenario 5
Alternatively, an application can handle all hardware configuration itself. It can enumerate all available devices of all types it can use and ask the user to make choices where there is ambiguity and then persist this configuration to its own configuration store. Then, when the application runs, it enumerates all available devices by calling GetDevices( <type> ), detects if any devices were added/removed, and updates its persisted configuration. In ambiguous cases of multiple devices of a type it may require user selection. This approach can be used in conjunction with the above example so that all input devices are handled automatically and persisted configuration is used only for output devices.
Inheritance Hierarchy
System.Object
Microsoft.PointOfService.PosExplorer
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