Esegui codice personalizzato quando viene terminata l'app MFC: d'tor o WM_CLOSE?

Question

Ho un'applicazione MFC basata su una finestra di dialogo che deve arrestare il servizio Wifi di Windows per funzionare correttamente, ma desidero riattivarlo quando termina l'applicazione.

Quindi ho pensato di inserire il codice che riavvia il servizio nel distruttore della classe di dialogo principale.

Ora è venuto a conoscenza che altri inseriscono il codice che deve essere eseguito durante la chiusura del programma in un gestore di messaggi WM_CLOSE.

Entrambi i metodi sembrano funzionare, ma mi piacerebbe sapere se ci sono degli svantaggi in entrambi i modi.

Answer 1

Per l'applicazione basata su finestra di dialogo MFC, è possibile inserire il codice di finalizzazione nel metodo di classe applicazione InitInstance, immediatamente dopo la chiamata di dialogo principale DoModal. Per altri tipi di applicazioni MFC (MDI, SDI), il codice di finalizzazione viene di solito inserito nel metodo ExitInstance.

La differenza tra l'applicazione basata su finestra di dialogo e le applicazioni SDI/MDI, è che InitInstance nelle applicazioni basate su finestre restituisce FALSE e le uscite dell'applicazione: tutte le azioni vengono eseguite nella chiamata principale DoModal.

Si può preferire usare ExitInstance per tutti i tipi di applicazione, dovrebbe funzionare anche.

Modifica. Se si desidera creare codice di pulizia all'interno della classe di dialogo, WM_DESTROY (già citato da Roger Rowland) è il posto migliore di WM_CLOSE. A volte possiamo gestire il messaggio WM_CLOSE e impedire la chiusura di una finestra di dialogo, ad esempio, chiedendo "Esci dal programma? Sì - No". Nel caso in cui si desideri utilizzare alcune finestre secondarie, esse esistono nei gestori di messaggi WM_CLOSE e WM_DESTROY e non esistono in un distruttore di finestre di dialogo. Inoltre, la coda dei messaggi non esiste quando viene chiamato il distruttore della finestra di dialogo principale, quindi in questo caso non utilizzare la messaggistica di Windows.

Answer 2

Mirare a mantenere la simmetria: se si interrompe il servizio wifi in un costruttore, riavviarlo nel distruttore della stessa classe. Se invece si interrompe il servizio in InitInstance, lo si riavvierà in ExitInstance; se come risposta a WM_CREATE o qualche altro messaggio, quindi riavvialo in WM_CLOSE, ecc.

I costruttori e i distruttori non hanno modo di restituire uno stato di errore, quindi normalmente sono più adatti per compiti semplici come l'inizializzazione e l'allocazione di memoria/deallocazione.

InitInstance e ExitInstance, così come le finestre messaggi come WM_CLOSE, avvengono in un buon posto nella vita dell'applicazione per visualizzare i messaggi di errore, se necessario, o per interrompere in risposta alle condizioni di errore.