X marks what spot?

X marks what spot?

I am new to writing CVF windows apps.

I selected a simple dialog app from the initial NEW project screen,
then compiled it without any changes. While the default Exit button closes the app (i.e. calls the xxxsub handler with dlg_destroy msg), the window-X (upper right corner) does absolutely nothing, and the handler is never called.

I don't even know where to begin to look.
The project is >100K so I do not think I can attach it here, but if it helps I can post it somewhere else for download.

Any ideas will be appreciated.

Tim

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Click on X button generates IDCANCEL event, i.e. it is the same as if user clicked Cancel button. If you change the ID of Exit button to IDCANCEL, you'll get the desired behaviour.

I'd note that IMNSHO designers of CVF application wizards could have done a bit better job in this respect. Btw, I find tabs in generated source code annoying (apart from the fact that they're non-standard).

Jugoslav

Jugoslav
www.xeffort.com

Thanks,
It does work, but I am still confused about how this works.

If you are inclined to write more:

1.Without this change, who catches the event generated by the X button?,

2. Now with the change how does changing the ID on one button affect the other?

3. what is the difference between IDCANCEL and ID_EXIT?

Thanks,
Tim

IDOK (=1) and IDCANCEL (=2) are system-predefined values.

In Win32, the dialogs work the following way: There's a general-purpose API funcion DefDlgProc. It catches all events* in the dialog, and it's common for all dialogs. On any event, DefDlgProc calls user-defined logical function DialogProc. If DialogProc returns .TRUE., DefDlgProc does nothing; otherwise, it performs some default processing (which is in many, but not all, cases also nothing). Note that dialogs are windows like any other; it's DefDlgProc where some aspects of behaviour are determined.

Now, DFLOGM is still one layer above the whole thing. DFLOGM.f90 contains DialogProc (called CommonDlgProc), which calls user-defined callbacks if any, and synchronizes contents of dialog controls with variables within DIALOG structure.

What happens when user presses X?:
1) System sends WM_SYSCOMMAND/SC_CLOSE message to DefDlgProc.
2) DefDlgProc passes it to DFLOGM::CommonDlgProc; it returns .FALSE.
3) DefDlgProc, seeing it's not processed, generates a WM_COMMAND/IDCANCEL message and calls DFLOGM::CommonDlgProc again.
4) a) Since there ain't an IDCANCEL button, DFLOGM::CommonDlgProc concludes that there isn't any control with that ID** and does nothing. DefDlgProc does nothing either.
b) If there is an IDCANCEL button, DFLOGM::CommonDlgProc looks as if it has a callback; oh yes it does. It calls it, and there's written an DlgExit (or whatever). Dialog closes.

Note step 3: this is hard-coded into Windows and this is what makes IDCANCEL special. Thus, the dialog application created by CVF AppWizard should better have an IDCANCEL button instead of some user-defined ID_EXIT.

Jugoslav

*) Events (messages) can come from the user/system, but can be generated ("faked") as well, using SendMessage.
**) By default, in DFLOGM, pressing a button without defined callback closes the dialog. However, in this case it won't happen since DFLOGM won't recognize IDCANCEL as a button or anything.

Jugoslav
www.xeffort.com

Leave a Comment

Please sign in to add a comment. Not a member? Join today