Problem mit 2. Formular

[gfjs]

Hallo, Allerseits.

Und schon das nächste Problem mit Delphi 2005:

Ich habe über Datei/Neu/Weitere.../Neue Dateien ein zweites Formular zu meinem Projekt hinzugefügt. Dann einen Button auf Formular1 und:

Delphi-Quellcode:

procedure TWinForm.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
  winForm1.Show;
end;

Ich war schon erstaunt, dass nicht (wie aus Delphi 5 gewohnt) die Meldung kam: "Formular 'Form1' referenziert Formular 'Form2' ... Unit einbinden? Hab ich dann selbst gemacht: Uses ...., Winform1;

Mit F9 versucht zu starten:

[Fehler] WinForm.pas(95): E2003 Undefinierter Bezeichner: 'Show'

Wo hab' ich da einen Fehler gemacht? :gruebel: - Bin für Hinweise wie immer äußerst dankbar (weil Delphi-2005-frustrierrt).

mfg gfjs :drunken:

[omata]

Moin,

es sieht so aus als ob du deine Fenster jetzt selber erstellen/freigeben must (finde ich super, endlich muss ordentlich programmiert werden!).

Also so...

Delphi-Quellcode:

procedure TWinForm.Button_Click(sender: System.Object; e: System.EventArgs);
var WinForm1:TWinForm1;
begin
  WinForm1:=TWinForm1.Create;
  try
    WinForm1.ShowDialog;
  finally
    WinForm1.Free;
  end;
end;

Show gibt es noch. ShowModal gibt es leider nicht mehr da gibt es jetzt ShowDialog für.

MfG
Thorsten

[gfjs]

@ omata

Guten Morgen und vielen Dank für Deine Antwort.

Wenn ich das richtig verstanden habe, wird jetzt nur noch das Startformular automatisch erstellt und alle anderen Formulare muss ich selbst erstellen und beim Schließen wieder freigeben?!

Sorry, wenn ich mich ein bißchen blöd anstelle, aber es sind noch immer meine ersten Gehversuche mit Delphi 2005:

Wenn ich ein Formular mit "Close" schließe, wird dann automatisch "Free" aufgerufen oder kann ich es dann einfach mit "Show" wieder anzeigen?

Für ein paar zusätzliche Informationen wäre ich dankbar.

mfg gfjs

[omata]

Ja, ich gebe zu ich habe da auch noch nicht so viel mit gemacht.

Mit deinem Show habe ich auch mal rumprobiert. Das geht dann natürlich nicht mehr so wie in meinem obigen Beispiel, weil das Fenster dann gleich wieder verwindet.
Wenn man allerdings eine Private-Variable anlegt von Typ: TWinForm1 kann man im Create von TWinForm das zweite Fenster erzeugen und in dem Button-Event mit Show dieses Fenster sichtbar machen.
Allerdings wollte ich dann dieses Fenster selber wieder freigeben (im destruktor), das geht auch alles.
Nur wenn man das Fenster schliesst und wieder über den Button anzeigen lassen möchte, dann gibt es eine Fehlermeldung, die ich noch nicht so ganz verstehe.
Alternative war dann einfach alles so machen wie in meinem obigen Beispiel nur das Free weglassen. Dabei weiss ich allerdings nicht, ob der Speicher auch wieder freigegegen wird. Leider kenne ich kein Tool (Win32 -> MemProof) das mir das anzeigen könnte.
Deshalb rate ich von Show ab, mach es lieber mit ShowDialog.
Warum muss das Hauptfenster aktiv bleiben?

MfG
Thorsten

[Elvis]

Was du als "Free" bezeichnest ist in .Net Dispose des IDisposable Patterns, welches sich um alles kümmert, was für die GC unsichtbar ist (zum Beispiel DCs, Fenster,...).
Alles was IDisposable implementiert ist also potenziell memleak gefährdet.

