SENDER an andere Form übermitteln

[wp_xyz]

Wenn du an TEingabe nur Integer, keine Strings, übermitteln würdest, gäbe es das Problem nicht...

Das ist für mich ja kein Dogma, dann muss ich halt in der Mainform in einen Integerwert umwandeln und die Fehlerprüfung durchführen und das Ergebnis dann ebenda wieder in einen String umwandeln.
Ist halt irgendwie doppelt gemoppelt: Das Caption zunächst in eine Integer umwandeln, an Form2 übergeben, dort die Einzelstellen wieder in Captions zerlegen, das dann wieder in eine Integer umwandeln, die zurück an Form1, und dann wieder ein Caption draus machen.

Wozu brauchst du denn die Zahlen? Wahrscheinlich um irgendetwas damit zu berechnen oder einzustellen. Also verwendest du das als Integer, nicht als String. Das bisschen hin-und-her-Konvertieren merkst du garantiert nicht, du sparst dir aber viel Kopfzerbrechen wegen einer unnötigen Eingabeprüfung.

[kupferstecher]

Ist halt irgendwie doppelt gemoppelt: Das Caption zunächst in eine Integer umwandeln, an Form2 übergeben, dort die Einzelstellen wieder in Captions zerlegen, das dann wieder in eine Integer umwandeln, die zurück an Form1, und dann wieder ein Caption draus machen.

Das ist m.E. der einzig praktikable Weg. Wenn dein Label falsch initialisiert wird (Programmaenderung) und die fuehrenden Nullen fehlen, muss dein Programm das aufwaendig unterscheiden koennen. Eine doppelte Typumwandlung ist da deutlich einfacher.
Nimm das Beispiel von wp_xyz von weiter vorne und nehm alle Zuweisungen mit ValIndex raus. Dann hast du einen sehr kompakten Code, deutlich kuerzer wie deine Version. Falls du nicht genau verstehst wie dieser funktioniert: Form2.ShowModal unterbricht die Abarbeitung des Programms solange bis Form2 wieder geschlossen wurde, reagiert aber weiter auf Tastenklicks auf Form2. Nach dem Schliessen/Bestaetigen gehts an der alten Stelle weiter und du kannst die Labels von Form2 auslesen.

@Mathias: ShowModal funktioniert im Grunde wie ein Dialog, siehe oben.

[Mathias]

@Mathias: ShowModal funktioniert im Grunde wie ein Dialog, siehe oben.

Ich habe gerade gesehen, das ShowModal eine Function ist und keine Procedure.
Als Result ist ist ein Integer vorhanden, wird da etwa ModalResult von einem Button zurückgeliefert ?

[kupferstecher]

Als Result ist ist ein Integer vorhanden, wird da etwa ModalResult von einem Button zurückgeliefert ?

Ja, man kann ModalResult auch selber setzen, z.B. in einem ButtonOnClick-Event, und so wie ich es in Erinnerung habe wird das Programm daraufhin nach der ShowModal-Anweisung weitergefuehrt.

[ppahl]

Erstmal ein gutes neues Jahr!

So richtig verinnerlicht habe ich das mit der tcontrol-Property zwar noch nicht (da muss erst noch der Knoten platzen), dennoch habe ich es einfliessen lassen und auch ansonsten noch am Code geschraubt.
Immer unter der Prämisse dass bei _meiner_ Anwendung nur Labels für die Eingabe Verwendung finden und es auch ausgeschlossen ist, dass andere Zeichen als Zahlen auftreten. Den Test auf Zahlen habe ich also entfernt.

Die Änderungen:
- Die Labels von der Eingabeform sind jetzt von links (=1000er Stelle) nach rechts (=1er Stelle) nur noch von Label1 - Label4 durchnummeriert, warum seht ihr gleich.
- Weiterhin sind die oberen 'Up'-Grafiken von Image1 - Image4 und die unteren 'Down'-Grafiken von Image5 - Image8 durchnummeriert, auch da seht ihr gleich den Grund.

Also zunächst die Änderung in der Typ-Deklaration der zweiten Unit:

Code: Alles auswählen

 
  private
   QuellLabel: Tcontrol;
  public
   property Quelle: tcontrol read QuellLabel write QuellLabel;
  end;
 

Aufruf der zweiten Form aus der ersten heraus:

Code: Alles auswählen

 
procedure TForm1.Label1Click(Sender: TObject);
begin
  Eingabe.quelle := TControl(Sender);
  Unit2.Eingabe.visible := true;
end;
 

Im FormActivate der zweiten Form wird zunächst die Länge des übermittelten Captions ermittelt und bei Bedarf mit führenden Nullen aufgefüllt...

