Focus setzen im Frame

[paweld]

Verwenden Sie „SetFocus“: https://files.brudnopis.ovh/file/WJ7NcA ... -39-54.mp4
Ich würde aber empfehlen, den Code ein wenig zu ändern, da er sehr langatmig ist und viele Wiederholungen enthält. Wenn man ihn in Funktionen aufteilt, wird der Code nicht nur kürzer, sondern man kann auch leichter Änderungen vornehmen. Ich habe nur Änderungen an „Unit3.pas“ vorgenommen.

[juelin]

SUPER,
endlich mal einer der mich versteht. (poweld)
Sie haben natürlich Recht, man kann die Sachen vereinfachen und damit übersichtlicher machen.
Allerdings der Befehl: SetVariables('', 0, 2, 0, 0, 3, 0, 5, 20, 1, 1); ist etwas unübersichtlich.
Man weiss halt nicht genau was die Zahlen machen (muss man in der Routine nachschauen).
Gute Idee für das nächste mal.
Nochmal recht herzlichen Dank.
Gruß
Jürgen

[af0815]

Allerdings der Befehl: SetVariables('', 0, 2, 0, 0, 3, 0, 5, 20, 1, 1); ist etwas unübersichtlich.
Man weiss halt nicht genau was die Zahlen machen (muss man in der Routine nachschauen).

Die Parameter aus dem Interfaceteil werden bei Lazarus angezeigt, wenn man da sinnvolle Namen vergibt, erkennt man an der Deklaration was gemeint ist. Das ist nicht das große Problem. Generell sollte man sinnvolle Namensgebung verwenden. Edit1 bis Edit20 ist nicht lesbar. EdtVorName, EdtName, EdtOrt etc. schon.

Ich schau mir es auch noch an

[h-elsner]

Ich kann die Anzahl der Projekte eingeben aber sonst nichts. Kein Menü, keine Reaktion auf den (einzigen) Button.

[af0815]

Ich kann die Anzahl der Projekte eingeben aber sonst nichts. Kein Menü, keine Reaktion auf den (einzigen) Button.

Ich glaube man muss zwingend die anzahl der Projekte mit ENTER abschliessen, ansonsten wird ein Flag nicht gesetzt.

[juelin]

Ja stimmt.
Eingaben in Edit immer mit ENTER abschliessen, es sei den die Eingabe hat die maximale Anzahl an Stellen erreich.
Woher soll das Programm sonst wissen, das du mit der Eingabe fertig bist.
Man kann ja in einer 20 stelligen Eingabe die ersten 10 Zeichen eingeben und dann Mittagessen gehen
Und nach dem Mittagessen die zweiten 1o Zeichen eingeben oder ENTER.
Menü ist im ersten Bild oben (in Rot).
Gruß
Jürgen

[af0815]

Ich habe mal die Funktion Blankweg aus dem Form1 herausgezogen, die macht dort keinen Sinn und in eine extra unit gesteckt (Ebenso Blankdazu und Nummer). Ausserdem entfallen dann die Bezüge zurück ins Mainform. Ein Frame sollte keine bezüge zurück haben, ansonsten hat man einen Designfehler.

Wenn ich mir die so ansehe ist das nicht anders als die 3 Trimfunktionen, die sowieso schon vorhanden sind. Das geht mit anderen Funktionen sicher auch, die Sysutils und andere fertigen Bibliotheken beinhalten alles (bzw. das meiste) was man braucht.

Code: Alles auswählen