Wenn du ein Form normal aufrufst, wird mit Close gleich ein Dispose ausgeführt.
Bei ShowDialog passiert das nicht! Wäre ja auch schlimm wenn dir der Dialog zerstört werden würde bevor du sein Ergebnis abfragen kannst. :zwinker:
Für modale Dialoge würde das also so aussehen:

Delphi-Quellcode:

using dialog := new DeineDialogKlasse() do
  if dialog.ShowDialog() = DialogResult.OK then
    ...

Oder in D.Net:

Delphi-Quellcode:

var dialog : DeineDialogKlasse;
begin
  dialog := DeineDialogKlasse.Create();
  try
    if dialog.ShowDialog() = &DialogResult.OK then
      ...
  finally
    dialog.Dispose();
  end;

Dispose würde auch durch den Finalizer aufgerufen werden, aber Finalizer sind Handbremsen und gehören zu den Dingen, die Unwissende gerne zu der Litanei ".Net ist langsam" verleiten. ;)

Zitat:

Leider kenne ich kein Tool (Win32 -> MemProof) das mir das anzeigen könnte.

Suche mal nach CLR Profiler im MSDN. Ist ein sehr gutes FreeWare Tool und zeigt dir Dinge an, von denen du in MemProof nur träumen konntest... :)

[omata]

@Elvis: Danke für deine Erklärungen.

Leider bist du auf die Verwendung von Show nicht eingegangen, gerade das wäre aber sehr interresant.

MfG
Thorsten

[Khabarakh]

Zitat:

Zitat von Elvis

Wenn du ein Form normal aufrufst, wird mit Close gleich ein Dispose ausgeführt.

Sozusagen ein sauberer Selbstmord :wink: .

Zitat:

When a form is closed, all resources created within the object are closed and the form is disposed. You can prevent the closing of a form at run time by handling the Closing event and setting the Cancel property of the CancelEventArgs passed as a parameter to your event handler. If the form you are closing is the startup form of your application, your application ends.

The one condition when a form is not disposed on Close is when it is part of a multiple-document interface (MDI) application, and the form is not visible. In this case, you will need to call Dispose manually to mark all of the form's controls for garbage collection.

[omata]

Ja wunderbar, nur der Ausgangsthread ging immer noch um Show wie wäre es wenn sich ein Wissender mal dazu herablassen könnte und uns nicht wissende mal etwas erleuchten würde.

Hoffnungsvollge Grüsse
Thorsten

[Khabarakh]

Zitat:

Ja wunderbar, nur der Ausgangsthread ging immer noch um Show

Tja, mein Post auch :stupid: .
Mit einem Aufruf von Show wird die Visible-Property auf true gesetzt. Hide bewirkt das Gegenteil. Wenn nun aber Close aufgerufen wird oder der User das Fenster schließt, wird - wie von Elvis und dem SDK schon geschrieben - das Fenster freigegeben.

Zitat:

Zitat von Reflector

Code:

private void WmClose(ref Message m)
{
      FormClosingEventArgs args1 = new FormClosingEventArgs(this.CloseReason, false);
      [...]
      if ((m.Msg != 0x11) && !args1.Cancel)
      {
            [...]
            base.Dispose();
      }
}

[gfjs]

Zitat:

Zitat von Khabarakh

Zitat:

Ja wunderbar, nur der Ausgangsthread ging immer noch um Show

Tja, mein Post auch :stupid: .
Mit einem Aufruf von Show wird die Visible-Property auf true gesetzt. Hide bewirkt das Gegenteil. Wenn nun aber Close aufgerufen wird oder der User das Fenster schließt, wird - wie von Elvis und dem SDK schon geschrieben - das Fenster freigegeben.

Zitat:

Zitat von Reflector

Code:

private void WmClose(ref Message m)
{
      FormClosingEventArgs args1 = new FormClosingEventArgs(this.CloseReason, false);
      [...]
      if ((m.Msg != 0x11) && !args1.Cancel)
      {
            [...]
            base.Dispose();
      }
}

Ach, khabarakh! - "Immer diese Fremdsprachen"!