Code: Alles auswählen

 
  procedure TEingabe.FormActivate(Sender: TObject);
  var i : integer;
    dummy : string;
  begin
    rueckgabe := QuellLabel;
    dummy := (rueckgabe as tlabel).caption;
    i := length(dummy);
    case i of
        1: begin
            dummy := '000' + dummy;
           end;
        2: begin
            dummy := '00' + dummy;
           end;
        3: begin
            dummy := '0' + dummy;
           end;
     end;
     Label1.caption := copy(dummy,1,1);
     Label2.caption := copy(dummy,2,1);
     Label3.caption := copy(dummy,3,1);
     Label4.caption := copy(dummy,4,1);
  end;               
 

...und vorm Zurückschreiben eventuelle führende Nullen wieder entfernt.

Code: Alles auswählen

 
  procedure TEingabe.Button1Click(Sender: TObject);
  var i : integer;
  begin
   labeltext := Label1.caption + Label2.caption + Label3.caption + Label4.caption;
   i := strtoint(labeltext);
   labeltext := inttostr(i);
   QuellLabel.Caption := labelText;
   Eingabe.visible := false;
  end;
 

Was mich ja gestört hatte waren die vielen OnClick-Events der Up/Down-Images, das habe ich nun in einem einzigen Event zusammengefasst welches für alle Up/Down-Grafiken gilt.

Code: Alles auswählen

 
procedure TEingabe.ImageClick(Sender: TObject);
var
  UpDown : tobject;
  ImageName : string;
  ImageNummer, LabelNummer : integer;
  ZielLabel : tobject;
begin
  UpDown := sender;
  ImageName := (UpDown as Timage).name;
  ImageNummer := strtoint(copy(ImageName,6,1));
  if ImageNummer < 5 then LabelNummer := ImageNummer else LabelNummer := ImageNummer - 4;
  Ziellabel := TLabel(FindComponent('Label'+inttostr(LabelNummer)));
  case ImageNummer of
    1..4:
      begin
       if strtoint((Ziellabel as TLabel).Caption) < 9 then (Ziellabel as TLabel).Caption := inttostr(strtoint((Ziellabel as TLabel).Caption) + 1) else (Ziellabel as TLabel).Caption := '0';
      end;
    5..8:
      begin
       if strtoint((Ziellabel as TLabel).Caption) > 0 then (Ziellabel as TLabel).Caption := inttostr(strtoint((Ziellabel as TLabel).Caption) - 1) else (Ziellabel as TLabel).Caption := '9';
      end;
  end;
end;
 

Ich prüfe also erstmal die Nummer des auslösenden Images indem ich vom Namen die letzte Stelle als Integer sichere.
1 - 4 heisst Plus, 5 - 8 heisst Minus.
Dann suche ich nach einem Label auf der Form, dessen laufende Nummer der des Up-Images entspricht bzw. der des Down-Images minus 4.
Und dieses Label wird dann hoch- bzw. runtergeblättert.
Funktioniert zu meiner grossen Verblüffung tadellos .

So, jetzt liegt es wieder an euch die Hände über dem Kopf zusammenzuschlagen .

Gruss
Anton

[Mathias]

Hat das einen Grund, wieso das du für die Pfeile Images genommen hast, anstelle von BitBtn ?

Einen Schönheitsfehler habe ich gefunden, der Button Übernehmen sollte besser Ok heissen. Ein Übernehmen Button schliesst im Normalfall den Dialog nicht.

[wp_xyz]

Wird doch! Bist auf dem richtigen Weg!

Aber ein paar Sachen könntest du noch besser machen:

• Das "uses unit1" steht in unit2 immer noch da - auf dem habe ich die ganze Zeit herumgeritten. Es bewirkt, dass Unit2 nicht funktioniert, wenn Unit1 vorhanden ist. Aber du hast das offenbar nur übersehen - du kannst die Zeile ersatzlos streichen, weil von der Funktion her jetzt wirklich nichts mehr aus unit1 benötigt wird
• Mein geliebter Kritikpunkt an Anfängercode, wenn in einem Formular für die Klasse TEingabe plötzlich der Bezeichner "Eingabe", also der Names des Formulars, auftaucht. Gesehen in TEingabe.Button1Click und TEingabe.Button2Click. Das ist nicht nur unnötig, sondern ein latenter Fehler, weil das Formular nur noch funktioniert, wenn es "Eingabe" heißt. Oder wenn du zwei Formulare der Klasse TEingabe erzeugen musst, eins heißt Eingabe, das andere AlternativeEingabe, dann suchst du dich zu Tode, wenn du in "AlternativeEingabe" etwas eingibst, und du damit den Inhalt des anderen Formulars veränderst.
• In TEingabe.FormActiivate verwendest du ein global deklariertes Objekt "rueckgabe", das nirgendwo anders vorkommt. Warum machst du das global? Globale Variablen sollten so weit wie möglich vermieden werden, weil sie irgendwann Probleme machen. Wahrscheinlich wird dein Programm nie so groß werden - aber gewöhne dir das gar nicht an. Statt einer globalen Variablen deklariere diese doch lokal in der Routine in der du sie verwendest. Und speziell in deinem Fall ist rueckgabe überhaupt nicht nötig, denn die Caption kannst du auch direkt von QuellLabel abfragen: QuellLabel ist ein TControl, und jedes TControl hat eine Caption, also

  Code: Alles auswählen

    procedure TEingabe.FormActivate(Sender: TObject);
    var i : integer;
      dummy : string;
    begin
      dummy := QuellLabel.caption;  

