mein Problem ist folgendes:

Ich bin eben dabei einen Wecker zu programmieren, über CreateDialog():

[cpp]      hwnd = CreateDialog(hThisInstance, MAKEINTRESOURCE(IDD_UHR),
             NULL, uhrproc);
             [/cpp]

Um das Teil so klein wie möglich zu halten hab ich versucht auf das Hauptfenster zu verzichten, was auch soweit geklappt hat. Allerdings bin ich mit dem Versuch gescheitert die Dlg-Prozedur als Hauptprozedur (wndproc) umzuschreiben (ich bekomm da einen Invalid Conversion Error weil mein Dialog ein Bool-Callback ist). Das Programm läuft, allerdings sieht es so aus als ob die (immer noch vorhandene) wnd-proc komplett ignoriert wird.
Das Freigeben der verwendeten Resourcen beim Ausstieg aus dem Programm hab ich somit dann mal in WM_CLOSE im Dialog-Fenster gepackt statt in WM_DESTROY in der wnd-proc.

Meine Frage ist nun:

Ist der von mir eingeschlagene Weg statthaft oder gibt es eine andere, sauberere Lösung (wovon ich mal stark ausgehe)?

Hab schon im Forum gesucht, aber leider nix gefunden was annähernd Bezug zu meinem 'Problem' hätte.

Danke im Voraus für Eure Hilfe!

Michael

Ist der von mir eingeschlagene Weg statthaft oder gibt es eine andere, sauberere Lösung (wovon ich mal stark ausgehe)?

dialoge sind auch nur stinknormale fenster
ich würds auch so machen...;)

Hab das ma so umgesetzt und es läuft erwartungsgemäß.

Unabhängig davon hab ich aber ein anderes Problem.
Mir ist aufgefallen dass nach längerem 'Betrieb' meines Weckers die User Resourcen (ich hab W98se) extrem in den Keller gehen. Hab schon mehrfach kontrolliert ob ich Resourcen ordnungsgemäß wieder freigebe und alles scheint korrekt zu sein, wobei das meiste eh erst am Programmende freigegeben wird.
Diese Probleme sind bei anderen Applikationen die ich geschrieben habe nie aufgetreten. Da ich dort aber auch keinen Timer benutzt hab vermute ich dass es möglicherweise etwas damit zu tun hat.

Hat jemand irgendwelche Tips wie ich der Sache auf den Grund gehen kann?

Danke im Voraus!

Michael

Gruß

Michael

Könnte die MessageBox prinzipiell für den hohen Resourcenverbrauch verantwortlich gewesen sein?

Definitiv nein!

CodeJunkie schrieb:

Ich mein, die Abarbeitung von WM_TIMER ist ja dadurch an der Stelle gestoppt, aber die Messages laufen weiter ein....?¿

Sobald Du mit return oder break aus dem case WM_TIMER rausspringst nicht! Du bekommst immer nur 1 WM_TIMER-Nachricht, solange Du die vorherige nicht aus der MessageQueue abgearbeitet hast, ja.

CodeJunkie schrieb:

Könnte die MessageBox prinzipiell für den hohen Resourcenverbrauch verantwortlich gewesen sein?

Definitiv nein!

CodeJunkie schrieb:

Ich mein, die Abarbeitung von WM_TIMER ist ja dadurch an der Stelle gestoppt, aber die Messages laufen weiter ein....?¿

Sobald Du mit return oder break aus dem case WM_TIMER rausspringst nicht! Du bekommst immer nur 1 WM_TIMER-Nachricht, solange Du die vorherige nicht aus der MessageQueue abgearbeitet hast, ja.

Hm, seltsam. Ich hab das Teil nun mal über Nacht durchlaufen lassen und die User-Resourcen sind konstant geblieben.
Wo liegt nun mein Denkfehler bezüglich der Timer-Nachrichten? Wenn ich innerhalb von WM_TIMER eine Messagebox öffne und diese nicht mit OK (oder sonstwas) bestätigt wird, wird der case WM_TIMER doch auch nicht komplett abgeschlossen, oder? Prinzipiell könnte man ja den Rückgabewert der MessageBox auswerten wollen, im Anschlußcode und zum Beispiel je nach Wert das Progi beenden etc. Zumal, das hab ich in meinem letzten Post vergessen, WM_TIMER ja auch für die Aktualisierung der Uhrzeitanzeige verantwortlich ist. Im Falle des Alarms (hatte!) ich zwar durch Änderung des Variablenwertes die folgende Vergleichsfunktion + den Folgecode bei Übereinstimmung ausgegliedert, für zukünftige Messages, aber die Anzeige der aktuellen Uhrzeit funktionierte weiterhin. Somit müßten ja weiterhin WM_TIMER Nachrichten eingegangen und abgearbeitet worden sein.
*verwirrtbin*

Gruß

Michael