Vielen Dank für Deine Bemühungen, aber damit kann ich leider gar nichts anfangen. :x Ich werd' einfach mal ein wenig rumprobieren und hoffen, dass ich weiterkomme.

mfg gfjs

[Khabarakh]

Kein Problem, der Reflector beherrscht auch Delphi :wink: . Allerdings war das ja nur als Zusatz gedacht, dass bei WM_CLOSE wirklich dispost wird - zum Verständnis ist das nicht nötig. Außerdem kann man IMHO auch ohne wirlkliche Ahnung von C# die Aussage des Codes verstehen, sonderlich lang ist er ja nicht.

Delphi-Quellcode:

procedure Form.WmClose(var m: Message);
[...]
      
      if ((m.Msg <> 17) and not args1.Cancel) then
      begin
            [...]
            inherited Dispose
      end
end;

[omata]

@gfjs: Danke, ich habs auch nicht verstanden.

@Khabarakh: ja, sowas habe ich mir auch schon gedacht. (ich konnte in deinem Post allerdings nichts finden, was darauf kontret eine Antwort liefert)
Wenn man aber mal in Delphi.NET bleibt und folgendes macht...

Delphi-Quellcode:

with TWinForm1.create do
  show;

dann klappt das natürlich.
Mit euren Aussagen zum selber aufräumen des Speichers habe ich aber so meine Probleme.
Kann man das irgendwie prüfen? Ok eventuell mit dem Profiler (aber wie? -> genaue Erklärung bitte)
Wenn ich nämlich mal den Taskmanager im Auge behalte während ich mein Fenster mit Show öffne, dann verbraucht meine Anwendung mehr Speicher (jedesmal wenn ich das zweite Fenster öffne).
Wenn ich es schliesse geht der Speicher aber nicht zurück.

Also kann mir das mal bitte einer erklären?

Erwartungsvolle Grüsse
Thorsten

[Elvis]

Zitat:

Mit euren Aussagen zum selber aufräumen des Speichers habe ich aber so meine Probleme.

Das Problem bei Fenstern ist, dass es kein richtiges Selberaufräumen gibt.
Es wird weiterhin ein Win32 Fenster angelegt, weiterhin wird mit Handles und Messages umhergeworfen (Glücklicherweise wird man selbst nur selten damit belästigt...).
Der Unterschied im Aufräumen bei Show <-> ShowDialog liegt in der Verwendung der beiden Methoden.
Bei Show ist es meist vollkommen legitim das Fenster beim Schließen zu zerstören. Bei ShowDialog braucht man aber meistens den Dialog nach dem Anzeigen um die Benutzereingaben auszuwerten.
Deshalb muss ein Dialog explizit freigegeben werden, indem man sich an IDisposable hält.

Preisfrage: Hast du ein MemLeak wenn du Dispose nach einem Dialog vergisst?
Nein, wie die meisten Klassen, die IDisposable implementieren, besitzt Form einen Finalizer, der ausgeführt wird wenn die GC das Form aufräumt. Der kann dann den ganzen Müll aufräumen...
Da Finalizer aber einen GC sweep _extrem_ ausbremsen sollte man immer Dispose aufrufen, statt es an den Finalizer abzutreten.
Fast alle .Net SPrachen bringen ein using statement mit (wie oben in meinem Chrome Schnipsel).
Dieses sorgt in einer Zeile dafür, dass eine Variable deklariert, besetzt und aufgeräumt wird.

Zitat:

Kann man das irgendwie prüfen? Ok eventuell mit dem Profiler (aber wie? -> genaue Erklärung bitte)

Schaue mal hier vorbei.
Vorsicht: FF-Fans sollten "http://msdn.microsoft.com/msdntv/" im Filter der liebenswerten IE Tab Extension haben um nicht auch noch dieses Mistvieh direkt starten zu müssen. ;)

Zitat:

Wenn ich nämlich mal den Taskmanager im Auge behalte während ich mein Fenster mit Show öffne, dann verbraucht meine Anwendung mehr Speicher (jedesmal wenn ich das zweite Fenster öffne).
Wenn ich es schliesse geht der Speicher aber nicht zurück.

