unbeabsichtigter Focus auf Textbox bei programmgesteuertem Wechsel des Tabs in TabControl

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Frequentprogrammer.

    unbeabsichtigter Focus auf Textbox bei programmgesteuertem Wechsel des Tabs in TabControl

    Habe aktuell wieder einen interessanten Effekt:

    ​Habe ein TabControl mit mehreren Reitern. Wenn ich nun programmgesteuert mit .SelectedIndex = X auf einen anderen Tab wechsle, setzt mir VB.NET auf die TextBox mit dem niederwertigsten TabIndex den Focus. Wäre ja nicht weiter schlimm, wenn ich danach nicht ein Validating Ereigniss auf der TextBox hätte. Dieses wird nun zu früh ausgelöst und der Code des Validation-Ereignisses wird überflüssigerweise durchlaufen. In meinem Fall wird nun eine Reaktion erzeugt, die ich zu diesem Zeitpunkt nicht haben möchte.

    ​Gibt es in den Properties der TextBox oder des TabControls eine Möglichkeit dies zu unterdrücken? Vorher den Focus auf ein anderes Control legen reicht nicht aus, da er mir trotzdem noch in das Validation Ereignis springt.

    ​Jede Hilfe ist herzlich willkommen.

    ​Gruß Frequentprogrammer
    @Frequentprogrammer Kann es sein, dass da beim Wechsel noch ein unbeabsichtigter Tastendtuck gesendet wird?
    Probier mal, den Fokus beim Wechsel des Tabs auf ein Dir genehmes Control zu setzen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Frequentprogrammer schrieb:

    Wie könnte das Passieren?
    Irgend was passiert da:
    da er wieder auf die TextBox mit dem niedrigsten TabIndex springt.
    Das solltest Du aufklären.
    Irgend eine Zeile Code, die nicht das macht, was Du glaubst, was sie machen soll.
    Kannst Du das Projekt posten?
    Oder zumindest so abrüsten, dass Dein Effekt noch reproduziert wird?
    nÚnd das Projekt bitte bereinigen, damit der VB-Server nicht zugemüllt wird.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Puh, sind mittlerweile so an die 15.000 Zeilen Code in 11 Forms. Der Effekt tritt zur Verkomplizierung auch noch über einen Formwechsel auf.
    Das mit dem Abspecken habe ich mir auch überlegt - ist ein guter Rat, wenn man andere zum Nachdenken anregen will. Würde den Punkt dann wahrscheinlich auch selbst finden. Ist eben sehr zeitintensiv und hatte gehofft mit ein paar cleveren Ratschlägen von klugen Köpfen im Forum schneller voran zu kommen.

    Irgend eine Idee, wie ich den Programmablauf loggen kann, bzw. wenn ich ein TextBox.Enter Event erzeuge, wie kann ich nachvollziehen woher der Einsprung kommt?

    ​Nachtrag: Habe es mit TextBox.Enter versucht. Habe die Zeile aus der der Einsprung kommt anscheinend identifiziert und komme dem Thema irgendwie doch nicht näher, da der Debugger mir eine "END IF" Zeile anzeigt, er die IF Abfrage aber gar nicht durchläuft, da false?!?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Frequentprogrammer“ ()

    Frequentprogrammer schrieb:

    cleveren Ratschlägen von klugen Köpfen
    Das hängt sehr von Deinem Code ab, den wir nicht kennen.
    Loggen: Console.WriteLine("..."), im Ausgabefenster des Studios,
    oder in eine Datei:

    VB.NET-Quellcode

    1. System.IO.File.AppendAllText(path,content)
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Frequentprogrammer schrieb:

    Dieses wird nun zu früh ausgelöst und der Code des Validation-Ereignisses wird überflüssigerweise durchlaufen. In meinem Fall wird nun eine Reaktion erzeugt, die ich zu diesem Zeitpunkt nicht haben möchte.
    Glaub jedes Control hat eine CausesValidation - Property. Steht die auf False, causes das Control halt keine Validation.

    vlt. hilft dir das ja weiter.
    Hallo,

    ​der Input mit dem CausesValidation-Property war klasse. Hat mir zumindest gezeigt, dass der Aufruf an einer ganz anderen Stelle war als vermutet.
    ​Habe das Problem zwar noch immer nicht eindeutig identifiziert, konnte so aber einen Workaround machen indem ich einen großen Codeteil einfach das Validation Event für meine TextBox "deaktiviert habe". Evtl. nehme ich mich des Themas noch einmal an wenn ich mehr Zeit und Muße habe.