DestroyWindow() a destruktor

DestroyWindow() wysyła komunikaty WM_DESTROY i WM_NCDESTROY ale chyba nie ma żadnej gwarancji, że w miedzyczasie nie otrzymam jakiegoś innego komunikatu przy którym będę odwoływał sie do niszczonego obiektu.
Nie ma gwarancji. Pomiędzy DestroyWindow a WM_DESTROY możesz dostawać jeszcze normalne komunikaty.

Pokaż może z grubsza, jak twój kod wygląda.

Jeszcze nie wygląda;P tzn kod jest ale dosyć rozgrzebany, miałem problem z widocznościa i postanowiłem od nowa wszystko upakowac w klasach.

Ogólnie sprawa wygląda tak:
*każde okno ma swoją klasę
*konstruktor tworzy okno, kontrolki itd
*destruktor miał niszczyć okno.
Zastanawiam się teraz czy w ogóle nie napisać metody niszczacej okno bo chyba w żaden sposób nie zabezpieczę sie przed sytuacją z punktu 1, racja?

Azarien napisał(a):

Pomiędzy DestroyWindow a WM_DESTROY możesz dostawać jeszcze normalne komunikaty.

Ale WM_DESTROY będzie już ostatnim komunikatem i mogę usunąć obiekty reprezentujące okna?

Wydaje mi się, że większość okien zamyka w taki albo inny sposób użytkownik, więc jakiejś metody Close raczej nie unikniesz. Być może i Open się przyda, oddzielna od konstruktora.

Ale WM_DESTROY będzie już ostatnim komunikatem i mogę usunąć obiekty reprezentujące okna?
Ostatnim jest WM_NCDESTROY, ale pod warunkiem że w WM_DESTROY ani WM_NCDESTROY nie wysyłasz żadnego nowego komunikatu.

Generalnie wszystkie okna mają być tworzone na starcie i ukrywane (ustawienia, podglad plików). Gdzieś widziałem takie podejście i chyba jest lepsze niż tworzenie i niszczenie za każdym razem gdy user kliknie na odpowiedni button. Główne okno pojawia się gdy kursor zbliży sie do krawędzi pulpitu, ma przycisk 'Exit' i w reakcji na niego wszystkie okna mają byc niszczone i obiekty kasowane.

Da się może jakoś odciąć okno od wszystkich komunikatów oprócz wybranych? Umieściłbym taką funkcę w reakcji na przycisk 'Exit' i przepuścił tylko WM_DESTROY, WM_NCDESTROY. Wtedy całą sprawą niszczenia okna zająłby się destruktor.

Da się może jakoś odciąć okno od wszystkich komunikatów oprócz wybranych?
Nie bardzo rozumiem po co miałbyś to robić, ale:

1. teoretycznie masz przecież kontrolę nad pętlą komunikatów. Więc dla wybranych komunikatów możesz po prostu nie robić DispatchMessage (bo to właśnie DispatchMessage wywołuje WndProc), ale…
2. …praktycznie to nie masz nad pętlą pełnej kontroli, bo głupi MessageBox ma własną standardową pętlę i komunikaty zaczną do okna przychodzić kiedy message box jest na ekranie.
3. może lepiej wyłączać ukryte okna (EnableWindow(hwnd, FALSE))?

@Azarien Zrobiłem jak radziłeś metody create/destroy (zamiast open/close imo lepiej pasują :) ) ale pojawił się nowy problem.
Mianowicie: tworzenie obiektu okna wygląda tak:

• metoda create
• rejestracje klasy okna
• tworzenie okna
  *tworzenie kontrolek

Problem w tym, że po utworzeniu okna jego procedura już pracuje, i może skorzystać z obiektu, który przecież jeszcze nie jest gotowy (tworzenie kontrolek i inne operacje). Póki co nie ma żadnego błędu ale chyba lepiej dmuchać na zimne. Chciałem dodać styl WS_DISABLED i odblokować okno gdy już obiekt będzie gotowy ale ten styl blokuje 'input from the user' więc pewnie tylko klawiaturę i myszkę tak jak EnableWindow(hwnd, FALSE).
Czy jedynym rozwiązanie jest przeprojektowanie całej aplikacji tak aby uniknąć takich konfliktów?

BTW coraz częściej zastanawiam się czy w ogóle można w WinAPI pisać używając obiektowości. Wiem, że to API jest stare ale uważam, że podstawy mogą się przydać tym bardziej, że nie jest zależne od kompilatora tak jak MFC/WTL itp...

BTW coraz częściej zastanawiam się czy w ogóle można w WinAPI pisać używając obiektowości
Przecież całe MFC to zestaw klas opakowujących WinAPI. Istnienie MFC dowodzi, że można.

Problem w tym, że po utworzeniu okna jego procedura już pracuje, i może skorzystać z obiektu, który przecież jeszcze nie jest gotowy (tworzenie kontrolek i inne operacje).
Nie widzę twojego kodu więc nie widzę problemu ;-)

Azarien napisał(a):

BTW coraz częściej zastanawiam się czy w ogóle można w WinAPI pisać używając obiektowości
Przecież całe MFC to zestaw klas opakowujących WinAPI. Istnienie MFC dowodzi, że można.

Racja ale MFC napisali ludzie kompetentni, przynajmniej w teorii, nie znam tej biblioteki wiec się nie będę wypowiadał :) A przede mną długa droga do chociażby programisty-amatora :)

Azarien napisał(a):

Problem w tym, że po utworzeniu okna jego procedura już pracuje, i może skorzystać z obiektu, który przecież jeszcze nie jest gotowy (tworzenie kontrolek i inne operacje).
Nie widzę twojego kodu więc nie widzę problemu ;-)

Głupotę tu palnąłem. Przecież ja pisze funkcje obsługujące poszczególne komunikaty i wstawiam je w WndProc, więc mam kontrolę nad tym co sie w procedurze dzieje i sama z siebie nie użyje żadnego obiektu :) Sorki za zamieszanie, temat do zamknięcia :)