Benutzer mit den meisten Antworten
KeyDown-Ereignis

Frage
-
Hallo,
ich habe ein kleines Programm geschrieben, wo in eine Textbox ein Barcode (Handscanner) eingelesen wird.
Nach dem Einlesen wird über das KeyDown-Ereignis (Entertaste) automatisch eine Prozedur gestartet.
Private Sub txtBC_KeyDown(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) Handles txtBC.KeyDown If e.KeyData = Keys.Enter Then Call cmdScan_Click(Nothing, Nothing) End If End Sub
Das funktioniert auch alles prima, aber bei einem Kollegen wurde der Rechner neu aufgesetzt (mit Tastatur+Maus), funktioniert nicht mehr?
D.h. man muss die Entertaste drücken, damit die Prozedur gestartet wird.
Kann es mit der Tastenbelegung der Tastatur zusammen hängen?
Bei "Key.Enter" im Code wird "Enter as System.Windows.Forms.Key = 13" angezeigt.
Gibt es bei den Tastaturen eine nummerische Tastenbelegung (Entertaste = 13), welche angepasst werden muss?
Danke für die HilfeMit freundlichen Grüssen
ro_grilleLebe Dein Leben beständig, Du bist länger Tod als lebendig.
Antworten
-
Hallo ro_grille,
das ist ist ein ganz anderer Sachverhalt jetzt. Die Ursache für Dein Problem ist nicht in der Textbox event handle Prozedur zu finden. Diese ist ja nur ein Parallelzweig für die Übernahme von Daten. Die stört nicht und funktioniert ja auch. Wichtig ist die Übernahme der Datern geschieht woanders und nicht hier.
Wenn ich mir diese Funktion ansehe Call cmdScan_Click(Nothing, Nothing)
erkenne ich darin eine weitere event handle Prozedur, welche Du benutzt. Kannst Du die mal posten? Entweder wird diese wird garnicht ausgeführt, weil das event fehlt oder diese ist fehlerhaft.In einer produktiven Anlage einen Fehler zu finden ist keine dankbare Aufgabe. Ich kenne das. Das ist eben nicht nur Labortisch oder Entwicklungsbüro. Weitere mögliche Vorgehensweise:
1. geladene Assemblies ermitteln
einen Programmierfehler in das Programm einbauen, der zu einer unbehandelten Ausnahme führt. Die Bedingung kennst nur Du. Dann erhälst Du eine Liste aller gelandenen Assemblies. So kannst Du NET Framework als möglichen Fehler ausschliessen. (das geht bestimmt auch eleganter, ich weis)
2. Fallen setzen
An allen wichtigen Progammstellen Markierungen erzeugen. Das können Ausgaben sein in eine versteckte Textbox. So kannst Du feststellen, ob ein Programm eine bestimmte Stelle erreicht oder eben nicht.
3. Debug Version verteilen und nicht die Release.
4. Option Strict ON
Der Vollständigkeit halber möchte ich das erwähnen. Wenn Du diesen Schalter nicht gesetzt hast, kann es zur Laufzeit zu Problemen führen. Ankommende Daten werden nicht korrekt verarbeitet. Daher sollte man grundsätzlich die Typenkonvertierung selber kontrollieren und nicht dem Compiler überlassen
Poste erst einmal den code.
Eine Möglichkeiten Dein Programm anders zu gestalten wäre das TextChanged event zu verwenden
Dann könntest Du auch mit dem Like-Operator (Visual Basic) arbeiten und die Barcodedaten noch einmal verifizieren.
Gruss Ellen
Ich benutze/ I'm using VB2008 & VB2010
- Bearbeitet Ellen Ramcke Donnerstag, 28. Juni 2012 13:48 Nachtrag
- Als Antwort markiert ro_grille Freitag, 29. Juni 2012 15:09
Alle Antworten
-
Hallo ro_grille,
das ist ja merkwürdig. Die Entertaste sollte bei allen Tastaturen gleich belegt sein. Hier ein Beitrag von Peter: http://social.msdn.microsoft.com/Forums/de-DE/vbasicexpresseditionde/thread/19e1497d-65b8-4875-9159-c17de4972704
Jetzt verstehe ich was nicht in Deiner Frage:
"Das funktioniert auch alles prima, aber bei einem Kollegen wurde der Rechner neu aufgesetzt (mit Tastatur+Maus), funktioniert nicht mehr?
D.h. man muss die Entertaste drücken, damit die Prozedur gestartet wird.
Kann es mit der Tastenbelegung der Tastatur zusammen hängen?
Bei "Key.Enter" im Code wird "Enter as System.Windows.Forms.Key = 13" angezeigt.
Gibt es bei den Tastaturen eine nummerische Tastenbelegung (Entertaste = 13), welche angepasst werden muss?"Also Ihr benutzt eine andere Tastatur. Wie soll denn die Prozedur gestartet werden wenn nicht mit der Entertaste? Das scheint doch aber zu gehen?
Gruss Ellen
Ich benutze/ I'm using VB2008 & VB2010
-
Hallo Ellen,
ich habe mal zum besseren Verständnis ein Bild angehangen.
Der Kursor bleibt in der Textbox stehen (blinkt), obwohl lt. Code automatisch die Prozedur starten sollte.
An allen Werkstatt-PC funktioniert das Scannen tadelos, ohne die Enter-Taste zu drücken [kann man auch keinem zumuten ;-)], nur bei dem
einen Rechner nicht? Die Tastatur ist "normal" wie alle anderen Tastaturen.
Kann es vielleicht auch was mit dem Net.Framework zu tun haben, Version auf dem Rechner?
Ich habe keine Ahnung oder Idee mehr woran das liegen könnte?Mit freundlichen Grüssen
ro_grilleLebe Dein Leben beständig, Du bist länger Tod als lebendig.
-
Hallo ro_grille,
das ist ist ein ganz anderer Sachverhalt jetzt. Die Ursache für Dein Problem ist nicht in der Textbox event handle Prozedur zu finden. Diese ist ja nur ein Parallelzweig für die Übernahme von Daten. Die stört nicht und funktioniert ja auch. Wichtig ist die Übernahme der Datern geschieht woanders und nicht hier.
Wenn ich mir diese Funktion ansehe Call cmdScan_Click(Nothing, Nothing)
erkenne ich darin eine weitere event handle Prozedur, welche Du benutzt. Kannst Du die mal posten? Entweder wird diese wird garnicht ausgeführt, weil das event fehlt oder diese ist fehlerhaft.In einer produktiven Anlage einen Fehler zu finden ist keine dankbare Aufgabe. Ich kenne das. Das ist eben nicht nur Labortisch oder Entwicklungsbüro. Weitere mögliche Vorgehensweise:
1. geladene Assemblies ermitteln
einen Programmierfehler in das Programm einbauen, der zu einer unbehandelten Ausnahme führt. Die Bedingung kennst nur Du. Dann erhälst Du eine Liste aller gelandenen Assemblies. So kannst Du NET Framework als möglichen Fehler ausschliessen. (das geht bestimmt auch eleganter, ich weis)
2. Fallen setzen
An allen wichtigen Progammstellen Markierungen erzeugen. Das können Ausgaben sein in eine versteckte Textbox. So kannst Du feststellen, ob ein Programm eine bestimmte Stelle erreicht oder eben nicht.
3. Debug Version verteilen und nicht die Release.
4. Option Strict ON
Der Vollständigkeit halber möchte ich das erwähnen. Wenn Du diesen Schalter nicht gesetzt hast, kann es zur Laufzeit zu Problemen führen. Ankommende Daten werden nicht korrekt verarbeitet. Daher sollte man grundsätzlich die Typenkonvertierung selber kontrollieren und nicht dem Compiler überlassen
Poste erst einmal den code.
Eine Möglichkeiten Dein Programm anders zu gestalten wäre das TextChanged event zu verwenden
Dann könntest Du auch mit dem Like-Operator (Visual Basic) arbeiten und die Barcodedaten noch einmal verifizieren.
Gruss Ellen
Ich benutze/ I'm using VB2008 & VB2010
- Bearbeitet Ellen Ramcke Donnerstag, 28. Juni 2012 13:48 Nachtrag
- Als Antwort markiert ro_grille Freitag, 29. Juni 2012 15:09
-
Hallo Ellen,
gute Nachrichten, dass Problem ist gelöst.
Anstoß war Dein Satz:
"Wichtig ist die Übernahme der Datern geschieht woanders und nicht hier."
Es lag am Handscanner !!!!!!!!!!!!!!
Wir haben einfach mal den Scanner getauscht (von Werkstatt-PC) und siehe da es funktioniert.
Rückfrage bei unserm IT-Verantwortlichen ergab, dass er den angeschlossenen H-Scanner nicht so
konfiguriert hatte wie bei den Werkstatt-Scannern (Enter Übergabe der Daten deaktiviert)!!Ich bedanke mich für Deine freundliche Hilfe und wünsche ein schönes, heisses WE ... ;-)
... und, bis zum nächsten Problem ...Mit freundlichen Grüssen
ro_grilleLebe Dein Leben beständig, Du bist länger Tod als lebendig.