Parameterrückgabe von Form an aufrufenden Prozess

[FediDelPr]

Hallo zusammen,

ich suche für folgendes Problem eine (elegante) Lösung:

Es existiert bereits ein Modul mit Form das eine komplexe Suche in einer DB ermöglicht.
Die Suche soll von überall aus dem Programm verwendet werden können.

Am Ort des Aufrufs soll z.B. ein Edit-Feld und zusätzlich ein Button (Bezeichnung Advanced Search) vorhanden sein. Mit dem Button wird das Search-Fenster geöffnet.
Jetzt kann nach etwas gesucht werden. Beim Schliessen des Fenster soll nun das Resultat
(idR eine Referenz zu einer ItemNr in der DB) direkt in das Edit-Feld auf dem Form von
dem aus die Suche aufgerufen wurde eingefüllt werden.

Wäre das Suchen nur eine einfache Funktion oder Procedure wäre das Ganze keine Hexerei.
Schwieriger wird's (für mich), weil das Aufbereiten des Resultates im Subfenster geschieht und
die Resultatübergabe erst beim Schliessen dieses Fensters erfolgen soll. (oder explizit mit
Button auf dem Suchfenster)

Ich kann mir gut vorstellen, dass unter euch jemand ist, der eine einfache,
perfekte Lösung bereit hält.

[ConstantGardener]

...naja wir müssten schon wissen wie die Ergebnisse aussehen, die die Suche ausspuckt. Dann kann man auch über eine Rückgabe spekulieren.

[hoika]

Hallo,
das SuchForm über eine lokale Variable erzeugen, starten, warten und fertig.

Delphi-Quellcode:

unit2

type
  TSuchForm = class(TForm)
    public
      ItemNr: Integer;
  end;


unit1

procedure TForm1.Suche;
var
  Frm: TSuchForm;
  ItemNr: Integer;
begin
  ItemNr:= 0;

  Frm:= TSuchForm.Create(Self);
  try  
    if Frm.ShowModal=mrOK then
    begin
      ItemNr:= Frm.ItemNr;
    end;
  finally
    Frm.Free;
  end;  

  if ItemNr=0 then
  begin
    Exit;
  end;

end;

[TurboMagic]

Hoika's Lösungsansatz ist einer, der mal als einfaches Beispiel formuliert wurde aber funktioniert.

Ein anderer wäre dem Suchen Fenster via Konstruktor eine Callback-Methode zu übergeben, die das Suchen
Fenster aufruft wenn es geschlossen wird und dem die Daten übergibt.

[hoika]

Hallo,

Zitat:

Ein anderer wäre dem Suchen Fenster via Konstruktor eine Callback-Methode zu übergeben, die das Suchen
Fenster aufruft wenn es geschlossen wird und dem die Daten übergibt.

Bo eh!
Der TE hat 43 Einträge !

[FediDelPr]

Die Variante von hoika funktioniert jetzt.

Die wesentlichen Elemente sind:
- ShowModal
- ModalResult, um z.B. mrOK.. selbst zu generieren (kein Standard-Dialog)
- Die Output-Variable als PUBLIC in der Klasse definiert

Ich verwende allerdings nicht die dynamische Form-Erzeugung. Wo liegt der Vorteil ?

Die andere Möglichkeit von TurboMagic ist für später sicher interessant.
Etwas in dieser Art schwebte mir ursprünglich vor. Da ich in dieser Hinsicht wenig
Erfahrungen habe konzentrierte ich mich auf die andere Lösung.
Sollte jemand Zeit haben die Details an einem einfachen Beispiel kurz zu erläutern, würde
mich das natürlich freuen.

Besten Dank für die Hilfe.

[haentschman]

Moin...

Zitat:

Ich verwende allerdings nicht die dynamische Form-Erzeugung. Wo liegt der Vorteil ?

Wieder mal ein Auto Vergleich...
Stelle dir mal vor, daß du in den Urlaub fahren willst.Dazu packst du deinen kompletten Hausstand (Forms) ein...jeder Koffer eine Form. Wenn du Pech hast (eher selten ) passen deine Koffer nicht ins Auto (Arbeitsspeicher zu klein). Besser ist, nur die Koffer zu packen, die du brauchst (dynamische Erzeugung) und nach dem Urlaub wieder auszupacken (Free). Somit hast immer den Kofferraum immer leer...

Bei einer Form spielt es keine Rolle, aber man sollte es gehört haben wie es auch anders geht.

[Andreas L.]

Zitat von hoika:

Hallo,
das SuchForm über eine lokale Variable erzeugen, starten, warten und fertig.

Delphi-Quellcode:

unit2

type
  TSuchForm = class(TForm)
    public
      ItemNr: Integer;
  end;


unit1

procedure TForm1.Suche;
var
  Frm: TSuchForm;
  ItemNr: Integer;
begin
  ItemNr:= 0;

  Frm:= TSuchForm.Create(Self);
  try  
    if Frm.ShowModal=mrOK then
    begin
      ItemNr:= Frm.ItemNr;
    end;
  finally
    Frm.Free;
  end;  

  if ItemNr=0 then
  begin
    Exit;
  end;

