Parameterrückgabe von Form an aufrufenden Prozess

[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.

[TurboMagic]

Wenn ein Callback genutzt werden soll geht es ungefähr so:

Delphi-Quellcode:

type
  TCallbackProc = procedure(MyReturnValue:Integer) of Object;

  TMyForm = class(TForm)
  private
    FCallback : TCallbackProc;
  public
    constructor Create(AOwner: TComponent; ResultCallback:TCallbackProc); 
  end;

constructor TMyForm.Create(AOwner: TComponent; ResultCallback:TCallbackProc); 
begin
  inherited Create(AOwner);

  FCallback := ResultCallback;
end;

Im FormClose dann einfach das aufrufen, wenn 5 zurückgegeben werden soll,
evtl. mittels Assigned Prüfung absichern:
  FCallback(5);
   

Aufruferseite:

TMyOtherForm = class(TForm)
private
  procedure DoIt;
public
  procedure GetResult(MyReturnValue:Integer);
end;

procedure TMyOtherForm.DoIt;
var
  MyForm : TMyForm;
begin
  MyForm := TMyForm.Create(self, Getresult);
  MyForm.Show; // oder .ShowModal, bei .Show muss sich die andere Form 
               // selber freigeben, bei ShowModal müsste es hier passieren
end;

procedure TMyOtherForm.GetResult(MyReturnValue:Integer);
begin
  ShowMessage(MyReturnValue.ToString);
end;

So ungefähr geht das und das ist in etwa auch, was der Formulareditor tut,
wenn man einem Steuerelement ein Event zuweist.

[hoika]

Hallo,
TE= Thread-Ersteller

[FediDelPr]

@haentschman

Ich sehe die Vorteile von dynamischen Objekten mindestens teilweise schon.
Manchmal ist es ein Muss.

Trotzdem wende ich dies sehr sparsam an und zwar aus dem Grund der Zuverlässigkeit.
Ich denke, dass viele Fehler heutiger Software bei der Anwendung dynamischer
Strukturen liegen. Ein typisches Beispiel ist die Delphi-IDE selbst. Immer wieder mal
gibt's Probleme mit der dyn. Speicherverwaltung.

Der Zeitdruck in der Software-Entwicklung ist heute sehr hoch. Oft zu hoch.
Schnell vergisst man mal eine Speicherfreigabe oder die Übersicht ist nicht mehr
wirklich da.
Im weiteren ist auch die dahinterliegende Implementation komplexer und damit fehleranfälliger.
Also wieder mal: je einfacher, desto besser.

Wenn mir jemand ein tolles Rezept hat das in den Griff zu bekommen, bin ich ganz Ohr.
Ich denke da ist der PASCAL-Nachfolger OBERON schon besser. Aber eben..

ps
Neben der dynamischen Objekt-/Speicherverwaltung gibt's noch Thema wo ich sehr vorsichtig
bin: Interrupts - wirklich nur dort wo's absolut notwendig (Timing). In den meisten
Echtzeit-Systemen sind nur ganz wenige notwendig.

[FediDelPr]

@Andreas L., Pfaffe und TurboMagic

ich werde mich später weiter damit befassen. Diese alternativen Methoden interessieren
mich.

[TurboMagic]

Zitat von FediDelPr:

@haentschman

Ich sehe die Vorteile von dynamischen Objekten mindestens teilweise schon.
Manchmal ist es ein Muss.

Trotzdem wende ich dies sehr sparsam an und zwar aus dem Grund der Zuverlässigkeit.
Ich denke, dass viele Fehler heutiger Software bei der Anwendung dynamischer
Strukturen liegen. Ein typisches Beispiel ist die Delphi-IDE selbst. Immer wieder mal
gibt's Probleme mit der dyn. Speicherverwaltung.

Der Zeitdruck in der Software-Entwicklung ist heute sehr hoch. Oft zu hoch.
Schnell vergisst man mal eine Speicherfreigabe oder die Übersicht ist nicht mehr
wirklich da.

Naja, im Lieferumfang von Delphi ist schon ein einfacher Hinweisgeber für vergessene
Speicherfreigaben eingebaut. Man muss ihn nur wie folgt aktivieren:

1. .dpr Datei des Projekts öffnen
2. als erste Zeile direkt hinter das begin das hier schreiben:
ReportMemoryLeaksOnShutdown := true;

Wenn nun das Programm ein Speicherleck verursacht, gibt's beim beenden eine Meldung.
Nur sagt einem diese Variante noch nicht woher es kommt.

Lädt man die komplettversion des FastMM4 Speichermanagers aus dem internet herunter,
kann man auch einen Stacktrace bekommen der auf die Programmstelle zeigt, an der dieser
Speicher allokiert wurde.

Damit wird es zumindest unter Windows sehr einfach Speicherlecks zu finden.

Grüße
TurboMagic

[DieDolly]

Zitat:

1. .dpr Datei des Projekts öffnen
2. als erste Zeile direkt hinter das begin das hier schreiben:
ReportMemoryLeaksOnShutdown := true;

Als ich die Funktion vor über einem Jahr entdeckt und auch eingeschaltet habe, war ich erstmal mehrere Wochen damit beschäftigt Speicherlecks zu beseitigen.

Die Funktion ist goldwert.