TaskMan taugt eigentlich rein gar nix um etwas über den Speicherverbrauch auszusagen...
Genauer sind die Performance counter, die du unter Admin Tools (bzw Verwaltung im dtsch Windows) findest. Dort gibt dir "private Bytes" (unter Process) die wirkliche reservierte Speichergröße. Also minus das was durch geteilte Bibliotheken, wie die CLR, beansprucht wird.

[omata]

@Elvis: Danke für den Hinweis und den Link.

Habe mir das mal angesehen, sehr interresant.

Allerdings bekomme ich bei einer leeren Delphi.NET-Anwendung beim Beenden einen Fehler im Profiler, sodass mir leider keine Auswertesichten zur Verfühung stehen.

Warum ist es eigentlich nicht möglich hier mal mit einfachen Worten ein kleines, funktionierendes Beispiel (für Delphi.NET) zu zeigen, das die Verwendung von einem zweiten Formular, dass mit Show geöffnet wird, erläutert.

Ist das wirklich so aufwendig/kompliziert/zeitraubend?

Skeptische Grüsse
Thorsten

[Elvis]

Zitat:

Zitat von omata

Warum ist es eigentlich nicht möglich hier mal mit einfachen Worten ein kleines, funktionierendes Beispiel (für Delphi.NET) zu zeigen, das die Verwendung von einem zweiten Formular, dass mit Show geöffnet wird, erläutert.

Ist das wirklich so aufwendig/kompliziert/zeitraubend?

LOL nein :mrgreen:

Die Originalfrage war nur so billig, dass ich nicht darauf geantwortet hätte, wenn der Thread nicht diese Wende genommen hätte. ;)

Außerdem gab es diese Frage schon so oft, dass ich sie auch jetzt nicht beantworten _will_. (Wobei du das längst selbst getan hast, btw ;) )

[omata]

Schade, nur weil es für dich ganz einfach ist...egal will es gar nicht mehr wissen, dann eben nicht...

[Elvis]

Zitat:

Zitat von omata

Schade, nur weil es für dich ganz einfach ist...egal will es gar nicht mehr wissen, dann eben nicht...

War nicht dein erster Post in dem Thread hier die Antwort auf die Frage oder habe ich dich missverstanden? :gruebel: Mein vorheriger Post bezog sich auf die Frage des OT.

[gfjs]

@ Elvis

Guten Morgen!

Wenn man nur mit Grundkenntnissen aus Delphi5 sich mit Delphi 2005 rumschlagen muss, dann können auch solche "billigen" Fragen zu einem echten Problem werden. Vor allen Dingen, weil die Hilfe für WinForms-Anwendungen mehr als dürftig ist.

Insofern tut es mir leid, dass ich derzeit noch nicht mit qualifizierteren Fragen zu "echten" Problemen dienen kann. :cry: Aber: Was nicht ist, kann ja noch werden. Ich habe nicht den Eindruck, dass mir in nächster Zeit die Fragen ausgehen werden.

Bis dahin danke ich allen, die bereit sind, mir auch bei meinen billigen Fragen weiter zu helfen.

mfg gfjs

[Elvis]

Zitat:

Zitat von gfjs

Vor allen Dingen, weil die Hilfe für WinForms-Anwendungen mehr als dürftig ist.

Kleiner Tip: Schaue mal unter Microsoft .NET SDK 1.1\Documentation in deinem Startmenü. Dort wirst eine so umfassende Dokumentation für so ziemlich alles in .Net finden wie es sie für noch kein Delphi zuvor gegeben hat. Du solltest allerdings lernen C#, VB.Net oder CLI/C++ zu lesen, da die Doku von MS verständlicherweise keine Delphi Beispiele enthält. ;)

btw, Ich ja nachvollziehen, dass du ein wenig eingeschnappt bist auf meinen etwas direkten Kommentar. Du hast aber deine Antwort bereits nach 12 Minuten im ersten Beitrag dieses Threads erhalten. Da das für fast alle "billigen" Fragen gilt wüsste ich nicht warum ich darauf antworten sollte/müsste. ;)

