[nonVCL] Endlosschleife mit 2 Fenstern

[lbccaleb]

Hallo,

hab mal wieder ein kleines Problem und kann den Fehler nicht finden :stupid:

Also ich habe eine Simple nonVCL Anwendung mit einer MainForm und 2 Buttons.
Auf klick der Buttons öffnet sich ein weiteres Fenster.

Bisdahinn alles schick.

Wenn aber nun eins der beiden Fenster geöffnet ist, und ich die MainForm schliesse hängt sich das Programm in einer Endlosschleife fest und das obwohl ich vor dem schliessen ein WM_CLOSE an die Fenster schicke.

Mein Problem ist, ich finde einfach den Fehler nicht. Wieso sich das Programm dann festhängt.

Kann mir da einer weiterhelfen und weiß wo genau mein Fehler da liegt, und wie ich das korrigieren kann?

Habe das kleine Testprojekt angehangen.

[EWeiss]

Wenn die Mainform "first form ist" dann solltest du nur hier die messagen behandeln
andernfalls hängt die Anwendung in den anderen Form's bei GetMessage.

Ausblenden.. bzw entfernen in Form1 und Form2

Delphi-Quellcode:

while GetMessage(msg, 0, 0, 0) do
      begin
        if IsDialogMessage(hTest1Wnd, msg) = FALSE then
          begin
            TranslateMessage(msg);
            DispatchMessage(msg);
          end;
      end;

Frage mich auch warum du einen zugriff auf die Hauptform überhaupt zuläßt
Schalte diese doch auf enabled = False wenn du schon modale Forms öffen willst.

Auch darf dann in Form1 und Form2 ein

Delphi-Quellcode:

    WM_DESTROY:
      begin;
        PostQuitMessage(0);
      end;

nicht behandelt werden da du dann die gesamte Anwendung dadurch beendest.

Ein

Delphi-Quellcode:

    WM_CLOSE:
      begin
        DestroyWindow(hWnd);
      end;

sollte ausreichen um das Fenster korrekt zu beenden.

gruss

[lbccaleb]

Also ich will die Form nicht disablen, da alle noch nutzbar sein sollen, auch wenn die Child Fenster geöffnet sind.

Aber durch dich hab ich trotzdem endlich die Lösung gefunden.
Die eigentlich auch klar war :oops:

Ich muss nachtürlich in der Nachrichtenschleife der Childs auf die WM_CLOSE Message reagieren. Dann funktioniert es wie es soll:

Delphi-Quellcode:

    while GetMessage(msg, 0, 0, 0) do
      begin
        if IsDialogMessage(hTest1Wnd, msg) = FALSE then
          begin
            if Msg.message = WM_CLOSE then Break;
            TranslateMessage(msg);
            DispatchMessage(msg);
          end;
      end;

[EWeiss]

GetMessage sollte nur in der Hauptform behandelt werden.

Aber gut jeder wie er will ;)

gruss

[lbccaleb]

Sorry doppel post..

[lbccaleb]

Ich weiß nicht genau wie ich GetMessage aus den Childs rausbekommen soll?!
Wie würdest du das denn machen?

Was ist denn mein Message Handler in den Fenstern?

Edit:

Würdest du vllt. oben das gepostete Bsp. mal anpassen wie du es meinst? Das wäre sehr nett :thumb:

Edit2: Ohh wieso hat er das Edit als neuen Beitrag verfasst :gruebel:

[EWeiss]

Bitte

Zitat:

Was ist denn mein Message Handler in den Fenstern?

Wenn ich nicht falsch liege der aus dem der Thread gestartet wurde.
Pro Thread kann/könnte man einen Message Handler verwenden da du das 2 Fenster aus dem Thread der MainForm aufrufst
benötigst du hier keinen weiteren Handler. (meiner erfahrung nach :gruebel:)

gruss

[DeddyH]

Macht doch bitte aus

Zitat:

Delphi-Quellcode:

if IsDialogMessage(hAppWnd, msg) = FALSE then

Delphi-Quellcode:

if not IsDialogMessage(hAppWnd, msg) then
  ...

Ich bekomme immer Augenkrebs bei Boolean-Vergleichen ;)

[EWeiss]

Zitat:

Ich bekomme immer Augenkrebs bei Boolean-Vergleichen

Oder Netzhautablösung ;) Hehehehhe