• Dass du FormActivate verwendest, um das QuellLabel ins Eingabeformular zu übertragen, finde ich etwas ungeschickt. Ich könnte mir einen Anwendungsfall vorstellen, bei dem das Eingabeformular offen bleibt und du durch anklicken der Labels im Hauptformular die Werte zum Editieren eintragen möchtest. Wie machst du das? FormActivate wird nur beim 1. Label aufgerufen, weil sich das Formular öffnet, später aber nicht mehr. Besser wäre es, mit den Möglichkeiten zu arbeiten, die Properties bieten. Bei deiner Implementierung wird das Label, das der Property "Quelle" zugewiesen wird, nur "durchgereicht" zum interne Feld QuellLabel, weil hinter der Direktive "write" in der Property-Deklaration nur der Name der Feldvariablen steht. Wenn du hier aber eine Prozedur mit dem Label als Parameter angibst, dann wird diese aufgerufen, wenn der Property ein Wert zugewiesen wird. Das wäre dann der Code, den du in FormActivate verwendest. Noch zur Information, dass ich im folgenden Code die Bezeichner geändert habe. Denn wenn man Quellcode veröffentlicht, sollte man sich an die üblichen Konventionen halten, damit die "Öffentlichkeit" damit besser klarkommt. Bei Objekt-Feldern ist die Konvention, dass dem internen Namen ein F (für "Feld") vorangestellt wird. Außerdem finde ich den Bezeichner QuellLabel irreführend, weil der Typ ja nur ein TControl ist (auch wenn du bisher nur mit Labels arbeitest).

  Code: Alles auswählen

  type TEingabe = class(TForm)
  private
    FQuelle: TControl;
    procedure SetQuelle(AQuelle: TControl);
  ...
  public
    property Quelle: TControl read FQuelle write SetQuelle;
  ...
   
  procedure TEingabe.SetQuelle(AQuelle: TControl);
    var i : integer;
      dummy : string;
    begin
      FQuelle := AQuelle;
      dummy := FQuelle.Caption.Caption;
      i := length(dummy);
      case i of
          1: begin
              dummy := '000' + dummy;
             end;
          2: begin
              dummy := '00' + dummy;
             end;
          3: begin
              dummy := '0' + dummy;
             end;
       end;
       Label1.caption := copy(dummy,1,1);
       Label2.caption := copy(dummy,2,1);
       Label3.caption := copy(dummy,3,1);
       Label4.caption := copy(dummy,4,1);
    end;

• Um ein Zeichen aus dem String herauszuholen, verwendest du die Funktion "copy()". Nicht falsch, aber unnötig kompliziert. Nimm doch einfach nur das:

  Code: Alles auswählen

  Label1.Caption := dummy[1];
  Label2.Caption := dummy[2];
  Label3.Caption := dummy[3];
  Label4.Caption := dummy[4];

• In Form1.Label1Click stellst du in der zweiten Zeile den Unitnamen voran. Das ist nicht falsch, aber unnötig, weil "Eingabe" nur in Unit2 vorkommt, und erzeugt unnötig lange Bezeichner.

[ppahl]

Hat das einen Grund, wieso das du für die Pfeile Images genommen hast, anstelle von BitBtn ?

Da kann ich die Grafiken nach belieben stretchen, das ist alles.

Einen Schönheitsfehler habe ich gefunden, der Button Übernehmen sollte besser Ok heissen. Ein Übernehmen Button schliesst im Normalfall den Dialog nicht.

Die Anwendung ist für meine Frau, und die weiss das zum Glück nicht...

[ppahl]

