OLE Windows NT Keyboard Integration Toolkit

OLE Windows Toolkit

The Access IS range of Active X keyboard controls allows full and easy integration of Access hardware into your Windows application. This allows the user to instruct the system to deliver all keystrokes as events directly regardless of focus or other applications that may be running on the system.


The keyboard hardware has an additional 'wedge' socket that acts as an AT host allowing connection of any standard keyboard (even when the system is live) .


Keystrokes from the keyboard connected to the wedge can be blocked or passed through to be processed by Windows.



Windows NT, 2000 and XP presents many barriers when integrating keypads to generate robust and secure applications. Access Keyboards ActiveX Keyboard Toolkit provides the following functionality via the keyboard port with just a few lines of code:


  • Compatible with any Windows programming language
  • The master keypad has device status which allows it to be exclusively claimed
  • Keyboard events are reported to the controlling application regardless of foreground focus
  • Disable (lock) the keyboard and/or the wedge keyboard
  • Queuing of keyboard events until the application is ready to process or discard the events
  • Inhibit windows control functions
  • Control the keyboard auxiliary serial port
  • Sound internal keyboard beeper with a variety of standard beeps (useful if keyboard is remote from system unit)
  • Control up to status four LEDs on the keyboard
  • Momentary layer shift and 'sticky' shift keys to extend keyboard key combinations
  • Full tracking of six position key lock
  • Support for a standard layout 'slave' keyboard that operates in standard NT mode


Keyboard Controller Hardware


Standard Features

  • Standard PC/AT or PS/2 Interface
  • Slave keyboard 'wedge' port
  • Also available for USB interface keyboards


  • Slave RS232 serial interface
  • + 5V DC 150mA peripheral power output
  • Up to four LED indicators
  • Six-position key lock
  • Integrated two-track magnetic swipe reader (MSR)


How an Application Uses the Control

The first action the application must take on the control is to call its Open method. The parameter of this method selects a device name to associate with the Control. The Open method performs the following steps:


Establishes a link to the device name.


Initialises the properties Claimed, Device Enabled, Data Event Enabled, Freeze Events, Auto Disable, Data Count, and Binary Conversion, as well as descriptions and version numbers of the ActiveX Control layers. Additional class-specific properties may also be initialised.


Several applications may have the Control open at the same time. Therefore, after the device is opened, the application will often need to call the Claim method to gain exclusive access to the device. Many devices must be Claimed before the Control allows access to its methods and properties. Claiming the device ensures that other applications do not interfere with the use of the device. 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. This value brings the device to an operational state, while FALSE disables the device. For example, if the Keyboard Control is disabled, then the device will be physically disabled (when possible). 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 access controls.