[omata]

Zitat:

Zitat von Elvis

...Du hast aber deine Antwort bereits nach 12 Minuten im ersten Beitrag dieses Threads erhalten...

und das stimmt eben leider nicht!
Weil sich die eigentliche Frage nämlich auf SHOW (wie oft soll ich es eigentlich noch wiederholen) bezog. Meine Antwort zeigt aber nur die Verwendung von ShowDialog.

Ich habe mich dann mal mit dem Show-Aufruf beschäftigt und bekam nur Probleme.
Da sich dann noch andere in diesen Thread eingeklinkt haben dachte ich, da kann man doch mal nachfragen wie man das mit SHOW (wie oft soll ich es eigentlich noch wiederholen) richtig macht.
(Richtig machen soll heissen, wie es am elegantesten in Delphi.NET gemacht werden kann (bitte keine unzusammenhängende Codefetzen in anderen Dialekten).

Da das ja scheinbar so einfach ist, das man es nicht verraten will/soll/darf, habe ich es aufgegeben hier noch auf eine sinnvolle/funktionierende Antwort zu warten.

Wie ich schon schrieb will ich es gar nicht mehr wissen. Es geht hier scheinbar nur noch darum wichtig zu klingen aber Anlaufschwierigkeiten von Fragenden zu beantworten scheint nebensächlich zu sein.

Trotzdem finde ich es gut, dass gfjs Problem scheinbar gelöst wurde.
Auch wenn eine erneute Frage des Ausgangsthreads hier wohl zu einer Überforderung der Antwortenden geführt hat.

Schade,
Thorsten

[gfjs]

@ Elvis

NEIN! - Ich bin nicht eingeschnappt! :-D Sorry, wenn der Eindruck entstanden ist. Manchmal nervt es mich selber, wenn ich mit allzu simplen Fragen ins Forum muss. Im übrigen ist es oft so, dass ich aus der Diskussion, die sich über die ursprüngliche Frage hinweg entwickelt, noch zusätzliche Informationen bekomme, die mir helfen, besser durch zu blicken. Dein Tip mit dem SDK hilft mir im Moment nicht wirklich weiter, da C# und Konsorten für mich noch echte Fremdsprachen sind. Aber irgendwie werd' ich mich schon durchbeißen.

Servus aus München

gfjs

[Elvis]

Moin Thorsten,
Du hattest als Beispiel einen Dialog bentzt, richtig.
Direkt danach kam diese Frage:

Zitat:

Wenn ich ein Formular mit "Close" schließe, wird dann automatisch "Free" aufgerufen oder kann ich es dann einfach mit "Show" wieder anzeigen?

Und danach kam die Erklärung, das ein mit Show geöffnetes Fenster mit Close aufgeräumt wird. Dein Beispiel hatte den Dialog mit Free ( In D.Net ist Free ein Synonym für Dispose ;) ) aufgeräumt.

Zitat:

Ich habe mich dann mal mit dem Show-Aufruf beschäftigt und bekam nur Probleme.

Das passt doch zu dem Thema, in das wir abgerutscht sind. Wo kneift es denn?

Oh und nun zu den Dialekten...
KhabaDings ist ein C# Fan, während ich eher ein Chrome Fan bin. Biedes sind aber .Net Sprachen und es ist in der .Net Szene durchaus üblich, Dinge, die nicht sprachbezogen in der eigenen Sprache zu erklären... (home is where...). Die Klassen und deren Verhalten sind ja absolut identisch. Es mag vllt noch hinzukommen dass anscheinend keiner von uns beiden einen D.Net compiler zur Hand hat. ;)

[omata]

So, ich glaube ich weiss jetzt warum wir immer aneinander vorbeireden und ich versuche mein Problem jetzt nochmal zu beschreiben.