@wp_xyz
Nochmal Danke für deine Denkanstösse!
Vieles sind noch Überbleibsel vom Rumprobieren und wird noch bereinigt, z.B. Pkt.1 und Pkt.3. Wollte zum Testen jeweils nicht zuviel auf einmal ändern, denn wenn es dann wieder klemmt folgt zwangsläufig die Frage woran es lag.
Also im einzelnen:
Punk1: Checked
Punkt2: Geändert in 'self.visible' - besser?
Punkt3: Siehe oben, hätte ich noch geändert - trotzdem danke.
Punkt4: Wie schon gesagt ist das ja erstmal für meine konkrete Anwendung, bin ja schon froh überhaupt so weit gekommen zu sein. 'Besser wäre es, mit den Möglichkeiten zu arbeiten, die Properties bieten' klingt gut soweit man diese kennt. Ich kenne sie (bislang) nicht, z.B. kapiere ich nicht wieso die Prozedur TEingabe.SetControl in deinem Beispiel überhaupt aufgerufen wird? Komme ich schon noch dahinter, ist aber ein bisschen zuviel auf einmal. In meiner vorliegenden Form verstehe ich wenigstens was passiert .
Punkt5: Stimmt! wobei ich das ohnehin noch in eine Schleife mit 'TLabel(FindComponent('Label'+inttostr(LabelNummer)))' packen wollte - unnötig kompliziert aber irgendwie cool .
Punkt6: Siehe wiederum oben, ein Relikt von verschiedenen Herumprobierereien.

Gruss
Anton

[wp_xyz]

Verstehe mich nicht falsch. Ich will nicht pingelig sein. Du bezeichnest dich als Anfänger, und da ist man vielleicht froh, dass man auf Fehler oder Unschönheiten hingewiesen wird.

Jetzt nur so viel:

Punkt 2: "Self.Visibel" - besser? Jein. Ja - weil der Name der Instanz nicht mehr genannt ist. Nein - weil: Self ist unnötig. Die Klasse kennt sich selber. Self braucht man eigentlich nur, wenn es Namenskonflikte mit übergebenen Prozedur-Parametern gibt (was aber mode objfpc sowieso unterbindet), oder wenn man massiv mit hässlichen "with"-Direktiven hantiert. Hier ein unschönes Beispiel aus TAChart (nicht von mir geschrieben):

Code: Alles auswählen

type
  TBasicChartSeries = class(...)
    FActive: Boolean;
  [...]
  end;
 
procedure TBasicChartSeries.Assign(Source: TPersistent);
begin
  if Source is TBasicChartSeries then
    with TBasicChartSeries(Source) do begin
      Self.FActive := FActive;
      [...]
    end;
end;

Es sollen die Eigenschaften von Source in die aktuelle Instanz von TBasicChartSeries kopiert werden. Der Autor war hier schreibfaul (es folgen noch mehrere solche Zeilen) und klammert die QuellSeries mit "with" aus. Ohne das Self würde dann einfach FActive := FActive zugewiesen - welches FActive ist links gemeint und welches rechts? Mit Self weiß man, die linke Seite bezieht sich auf die aktuelle Instanz von TBasicChartSeries. Damit gehört die rechte Seite zu TBasicChartSeries(Source). Ohne "with" wäre das Self nicht nötig gewesen:

Code: Alles auswählen

procedure TBasicChartSeries.Assign(Source: TPersistent);
begin
  if Source is TBasicChartSeries then
   FActive := TBasicChartSeries(Source).Active;
    [...]
end;

Punkt 4: Wenn du ein (oder eine?) Property mit "Setter" (SetXXXX routine) deklarierst

Code: Alles auswählen

class TMeineKlasse = class(...)
private
  FEigenschaft: Integer;
  procedure SetEigenschaft(Wert: Integer);
public 
  property Eigenschaft: Integer read FEigenschaft write SetEigenschaft;

wird der Setter automatisch aufgerufen, wenn man dem Property einen Wert zuweist, also schreibend zugreift:

Code: Alles auswählen

MeineKlasse.Eigenschaft := 1;
// ist dasselbe wie
// MeineKlasse.SetEigenschaft(1);  // das kann aber nur "intern" aufgerufen werden, weil "SetEigenschaft" als "private" deklariert ist.
 

Der Mechanismus steckt in den Schlüsselwörtern "property" zusammen mit "write". Genauso kannst du Code ausführen lassen, wenn du lesend auf Properties zugreifst, indem du einen "Getter" schreibst (also sowas wie "function GetEigenschaft: Integer") und diesen in der Propertydeklaration hinter dem read-Schlüsselwert angibst. Das ist die Magie, die in den Compiler und die IDE eingebaut ist.

