MFC dialog based application...

Cut it out, AP.

I think the dialog is modeless iirc (you can find out by checking for any calls to DoModal in your application for that dialog) but it doesn''t really matter since it''s the lowest level of your application, so you can always do it in the destructor.

-fel

Actually, they''re modal. If you look in InitInstance of the application, you''ll see how it works. Modal dialogs are actually a great way to start working under MFC since you
don''t need to work as hard to get them running and you can just
paint controls inside the dialog editor. The dialog will close whenever you call EndDialog. By default, I think the ESC will close the dialog.

BTW, garbage collection isn''t any more important here than any other Windows application. There are some gotchas you need to be aware of like deleting GDI handles you aren''t using, but under MFC, as long as the object destructor gets called, you''re generally cool with the memory being released. When in doubt, pull up your Task Manager and watch the allocated GDI objects and memory usage at different breakpoints in your program.

If you plan to develop a lot under Windows, work hard to learn MFC. It is a great infrastructure for building tools. It doesn''t necessarily work great for complex games - but it sounds like you''ve already assumed that anyway.

Good luck.

How did you decide they''re modal? The app calls ShowWindow off the bat, and an SW_SHOW would be kind of pointless to call for a modal dialog if it were a modal dialog. That would kind of indicate to me that it''s modeless, though there isn''t a Create() call in the provided code (then again there isn''t a DoModal() either so that''s kind of ambiguous). Not to mention that if it were true modal, the app and doc technically wouldn''t be able do anything at all for the duration of the dialog being up.

Realistically I''m not sure that the concepts "modal" or "modeless" even make sense on a dialog application, because "modal" and "modeless" mostly apply to the way the dialogs interact with their parent application.

-fel

I''m not sure that you''re looking at the right kind of application. When you create a dialog-based application with appwizard (at least in VC6.0), it does so by putting a DoModal in InitInstance. DoModal shows the dialog as a modal entity. As far as the presence of ShowWindow, I don''t have it anywhere in my app, but it would nevertheless be required in a modal dialog if you happened to uncheck its ''visible'' property in the resource editor. Ergo, ShowWindow is a non-issue here.

I don''t think you need to confuse the original question about theoretical differences between modal and modeless. They each have very real behaviors that are important for a Windows programmer to understand. Just because there isn''t a window to be disabled behind the dialog doesn''t mean that it isn''t a modal window.

Ah, found it, you''re right.

That''s what I get for having 5 copies of VC up at the same time.

Back to the original question... it''s very rare that you have to do your own garbage collection in MFC, unless you''re using GDI. With GDI you''re probably going to be using a custom control anyway so you should do the collection inside the control destruction, not in the dialog destruction.

-fel

VC++ 6.0 documentation:

CDialog:

"When you implement a modeless dialog box, always override the OnCancel member function and call DestroyWindow from within it. Don’t call the base class CDialog::OnCancel, because it calls EndDialog, which will make the dialog box invisible but will not destroy it. You should also override PostNcDestroy for modeless dialog boxes in order to delete this, since modeless dialog boxes are usually allocated with new. Modal dialog boxes are usually constructed on the frame and do not need PostNcDestroy cleanup."



What''s all this about so?