PosExplorer Class
2/27/2008
Defines the programmatic interface for enumeration and initialization of POS installed devices.
Namespace: Microsoft.PointOfService
Assembly: Microsoft.PointOfService (in microsoft.pointofservice.dll)
Syntax
'Declaration
Public NotInheritable Class PosExplorer
public sealed class PosExplorer
public ref class PosExplorer sealed
public final class PosExplorer
public final class PosExplorer
Remarks
The PosExplorer class is used by applications to obtain a list of installed POS devices, create instances of service objects for those devices, and receive Plug and Play events when the devices are connected or disconnected from the system.
When you use the PosExplorer class, there are five possible usage scenarios in an application. An application can do the following:
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 computer. 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 = explorer.CreateInstance(deviceInfo) as Msr;
msr.Open();
In this example, if more than one MSR device is attached to the system, the GetDevice method 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, the GetDevice method does not throw an exception and returns a DeviceInfo object for the default MSR.
Scenario 3
An application may use logical device names. The names must be preconfigured (created) through WMI or Posdm before the application is run. The logical names the application uses for opening devices can be either hard-coded in the application or, better, can be defined in an application's configuration file <application name>.exe.config. In the latter case, the application reads the names from the configuration file by 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. If multiple applications that are running on the same device in the same manner, they configure other.NET Framework 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 = explorer.CreateInstance( deviceInfo ) as Msr;
msr.Open();
Scenario 4
For input devices, an application can enumerate and attach all available peripherals, provided it does not matter from which, for example, of two MSRs it receives card swipes from the following code.
ArrayList msrs = new ArrayList ();
PosExplorer explorer = new PosExplorer();
DeviceCollection devices = explorer.GetDevices( DeviceType.Msr );
foreach( DeviceInfo deviceInfo in devices )
{
Msr msr = explorer.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 together with this 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.