Spass beiseite ist nur ein kosmetischer Fehler.
Wenn der Compiler damit nicht klar kommt dann taugt er einfach nix.

gruss

[lbccaleb]

Vielen Dank!

Ich war immer in dem Glauben das ich für jedes Fenster nen eigenen Message Handler brauche. Da hab ich mich wohl kräftig geirrt :shock:
Ist aufjedenfall abgespeichert ;)

[EWeiss]

Zitat:

Zitat von lbccaleb (Beitrag 1199445)

Vielen Dank!

Ich war immer in dem Glauben das ich für jedes Fenster nen eigenen Message Handler brauche. Da hab ich mich wohl kräftig geirrt :shock:
Ist aufjedenfall abgespeichert ;)

Hab meinen Beitrag nochmal editiert
http://www.delphipraxis.net/1199436-post7.html

gruss

[Luckie]

Guck mal hier: http://michael-puff.de/Programmierung/Delphi/Tutorials/ -> Win32API_Delphi

[lbccaleb]

Zitat:

Zitat von Luckie (Beitrag 1199503)

Guck mal hier: http://michael-puff.de/Programmierung/Delphi/Tutorials/ -> Win32API_Delphi

Vielen Dank. Aber ich kenne deine Tutorials. Die wirklich klasse sind, danke dafür :thumb:

Das lag bei mir wohl eher am nicht wissen durch "hat vorher perfekt funktioniert" :lol:
Naja und dadurch hab ich mir nie nen Kopf drüber gemacht, wie es anders sein sollte..
Bis Heute! Aber man lernt nie aus und nun sollte ich es verstanden haben :)

[Luckie]

Also pro Fenster eine Nachrichtenschleife ist nicht verkehrt. Weil die Nachrichten der Kind-Fenster an das übergeordnete Fenster weitergereicht werden. Ein Klick auf eine Schaltfläche in Fenster 2 geht auch an das Fenster 2 und sollte da behandelt werden.

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1199584)

Also pro Fenster eine Nachrichtenschleife ist nicht verkehrt. Weil die Nachrichten der Kind-Fenster an das übergeordnete Fenster weitergereicht werden. Ein Klick auf eine Schaltfläche in Fenster 2 geht auch an das Fenster 2 und sollte da behandelt werden.

Aber unnötig bei einem Thread.

Zitat:

The GetMessage function retrieves messages associated with the window identified by the hWnd parameter or any of its children, as specified by the IsChild function, and within the range of message values given by the wMsgFilterMin and wMsgFilterMax parameters. Note that an application can only use the low word in the wMsgFilterMin and wMsgFilterMax parameters; the high word is reserved for the system.

gruss

[Luckie]

OK, aber bei mir hat jedes Fenster seine eigen Fensterprozedur, der Übersichtlichkeit halber, und dazu gehört für mich eben auch jeweils eine Nachrichtenschleife.

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1199592)

OK, aber bei mir hat jedes Fenster seine eigen Fensterprozedur, der Übersichtlichkeit halber, und dazu gehört für mich eben auch jeweils eine Nachrichtenschleife.

Das kann dann aber zu dem im ersten Beitrag aufgeführten problemen führen.

Selbst wenn du im zweiten Dialog einen Extra Handler hast werden die Messagen an dem Handler der Anwendung weitergeleitet denn dieser ist für
den aktuellen Thread maßgeblich.
Oder warum sonst gibt es hier in diesem Fall einen Endlos Loop? Nach dem schließen der Mainform.

Also doppelt gemoppelt.

Aber wie gesagt jeder wie er will..

gruss

[lbccaleb]

Das hört sich allerdings logisch an, was Emil da sagt.
Es gab mit mehreren Message Handlern ausserdem Probleme mit WM_KEYDOWN.
Dann hat nämlich die Form die Pfeiltasten sowie die Entertaste nicht erkannt.

Mit nur einer Schleife läuft das jetzt aber ohne Probleme.

[Luckie]

Also bei mir hat es ohne Probleme so geklappt, wenn ich mich recht erinne.

[EWeiss]

Zitat:

Zitat von lbccaleb (Beitrag 1199605)

Das hört sich allerdings logisch an, was Emil da sagt.
Es gab mit mehreren Message Handlern ausserdem Probleme mit WM_KEYDOWN.
Dann hat nämlich die Form die Pfeiltasten sowie die Entertaste nicht erkannt.

Mit nur einer Schleife läuft das jetzt aber ohne Probleme.

