none
KeyDown-Ereignis RRS feed

  • 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 Hilfe

    Mit freundlichen Grüssen
    ro_grille


    Lebe Dein Leben beständig, Du bist länger Tod als lebendig.

    Samstag, 23. Juni 2012 08:48

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
    Dienstag, 26. Juni 2012 13:15

Alle Antworten

  • Hallo ro_grille,

    versuche es so:

    If e.KeyCode = Keys.Enter Then

    KeyData ist nicht dasselbe.

    Gruss Ellen


    Ich benutze/ I'm using VB2008 & VB2010

    Samstag, 23. Juni 2012 09:07
  • Hallo Ellen,
    habe den Code angepasst, bin gespannt, ob es Montag funktioniert ;).
    Feedback kommt.

    Danke

    Mit freundlichen Grüssen
    ro_grille


    Lebe Dein Leben beständig, Du bist länger Tod als lebendig.

    Samstag, 23. Juni 2012 09:12
  • Hallo Ellen,

    hat leider nicht funktioniert, muss immer noch manuell "Enter" drücken?

    Mit freundlichen Grüssen
    ro_grille


    Lebe Dein Leben beständig, Du bist länger Tod als lebendig.

    Montag, 25. Juni 2012 11:58
  • 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

    Montag, 25. Juni 2012 16:41
  • 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_grille


    Lebe Dein Leben beständig, Du bist länger Tod als lebendig.

    Dienstag, 26. Juni 2012 10:59
  • 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
    Dienstag, 26. Juni 2012 13:15
  • 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_grille


    Lebe Dein Leben beständig, Du bist länger Tod als lebendig.

    Freitag, 29. Juni 2012 15:19