Witam
Zastanawiam się czy funkcję DestroyWindow() można bezpiecznie umiescić w destruktorze klasy reprezentującej okno. Problem polega na tym, że
#w momencie wywołania destruktora, ale przed wywołaniem DestroyWindow() w procedurze okna może być użyty właśnie niszczony obiekt
#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.
Pytanie jest więc nastepujace:
Czy musze miec metodę niczsząca okienko niezależną od destruktora czy moze da się to jakoś pogodzić?
0
1
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ędzyDestroyWindowaWM_DESTROYmożesz dostawać jeszcze normalne komunikaty.
Pokaż może z grubsza, jak twój kod wygląda.
0
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
DestroyWindowaWM_DESTROYmożesz dostawać jeszcze normalne komunikaty.
Ale WM_DESTROY będzie już ostatnim komunikatem i mogę usunąć obiekty reprezentujące okna?
1
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.
0
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.
0
Da się może jakoś odciąć okno od wszystkich komunikatów oprócz wybranych?
Nie bardzo rozumiem po co miałbyś to robić, ale:
- 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śnieDispatchMessagewywołujeWndProc), ale… - …praktycznie to nie masz nad pętlą pełnej kontroli, bo głupi
MessageBoxma własną standardową pętlę i komunikaty zaczną do okna przychodzić kiedy message box jest na ekranie. - może lepiej wyłączać ukryte okna (
EnableWindow(hwnd, FALSE))?
0
@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...
0
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 ;-)
0
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 :)