Es ist/sollte auch nicht die regel sein die WinMessagen innerhalb eines Message handler zu breaken..
Wieviele sollte man dann innerhalb des 2 Handlers umbiegen?
Das ist nicht der sinn eines Messagehandlers wenn man hier messagen außen vor läßt.

gruss

[lbccaleb]

Ich habe gerade mal die alten nonVCL DirectDraw bsp. von Microsoft durchgestöbert und auch die benutzen nur einen Message Handler bei 2 Dialogen in Ihren Bsp.

[EWeiss]

Zitat:

Zitat von lbccaleb (Beitrag 1199613)

Ich habe gerade mal die alten nonVCL DirectDraw bsp. von Microsoft durchgestöbert und auch die benutzen nur einen Message Handler bei 2 Dialogen in Ihren Bsp.

Macht auch sinn. ;)
Abgesehen davon wenn ich in DLL's mehrere Threads erstelle dann benötige ich für jeden einen Handler.
Da diese bekanntlich unabhängig von einander arbeiten.

gruss

[lbccaleb]

@Luckie:

Schaau dir mal bitte das Bsp an was ich angehangen hab.
Das verdeutlicht was ich meine!

Button1 Fenster ohne eigenen Message Handler
Button2 mit Message Handler

Edit:

Wenn das 2 Fenster geöffnet wurde (Button2) dann muss das Prog per Taskplaner gekillt werden. Wegen der Endlosschleife..

[turboPASCAL]

Ich habe ein wenig in Deinem Quelltext herumgepfuscht. ;)

Bitte schalte mal die Bereichs.-u. Überlaufsprüfung ein...

[EWeiss]

Leicht OT:
Hätte selber noch was geändert.

frmMainForm.WinMain(hInstance, System.hPrevInst, System.CmdLine, System.CmdShow);

Zitat:

[DCC Warnung] Template.dpr(24): W1000 Symbol 'HPrevInst' ist veraltet
[DCC Warnung] Template.dpr(24): W1002 Symbol 'CmdLine' ist plattformspezifisch

Wenn "System.hPrevInst, System.CmdLine, System.CmdShow" in der function WinMain keine weitere verwendung findet
warum dann nicht einfach 0 , nil, 0 ?

Und unnötige Warnungen von vornherein gar nicht erst produzieren.

Nur ein kleiner zusätzlicher TIP..

Delphi-Quellcode:

const
  Mutex = 'Template_Mutex';

Warum nicht 'Template_Mutex' direkt übergeben da nur einmal verwendet
das ersparrt unnötiges konvertieren nach PAnsiChar

gruss

[lbccaleb]

Zitat:

Zitat von turboPASCAL (Beitrag 1199676)

Ich habe ein wenig in Deinem Quelltext herumgepfuscht. ;)

Bitte schalte mal die Bereichs.-u. Überlaufsprüfung ein...

Woran liegt es, dass das Programm mit eingeschalteten Range Checks abstürzt? Was ist dafür verantwortlich??

[EWeiss]

Zitat:

Zitat von lbccaleb (Beitrag 1199699)

Zitat:

Zitat von turboPASCAL (Beitrag 1199676)

Ich habe ein wenig in Deinem Quelltext herumgepfuscht. ;)

Bitte schalte mal die Bereichs.-u. Überlaufsprüfung ein...

Woran liegt es, dass das Programm mit eingeschalteten Range Checks abstürzt? Was ist dafür verantwortlich??

Sorry wenn ich antworte..
Ich habe es bei mir getestet mit Bereichs.-u. Überlaufsprüfung.
Da stürzt nix ab.

gruss

[lbccaleb]

Also bei mir stürzt es ab, wenn:

Delphi-Quellcode:

SendMessage(hBmpButton4, WM_SETFONT, MAKEWPARAM(hAppFont, 0), 0);

nicht in :

Delphi-Quellcode:

SendMessage(hBmpButton4, WM_SETFONT, INTEGER(hAppFont), 0);

geändert wird. Bei MakeWParam greift der RangeCheck.

[turboPASCAL]

Genau.

Delphi-Quellcode:

MAKEWPARAM()

erwartet als Parameter Word, hAppFont ist aber ein Integer.
Im Anhang noch mal die Testapp mit verbessertem Fensterhandling in dem bei dem Subwindows als Parnet des Hauptfensters erzeugt werden.