function Blankweg(Art: integer; Btextstring: string): string;
//var
//  laenge: integer;
//  stelle: integer;
//  vari12: integer;
//  zeichen: string;
//  ausgabe: string;
begin
  // die Frage ist hier ob man nicht eher trim aus der sysutil verwendet
  case Art of
    1: Result:= TrimLeft(Btextstring);
    2: Result:= TrimRight(Btextstring);
  else
    Result:= trim(Btextstring);
  end;
  //laenge:=Length(Btextstring);
  //ausgabe:='';
  //if laenge > 0 then
  //begin
  //  ausgabe:=Btextstring;
  //  if ((Art = 1) or (Art = 3)) then
  //  begin
  //    vari12:=0;
  //    for stelle:=1 to laenge do
  //    begin
  //      zeichen:=Copy(Btextstring,stelle,1);
  //      if (vari12 = 0) then
  //      begin
  //        if (zeichen <> ' ') then
  //        begin
  //          vari12:=stelle;
  //        end;
  //      end;
  //    end;
  //    if vari12 > 0 then
  //    begin
  //      zeichen:=Btextstring;
  //      ausgabe:=Copy(zeichen,vari12,laenge-(vari12-1));
  //    end else begin
  //      ausgabe:='';
  //    end;
  //  end;
  //  laenge:=Length(ausgabe);
  //  if laenge > 0 then
  //  begin
  //    if ((Art = 2) or (Art = 3)) then
  //    begin
  //      vari12:=0;
  //      for stelle:=laenge downto 1 do
  //      begin
  //        zeichen:=Copy(ausgabe,stelle,1);
  //        if (vari12 = 0) then
  //        begin
  //          if (zeichen <> ' ') then
  //          begin
  //            vari12:=stelle;
  //          end;
  //        end;
  //      end;
  //      if (vari12 > 0) then
  //      begin
  //        zeichen:=ausgabe;
  //        ausgabe:=Copy(zeichen,1,vari12);
  //      end else begin
  //        ausgabe:='';
  //      end;
  //    end;
  //  end else begin
  //    ausgabe:='';
  //  end;
  //end;
  //Result:=ausgabe;
end;

War nur mal ein Schnellschuß, der mir ins Augegesprungen ist.
Edit: Einwenig refactoring um das Projekt klarer zu strukturieren, allerdings noch lange nicht fertig.

[charlytango]

Ich hab mir das Teil mal runtergeladen und angesehen.

Über das Design kann man geteilter Meinung sein, sei's drum.

Über die Usability aber nicht.
Hier wird programmiert wie ich es aus den schrägsten Masken aus DBase/Clipper/Foxbase kenne.
Das Userinterface geht gegen jede Konvention grafischer Oberflächen und Betriebssysteme -- kein Wunder wenn man sich da jede Menge Probleme eintritt.

Für Benutzer die Windows oder Linux GUIs gewohnt sind, ist das schlicht unbenutzbar. ENTER als Feldbestätigung ist ein Konzept aus den 80ern.

Eingabefelder haben in der jeweiligen Maske stateless zu sein und können mit Tab oder Mausklick navigiert werden. Die Reihenfolge von Eingabefeldern wird über die Taborder gesteuert. ENTER drückt den Default Button in einer Maske.

Man kann ja in einer 20 stelligen Eingabe die ersten 10 Zeichen eingeben und dann Mittagessen gehen

Nein, kann oder sollte man nicht. Für Masken läuft im besten Fall ein Timer, der Benutzeraktivitäten überwacht oder einfach einen Timeout auslöst und die editierung Maske abbricht. (da ist eh ein Timer auf dem Formular)

Damit ist der Datensatz in einer Mehrbenutzerumgebung wieder frei.

Feldvalidierungen erfolgen direkt vor dem Speichervorgang der bei einem Fehler abgebrochen wird. Die besseren Systeme markieren die erratischen Felder farblich und geben entsprechende Fehlermeldungen (z.B. als Hint oder MouseOver) aus. Der Benutzer kann korrigieren und neu speichern.

Projektindizes beim Programmstart zu erstellen ist obsolet, das muss vollautomatisch im Hintergrund laufen.

Ich frage mich ohnedies, warum man eine Projektverwaltung, also das Paradebeispiel für eine DB Anwendung auf Biegen und Brechen mit selbstgestickten Datendateien abbilden will.

