EditingDone und Showmessage Verhalten

[Technofreak]

Hallo

ich habe folgendes Phänomen festgestellt.

Wenn ich den folgenden Code ausführe und die Message mit der Maus bestätige funktioniert alles normal.
Bestätige ich die Message mit der Enter-Taste wird EditingDone sofort wieder aufgerufen.
Ist das normales Verhalten? Wie kann ich das umgehen?

Code: Alles auswählen

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;

type

  { TForm1 }

  TForm1 = class(TForm)
    Edit1: TEdit;
    procedure Edit1EditingDone(Sender: TObject);
  private

  public

  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure Eingabe_pruefen;
begin
  Showmessage('Test');
  Form1.Edit1.SetFocus;
end;

procedure TForm1.Edit1EditingDone(Sender: TObject);
begin
    Eingabe_pruefen;
end;

end.

Ich hoffe ihr habt eine Idee.


Silvio

[theo]

Auf Linux sehe ich dieses Verhalten nicht (GTK2, Qt5 getestet).
Lazarus 2.3.0 (rev main-2_3-1839-g4fba69291d) FPC 3.2.2 x86_64-linux-gtk2

Aber warum willst du den Fokus überhaupt programmatisch zurücksetzen, wenn der User das TEdit doch verlassen hat, wie man an "EditingDone" erkennen kann?

[Winni]

Hi!

Wir hatte das schon mal vor ein paar Jahren:

https://www.lazarusforum.de/viewtopic.php?t=8908

da gibt's auch ne Lösng.

Winni

[theo]

Wenn das Verhalten auf Windows wirklich so ist, dann als Workaround vielleicht auch:
https://wiki.lazarus.freepascal.org/Asynchronous_Calls

[Technofreak]

Hallo theo,

kurze Erklärung zum Programm in dem das Problem auftrat.

Das Programm soll bei der Dokumentation der Wartung eines Messgeräte unterstützen.
In diesem Messgerät dient ein Schlauch um einen Aluzylinder als Heizung.
Dieser Schlauch muss bei jeder Wartung getauscht werden.
Der Aufwand den Schlauch vor Ort zu tauschen ist größer als bei mir im Büro.
Daher wird das ganze Modul getauscht.
Die Module sind nummeriert, und der Austausch wird incl. Nummern dokumentiert.
Nach Eingabe der Modulnummer wird geprüft ob beide verschieden sind, wenn nicht wird eine Meldung angezeigt und in das Feld zurückgesprungen.
An dieser Stelle ist mir das Problem aufgefallen.

Ich umgehe jetzt das Problem indem ich einen Timer starte der nach 100ms den Fokus wieder auf das Feld setzt.


Silvio

[wp_xyz]

Ich mache eigentlich nie Eingabeprüfungen im OnEditingDone-Ereignis. In einem Dialog mit Cancel-Button erscheint dann nämlich auch die Fehlermeldung, obwohl ich den Dialog verlassen will und dabei die Eingabe verwerfe - das ist extrem nervig.

Stattdessen wird im OKClick in der Regel eine längere Fehlerprüfung aufgerufen, die alle möglichen Fehlerstände abfragt, das Control mit dem Fehler fokussiert, eine entsprechende Fehlermeldung angezeigt und mit ModalResult := mrNone das Schließen des Fensters verhindert. Da der EditingDone-Code da schon lange abgearbeitet ist, habe ich keine Probleme mit dem Fokussieren des den Fehler erzeugenden Controls.

[fliegermichl]

Wobei EditingDone nicht ganz nutzlos ist. So kann man abhängig vom eingegebenen Wert beispielsweise andere Felder befüllen usw.

[Technofreak]

OnClick ist in diesem Fall recht nutzlos, da in dem Programm meistens per Tastatur zwischen den einzelnen Feldern navigiert wird.
Die Reihenfolge der Eingaben ist in den meisten Fällen gleich und kann daher per SetFocus leicht vorausgewählt werden.

[charlytango]

da in dem Programm meistens per Tastatur zwischen den einzelnen Feldern navigiert wird.

Ganz verstehe ich diese Aussage nicht. Jedes Programm mit einer graphischen Oberfläche sollte doch so gebaut sein dass es egal sein sollte ob mit der Maus navigiert wird, die Tastatur benutzt wird oder auch Shortcuts. Stichworte: TabStop, TabOrder, TabOrder Editor, Default Button.
Unter Windows springt man mit dem Tabulator von einem Feld zum anderen und die Enter-Taste drückt den Default-Button.
Bei anderen OS kann das unterschiedlich sein.
Natürlich hat das einen wesentlich höheren Aufwand bezüglich der GUI-Programmierung zur Folge und bedeutet auch viele Überschneidungen in Funktionen und Events. Deswegen gibt es ja die Unterstützung durch Lazarus um diesem Chaos Herr zu werden.

Aber das enthebt einen nicht, sich ein brauchbares Design für seine Eingabemasken zu überlegen.
Bei mir machen die Editfelder außer den üblichen Formatprüfungen kaum umfangreiche Plausibilitätstests um nicht in solche unkontrollierbaren Endlosschleifen zu kommen.
Irgendwo gibt es immer einen Single Point an dem der Benutzer sich zwischen Speichern oder Abbruch entscheiden muss. Und genau dort mache ich alle Plausibilitätsprüfungen so wie

Stattdessen wird im OKClick in der Regel eine längere Fehlerprüfung aufgerufen, die alle möglichen Fehlerstände abfragt, das Control mit dem Fehler fokussiert, eine entsprechende Fehlermeldung angezeigt und mit ModalResult := mrNone das Schließen des Fensters verhindert. Da der EditingDone-Code da schon lange abgearbeitet ist, habe ich keine Probleme mit dem Fokussieren des den Fehler erzeugenden Controls.

Zusätzlich zu den angezeigten Fehlermeldungen hinterlege ich erratische Eingebefelder mit einer Fehlerfarbe.

Die Reihenfolge der Eingaben ist in den meisten Fällen gleich und kann daher per SetFocus leicht vorausgewählt werden.

SetFocus verwende ich nur wenn es in diesem Moment keine Probleme bereitet, da hab ich schon einiges an Wuthormonen vergeudet gggg