Etwas ausführlicher vielleicht in https://www.delphi-treff.de/object-pasc ... d-objekte/, v.a.

[ppahl]

So, es kam wie es kommen muss wenn ich einen Code nicht vollumfänglich überreisse: Es funktioniert nicht (mehr).

Sämtliche geposteten Codes habe ich zwar unter Win7 auf meinem PC verbrochen, aber auch jedesmal direkt auf dem RPi gegengecheckt -> lief alles.

Dann habe ich dort eine weitere Form eingefügt deren einzige Verbindung zu den anderen darin besteht, dass sie per ButtonClick aus der ersten heraus aufgerufen wird -> lief.

Dann habe ich den Komponenten dieser Form einige kosmetische Änderungen angedeien lassen (Grösse und Position von Labels und Buttons) -> kompilierte fehlerfrei, aber plötzlich wurden bei Aufruf von Form2 nicht mehr die Labelwerte aus Form1 übernommen. Die Rückgabe an Form1 funktionierte aber weiterhin einwandfrei. Wie das??

Ich habe das aber erstmal ignoriert und mich weiterhin dem Layout von Form3 gewidmet da ich da gerade geistig in diesem Thema drin war -> kompiliert weiter einwandfrei, aber nach Start des Programms erscheint nun zunächst die leere(!) Form1, um dann mit einem SIGSEGV abzustürzen:

Und selbst wenn ich die dritte Form wieder komplett aus dem Projekt herauskommentiere (und die war die einzige Änderung am Projekt), der Fehler bleibt (erwartungsgemäss).
Ich werde jetzt wieder auf meine ursprüngliche Version rückrüsten, mal schauen ob ich es retten kann. Ansonsten werde ich das Projekt beerdigen, es hat ohnehin schon viel zuviel Zeit gefressen.

[Mathias]

Wirf doch nicht so schnell die Flinte ins Korn.

Lade doch mal das vermurkste Project hoch, vielleicht sieht man dwf Fehler.

[ppahl]

'Nicht so schnell' ist gut...
Der eigentlich entscheidende Teil ist die dritte (Steuerungs)Unit, und statt mich endlich um die kümmern zu können kaspere ich seit Tagen mit der Eingabe herum.
Da ich noch ettliche andere offene Baustellen habe und ich nicht meinen gesamten Neujahrsurlaub für dieses Projekt verblasen wollte habe ich eben den RasPi wieder in der Grabbelkiste versenkt.
Mal schauen wann ich wieder genug Zeit, Langeweile und Nervenstärke habe um das Teil wieder rauszukramen, fürs erste ist das Projekt aber beerdigt.

Vielen Dank für eure Hilfe und Geduld!

Gruss
Anton

[wp_xyz]

Schade. Lese ich daraus eine Art von Ungeduld, dass du eigentlich in den zwei Wochen Urlaub Pascal lernen wolltest und gleichzeitig dein RPi-Programm fertig haben wolltest? Meine Erfahrungen: Bis ich mich einigermaßen sicher in der Pascal-Welt bewegen konnte, ist ein halbes Jahr vergangen. Und Ungeduld ist immer ein schlechter Kollege. Auch heute sitze ich oft noch mehrere Tage an einem Problem, das dann mit einer einzigen Zeile gefixt wird.

[ppahl]

Pascal nutze ich (sporadisch) schon länger, so ist es nicht. Und generell eigentlich auch erfolgreich, allerdings bislang Desktop-Anwendungen und Android-Apps.
Zum aktuellen Objekt aber folgende Info: Es geht um eine Steuerung für den Töpferbrennofen meiner Frau, bislang hatte ich das mittels AVR gelöst. Ich wollte meiner Herzdame aber die Möglichkeit einer etwas komfortableren Bedienung bieten, u.a. auch die Möglichkeit zusätzlich zu den bereits hinterlegten Brennprogrammen mit benutzerdefinierten Brennkurven zu experimentieren, das wird mit/für den AVR einfach zu sperrig.
Diese Steuerung muss aber absolut zuverlässig laufen. Im einfachsten Fall brennt nur die Muffel durch, im nächst-unschöneren Fall hauts auch noch die Sicherung raus und der Kühlschrank taut ab, und im WorstCase bekommen wir Besuch von der feuerlöschenden Zunft.
Wenn das Ganze aber schon derart wackelig und nicht nachvollziehbar beginnt dann ist es besser erstmal den Stecker zu ziehen, die Anwendung lässt keinen Raum für zweifelhafte Try&Error Experimente.
Die alte Steuerung läuft ja (übrigens gerade wieder in diesem Moment) wunderbar, ich habe da also keinen Leidens- oder Zeitdruck.