Und ja, manchmal ist das ideale Layout einer Maske für Ersterfassung anders als das für die Änderung von Bestandsdaten (die meist wesentlich umfangreicher sind). Dann verwendet man dazu eben eigene Eingabeformulare die zb modal angezeigt werden und als Wizard dienen.

Sorry, aber für mich sieht das so aus als ob jemand mit einem Design-Mindset aus nicht grafischer Programmierung mit Gewalt durch die Wand will.

Zum Code:
Durchnumerierte Variablen sind einfach schlechter Stil und die Hölle wenn man in einem halben Jahr etwas nachsehen muss.

Im Form klebt zur Design-Zeit ein Frame. Das macht bekanntermaßen Probleme.

Für die Aktionssteuerung und die Menüs fehlt mir eine Actionlist.

mit Irgend eine internen Numerierung von Personen et al darf der Benutzer gar nichts zu tun haben.


****************
Warum ich mir so eine Kritik erlaube?
Ich habe mich in den letzten 40 Jahren von dBase II über Clipper und Delphi/Kylix im wesentlichen mit Mehrbenutzer-Datenbankfrontends und deren Optimierung (zB Eerfassungs und Bedienungszeiten in diversen Geschäftsfällen) beschäftigt.
Ein Hauptaugenmerk war die Abbildung von personenbezogenen und firmenbezogenen Daten sowie deren historischer Beziehung zueinander.
Ebenso die Modellierung von Firmen- Personen und Adressdaten die auch automatisiert abgleichbar sind und mit Straßen und Firmenkatalogen aktualisiert und ergänzt werden können.


Trotzdem hat bei mir jeder das Recht sich in seine persönliche Hölle zu befördern und demnach soll jeder tun was er mag. In diesem Fall wäre das für mich eine Zweinigung

[af0815]

Entweder man bindet das Frame zur Designzeit ein (wie hier)

Code: Alles auswählen

  TForm1 = class(TForm)
    FileListBox1: TFileListBox;
    Frame1: TFrame1;
    Frame2: TFrame2;
    Image1: TImage;
    .....

dann darf man aber sowas nicht machen.

Code: Alles auswählen

procedure TForm1.Frame1Close;
begin
  Frame1.Visible:=False;
  TFrame1(FindComponent('Frame1')).Free;
  Menuefunktionen;
end;

Entweder dynamisch oder statisch aber keine Mischung. Nach dem FrameClose hast du nur noch eine hängende Referenz und die ist absolut tödlich. Gilt natürlich auch für das Frame2.

Der Nachteil von statisch eingebundenen Frames ist, das man sich gerne Ereignishandler unbewusst überschreibt und das Änderungen am Frame erst beim nächsten öffnen erkannt und angezeigt werden. Deswegen meine Meinung - Hände weg von den statisch eingebundenen Frames. Ausser du weisst wirklich was du tust und das Frame ist bombenfest ausdesigned.

Wenn du innerhalb von TForm1 etwas refernzierst dann NICHT

Code: Alles auswählen

Form1.Edit1.Text:= '';
// sondern nur
Edit1.Text:= '';

Weil wenn das Formular plötzlich MainForm heistt, gibt es kein Form1 mehr.

Edit: Ich habe einmal soweit bereinigt das man überhaupt das Frame verwenden kann und es noch dazu dynamisch eingebunden. Und vor allen die Bezüge aufgelöst. Wenn man von einem Frame etwas an den Parent senden will, so bitte immer OnXXX event = Callbacks verwenden, dann bleiben die Frames auch verwend und wartbar.
Das eigentlich springen von Feld zu Feld kann man jetzt erst mal angehen. Aber da ich von der Farbgebung gerade Augenkrebs bekommen habe (rosa auf grau ist fürchterlich) brauche ich mal eine Pause. Charlytango hat da schon recht. Allerdings wie man Daten speichert - über das kann man herrlich streiten (das ist Popcorntime).