|
| Home |
|
|
Win32 Console I/ORTTarget-32 installs its own keyboard interrupt handler on IRQ 1 when any file I/O or console I/O function is first called (usually through the run-time system's startup code). Reading keyboard input will only work if the target hardware has an IBM-PC compatible keyboard controller at the default I/O port addresses or if some other software calls RTInsertKeyboardScanCode. RTTarget-32's keyboard interrupt handler is optimized for low interrupt latency. US, German, French, Spanish, Italians, and Portuguese keyboard layouts are supported. The keyboard layout can be changed using function SetThreadLocale, RTSetFlags, or hotkeys. The default keyboard layout is US. Example:
SetThreadLocale(MAKELCID(
MAKELANGID(LANG_GERMAN, SUBLANG_GERMAN),
SORT_DEFAULT));
SetThreadLocale(MAKELCID(
MAKELANGID(LANG_FRENCH, SUBLANG_FRENCH),
SORT_DEFAULT)),
The keyboard layout can also be set with the RTTarget-32 system flags (see section RTTarget-32 Flags in the RTTarget-32 Reference Manual). The keyboard driver also supports switching languages using hotkeys: left Ctrl-Alt-F1 (US), Ctrl-Alt-F2 (German), Ctrl-Alt-F3 (French), Ctrl-Alt-F4 (Spanish), Ctrl-Alt-F5 (Italian), Ctrl-Alt-F6 (Portuguese), etc. Installing alternate keyboard translation tables is supported through function RTSetKeyboardTables. The keyboard driver supports entering numeric character values (key composing) on the numeric keypad when the left ALT key is held down. Once the ALT key is released, the desired key is generated. Numeric values greater 255 are interpreted as Unicode. Values entered with a leading '0' are interpreted using the current input code page. All others used OEM code page 437. For some languages, key combining is also supported. For example, using the German keyboard driver, pressing ´ followed by a produces á. The default input code page used is 437 (OEM). Function RTSetCodepageTranslation can be used to change the code page. RTTarget-32's keyboard driver is linked to the application by default, but it does occupy quite a lot of memory. For targets which do not need a keyboard, it can be eliminated by including the following function into the EXE/DLL which links Rtt32.lib:
void RTTAPI RTGetKeyEvents(void) {}
Mouse events are only available if the program has explicitly called function RTInitTextMouse. When the program is waiting for keyboard input, RTTarget-32 will display a cursor. However, this feature only works with a standard CRT monochrome or color display adapter. By default, this feature is automatically enabled if a video RAM at address B0000h or B80000h is used. If a video controller incompatible with the IBM-PC is used, but you still want to use a video RAM at those addresses, RTTarget-32 flag RT_CRT_NO_ACCESS must be set either through RTSetFlags or through a global instance of RTTarget32Flags. Console Input Event ManagementRTTarget-32 contains a flexible user event (keyboard and mouse) management. Both the keyboard and mouse drivers are interrupt driven. By default, the interrupt handlers will only retrieve the raw event data from the hardware and place it in a buffer. Each time the application program checks for user input, these buffers are processed and interpreted to build Win32 event structures (structure INPUT_RECORD). The advantage of RTTarget-32's delayed event processing is a very low interrupt latency; however, events are not always processed immediately. For example, if the application does not check for user events for a long time, mouse movements on the screen will be erratic. If you prefer smooth mouse movements and can tolerate higher interrupt latencies, you can instruct the drivers to process events within the interrupt handlers (that is, immediately). This is achieved by setting the RTTarget-32 system flags RT_KEY_BY_INTERRUPT and/or RT_MOUSE_BY_INTERRUPT using function RTSetFlags. The Win32 event reading functions such as ReadConsoleInput will call the following RTTarget-32 function to update the event queue: void RTProcessEvents(void); RTProcessEvents is actually not required if both drivers run with their respective RT_KEY_BY_INTERRUPT and RT_MOUSE_BY_INTERRUPT flags set. However, if they are not set, the application can also call RTProcessEvents to update the event queue and process all pending keyboard and mouse events. RTTarget-32 defines a few event hooks which are called on various events: extern void (RTTAPI * RTGetMouseEvents)(void); extern void (RTTAPI * RTSignalEvent)(void); extern void (RTTAPI * RTWaitEvent)(void); extern void (RTTAPI * RTNewEvents)(void); *RTGetMouseEvents is called by RTProcessEvents to get mouse events. *RTSignalEvent is called by interrupt handlers of the drivers to signal that RTProcessEvent should be called because new unprocessed event are now available. *RTWaitEvent is called by ReadConsoleInput when no events are available. *RTNewEvents is called by WriteConsoleInput when new INPUT_RECORD events are placed in the event queue. All hooks given above are initialized to point to dummy (do nothing) routines. The mouse driver will install a routine on RTGetMouseEvents which will process any pending mouse events and write them to the user event queue using WriteConsoleInput.
|