end;

So wie du würde ich es auch lösen. Ich würde lediglich eine execute-Methode dem Form geben:

Delphi-Quellcode:

type
  TSuchForm = class(TForm)
  private
    FItemNr: Integer;
  public
    class function Execute(var AItemNr: Integer): Boolean;
  published
    property ItemNr: Integer read FItemNr write FItemNr;
  end;

...

class function TSuchForm.Execute(var AItemNr: Integer): Boolean;
var
  Form: TSuchForm;
begin
  Form := TSuchForm.Create(nil);
  try
    Form.ItemNr := AItemNr;
    Result := Form.ShowModal = mrOK;
    if Result then
      AItemNr := Form.ItemNr;
  finally
    FreeAndNil(Form);
  end;
end;

Das Form sollte natürlich aus der auto. erstellen Liste des Projekts entfernt werden.

[Pfaffe]

Zitat:

Ich verwende allerdings nicht die dynamische Form-Erzeugung. Wo liegt der Vorteil ?

Bei Anwendungen, die der Anwender oft schießt und wieder öffnet, kann es nerven, wenn der Startvorgang lange dauert.
Es gibt aber auch Anwendungen, die schließt der Anwender selten, z.B. CAD-Programme, die halten möglichst viel im Speicher, da macht auch 64-Bit Sinn.
Bei Datenbankanwendungen wäre es blöd, wenn die Connection immer wieder zerstört wird. Habe schon Anwendungen gesehen, in der in jedem Form eine Connection auf und wieder zugemacht wurde
Es gibt noch eine weitere Möglichkeit. Die Formulare werden nicht in der dpr erzeugt, sondern dann, wenn der Anwender sie zum ersten Mal anfordert:

Delphi-Quellcode:

  if not Assigned(FSuchForm) then 
    Application.CreateForm(TFSuchForm, FSuchForm);
  // FSuchForm.xxx

anstatt von

Delphi-Quellcode:

  Frm:= TSuchForm.Create(Self);
  try 
    // Frm.xxx
  finally
    Frm.Free;
  end;

Nachdem das Formular erzeugt wurde, bleibt es im Speicher, bis die Anwendung beendet wird. Fordert der Anwender das Formular nicht an, dann wird es auch nicht erzeugt und verbraucht keinen Speicher.

Richtig/Falsch: Nicht zu viel Angst vor scheinbare Fehler, oft gibt es viele Lösungswege. Heuzutage wird in den Firmen zu lange geredet und es herrscht zu viel Angst davor, etwas nicht optimal zu machen. Meine Empfehlung: Demos mit den verschiedenen Techniken erstellen, kommentieren und archivieren.

Anmerkung zu DLL's: Bei den neueren Delphi-Versionen kann die Option delayed angeben werden, dann dauert das Erste ansprechen der DLL nicht so lange. (Bitte in der Hilfe nachlesen)

[Pfaffe]

Noch eine Anmerkung zum Thema Programmierstil:
Nehmen wir an, es gibt viele Anwendungen in eine FSuchForm benötigen.
Man könnte diese in eine DLL auslagern.
Oder man ruft alle Formulare aus einem Datamodul (DM) auf, welches von sämtlichen Anwendungen verwendet wird.
Man hat dann auch nicht das Problem, dass sämtliche Formulare viele units, in denen die anderen Formularen deklariert sind, eingebunden werden müssen. Es muss immer nur das Datamodul eingebunden werden. Im Datamodul sind die notwendigen units eingebunden.
Das Datamodul stellt nun durch Hilfsroutinen den Zugriff auf die Formulare her. Auch die Verbindung zu Datenquellen.
Also nicht:

Delphi-Quellcode:

  Frm:= TSuchForm.Create(Self);
  try 
    // Frm.xxx
  finally
    Frm.Free;
  end;

sondern:
  DM.Get_SuchFormItemNr; // in Get_SuchFormItemNr wir alles gemacht, was notwendig ist um das Formular anzuzeigen. Im Datamodul steht nun das

Delphi-Quellcode:

function DM.Get_SuchFormItemNr: integer;
begin  
  result:= -1; // Initialisierung
  if not Assigned(FSuchForm) then 
    Application.CreateForm(TFSuchForm, FSuchForm);
  if FSuchForm.Showmodal = mrOK then
    result:= FSuchForm.ItemNr
  else 
    result:= -2; // z.B. besser Konstanten deklarieren
end;

Nachteil:
Delphi gibt ggf. Warnungen aus "deklariert, aber nicht verwendet" aus.
Die einzelnen Anwendungen (exe) werden ein bisschen größer, da der Linken nicht intelligent genug ist.
Es dürfen in einem Projektteam nicht zu viel Leute am Datamodul rumfummeln.

Bei Fachanwendungen kann im Datamodul der Datenbankzugriff gekapselt werden, nicht jeder Dr.-Ing. muss davon Ahnung haben.

Wenn es nur eine große Anwendung gibt, dann kann die Logik auch ins Hauptformular und muss nicht ins Datamodul.