In Delphi (Win32) kann man sich ja Fenster beim Start automatisch initialisieren lassen. Diese Vorgehenweise finde ich sehr schlecht (Ausnahme natürlich die Hauptform). Wenn ich andere Fenster öffnen will, erstelle ich sie mir, zeige sie mit ShowModal und gebe den Speicher dann wieder frei. Das war ja auch das Beispiel was ich auf den Anfangspost geschrieben habe.

Nun gibt es aber ja auch die Möglichkeit mit Show das Fenster anzuzeigen. Bei Delphi (Win32) bleibt das gleiche Fenster immer aktiv auch wenn es geschlossen wird und wird beim Beenden des Programms automatisch freigeben. Oder man erstellt es selber und gibt es auch wieder selber frei.
Das Entscheidene ist jetzt das man in (Win32) immer das gleiche Fenster behält, während bei NET immer ein neues Fenster erstellt wird. Das heisst mein Aufrufbeispiel...

Delphi-Quellcode:

with TWinForm1.create do
  show;

erstellt immer ein neues Fenster, wenn ich also ein zweites Fenster sehe und nochmal auf der Hauptform obiges Ereignis auslöse, dann wird noch ein zweites Fenster angelegt und sichtbar. Das ist denke ich manchmal sinnvoll, aber was ist wenn es nicht sinnvoll ist? Wenn man immer nur ein Fenster haben möchte? Wie müsste man das dann realisieren? Der Benutzer kann das zweite Fenster schliessen, ich möchte ihm aber den Inhalt wieder präsentieren, wenn er dieses zweite Fenster wieder über die Hauptform sichtbar macht.
Aber ich denke das führt schon zu weit. Bleiben wir bei der einfachen Frage: "ich möchte nur ein zusätzliches Fenster sehen", egal wie oft ich die zweite Form mit Show aufrufe.
Gut das geht zum Beispiel über eine Private-Variable, die ich ja initialisieren kann. Allerdings was ist wenn der Benutzer das Fenster schliesst? Dann wird das Fenster freigegeben und die Private-Variable zeigt nicht mehr auf ein gültiges Objekt. Wie weiss ich jetzt das ich das Fenster neu initialisieren muss?

Hoffe mein eigentliches Problem wurde jetzt etwas verständlicher. Den mit ShowDialog (ShowModal) ergeben sich diese Probleme ja nicht, mit Show allerdings schon und genau das ist meine Verständnisfrage, wie könnte man soetwas sauber lösen.

Wieder hoffnungsvolle Grüsse,
Thorsten

[Elvis]

Du willst also die globale Variable des d32 Designers simulieren?
Der Trick wäre eine class property, die beim Zugriff eine Instanz anlegt und dieser AllowDisposing false über gibt.

Delphi-Quellcode:

class property Instance : Form1 read get_Instance;
property AllowDisposing : Boolean := true;

Delphi-Quellcode:

class function Form1.get_Instance: Form1;
begin
   if not assigned(fInstance) then
   begin
      fInstance := new Form1();
      fInstance.AllowDisposing := false;
   end;
   
   result := fInstance;
end;

Im FormClosing event noch das hier:

Delphi-Quellcode:

procedure Form1.Form1_FormClosing(sender: Object; e: FormClosingEventArgs);
begin
   if not AllowDisposing then
   begin
      e.Cancel := true;
      Hide();
   end;
end;

Damit ein Disosed fInstance auch wieder neu angelegt wird, müsste Dipose angepasst werden:

Delphi-Quellcode:

method Form1.Dispose(disposing: boolean);
begin
   if disposing then 
   begin
      if assigned(components) then
         components.Dispose();
      if self = fInstance then
         fInstance := nil;
   end;
   inherited Dispose(disposing);
end;

Im HauptForm sowas:

Delphi-Quellcode:

Form1.Instance.Show();

Das hätte auch den Vorteil, dass man weiter hin neue Instanzen von Form1 anlegen könnte, die sich beim Close zertören.

Edit, bin etwas handicapped, da ich eine andere Tastatur benutze... (Zu oft Alt + S statt Alt + D getippt :wall: )