Nicht ganz einfach bei der Erstellung eines Tastaturmakrorecorders ist
folgendes Problem:
Tastaturstatusabfragen (Int16 Funktion 01 oder 11) können von Programmen
auf 2 Weisen verwendet werden:
1. Gewöhnliche Abfrage
Hierbei wird im Polling der Status abgefragt. Alternativ könnte auch direkt
(mit Warten auf Taste) das BIOS gefragt werden (ReadKey). Damit schneidet
sich der Programmierer allerdings den Weg ab, bspw. in einer objektorien-
tierten Benutzerschnittstelle auch auf weitere Ereignisse reagieren zu können,
wie z.B. Mausereignisse, Zeittakte und das Erfassen des Drückens von
CTRL, SHIFT oder ALT zum Umschalten auf die Menüleiste.
Allerdings könnte es auch Programme geben, die für Tasteneingaben ausschließ-
lich die Funktion 16/00 bzw. 16/10 verwenden. Hierfür werde ich im Programm
MREC einen Schalter vorsehen.
2. Abfrage während einer Aktion
Das Programm PROFIB.EXE z.B. fragt während des Druckvorgangs ständig die
Tastatur ab, ob eine Taste gedrückt wurde, und leert den Tastaturpuffer
gegebenfalls. Bloß wie soll man den Unterschied zum Fall 1. feststellen???
Nach außen ist dies absolut dasselbe Verhalten!
Nämlich in Turbo Pascal:
{$X+} (1)
for i:=1 to irgendwohin do begin
TuIrgendwas;
If KeyPressed then If ReadKey=0 then ReadKey;
{Tastaturpuffer stets leeren!}
end;
Das Tastaturabfrageprogramm macht "dagegen":
{$X+} (2)
repeat until keypressed;
C1:=ReadKey; {ASCII-Code}
if C1=0 then C2:=ReadKey; {Scan-Code erweiterte Tastatur}
Lösungen:
1. Der Interrupt 16/01 bzw. 16/11 meldet *stets* "Keine Taste", d.h.
die TP-Fkt. KeyPressed meldet ständig FALSE. Läßt Programme mit dem
Programmstück (2) aufhängen, leider.
Um beim Test nicht RESET drücken zu müssen, ist eine normale
Tastaturabfrage zum Ausbruch aus der Schleife erforderlich
2. Der Interrupt 16/01 bzw. 16/11 meldet eine gewisse (ausreichend hohe)
Anzahl an "Keine Taste", bis er die nächste Taste "zum Verkauf" feilbietet.
Dies funktioniert recht universell, es ist aber ein verteufelter
Kompromiß zu schließen:
- Die Zahl ist *so* hoch zu wählen, daß während eines Jobs keine Taste
(mehr) emuliert wird (korrekte Funktion der Routine (1)).
- Bei einer hohen Zahl dauert die Routine (2) sehr lange; oft viel länger
als bei normaler Tastatureingabe
Als Lösung hierfür könnte man die *echte* Tastatur abfragen und bei gedrückter
Taste einen Ausbruch aus dieser Schleife erzwingen (siehe Lösung 1)
3. Ausnutzen könnte man, daß bei Druckjobs sich auf dem Bildschirm etwas
ändert, z.B. eine Zahl hochläuft oder eine Balkengrafik sich verändert.
Man könnte wiedergabeseitig (?) diese Veränderung benutzen, um den Zähler
zurückzusetzen, der ansonsten analog zu Lösung 2 die Leseversuche zählen
muß.
4. Die Umschaltung der Anzahl könnte dynamisch während der Emulation geschehen.
Die Registrierung ist jedoch nicht während der Aufnahme möglich, sodaß
der entsprechende Befehl nachträglich in die Steuerdatei eingefügt werden
muß.
Weitere Probleme und Lösungen:
- Die Tastenanschläge sind jedermann zugänlich; Paßwörter stehen praktisch
im Klartext im Tastenfile. (Lösung: Scrambeln, was sonst!!)
- Das Tastaturfile kann also in 3 Arten vorkommen:
+ als editierbare ASCII-Datei ("Text")
+ als Binärdatei mit Tastencodes ("File of Integer")
+ als gescrambelte Binärdatei (Dateiaufbau ist natürlich geheim!)
Umwandlungsmöglichkeit muß via MREC möglich sein!
| Vorgefundene Kodierung: OEM (CP437) | 1
|
|
|