DDT Dialog Close

[Colin Mair]

I have a simple program with one DDT Dialog box. What is the
correct way to handle a user clicking on the X on the caption bar
to close it ? This is how I'm handling it at the moment :-

' Display the mail dialog modeless to allow program execution to continue.

DIALOG SHOW MODELESS hDlg TO MainResult

' Code to get network information etc.

' Loop allowing dialog events until the MainResult is set or no dialogs !

DO

DIALOG DOEVENTS TO Count

LOOP WHILE MainResult = 0 AND Count > 0

EXIT FUNCTION 'Exit PBMAIN

This works - but the manual states that DOEVENT shouldn't be
called if there are no Dialogs and the user may have closed the
one and only Dialog !!




------------------
Colin Mair

[Lance Edmonds]

Your DIALOG DOEVENTS loop should terminate when the modeless dialog is closed, so you should not experience any problems. In otherwords, your code is probably working fine.

The following is supposition based on the fact that we not seen all of your dialog callback code.

Unless your dialog callback explicitly calls DIALOG END CBHNDL, value& for all possible closure conditions, then one condition of your DOEVENTS loop will not be satisfied. That is, your loop is really reliant on the "modeless dialog counter" value and not the return value of the dialog.

Therefore, if the dialog does not intercept %WM_SYSCOMMAND|%SC_CLOSE to handle the closure, then no dialog return value will be passed back. I would guess that you have a BUTTON that also dismisses the dialog, and I would guess that you are calling DIALOG END there.

Generally speaking, I write my DIALOG DOEVENTS loop like this:

'Psuedocode
DO
  DIALOG DOEVENTS
  DIALOG GET SIZE hDlg& TO x&, x&
LOOP WHILE ISTRUE x&

Essentially, this code loops until the target dialog is destroyed, in which case the SIZE statement fails and returns a zero value for the width & height. I economize by using just one variable for the return result instead of two.

Take a look at ADDRESS.BAS for another example of modeless dialog control.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Colin Mair]

Thanks Lance. I do have a close button on my dialog. My code
does work - I guess my real question was as the manual states
that DOEVENTS shouldn't be called if there are no dialogs how
do you ensure that you don't call it if the dialog has been
closed. I notice in your Pseudocode in your reply that you
have the DOEVENTS before you use GET SIZE to see if the dialog
still exists - does that mean that it is ok to do a DOEVENTS
even if the the only dialog has been closed ? Or should a
GET SIZE be done first and DOEVENTS only done if x& ISTRUE ?

DO
DIALOG DOEVENTS
DIALOG GET SIZE hDlg& TO x&, x&
LOOP WHILE ISTRUE x&




------------------
Colin Mair

[Lance Edmonds]

That is almost a 'chicken and egg' question!

When the DIALOG SHOW MODELESS statement fires, the dialog is created and a bunch of messages appear in the application message queue and these need to be dispatched and processed. Therefore the 1st instance of DIALOG DOEVENTS is "guaranteed" to actually do something.

Now, if we look at the 'flow' of the code, it looks like this:

1. DIALOG SHOW MODELESS
2. DIALOG DOEVENTS
3. DIALOG GET SIZE
4. test if dialog size, exit if zero, or...
5. DIALOG DOEVENTS
6. DIALOG GET SIZE
7. test if dialog size, exit if zero, or...
8. DIALOG DOEVENTS
9. DIALOG GET SIZE
10. test if dialog size, exit if zero, or...
11. DIALOG DOEVENTS
...ad infinitum...

After than initial loop is executed, you could argue that after the DIALOG GET SIZE statement is executed, a DIALOG DOEVENTS is called (unless the dialog is destroyed)... in other words, it is a matter of perspective. The doc's are really stating that unless you are using a modeless dialog, you don't need to use DIALOG DOEVENTS. The implication is that a MODAL dialog does not need such a message pump so DIALOG DOEVENTS should not be used.

When the dialog is to closed/dismissed, the message queue receives another batch of messages, such as %WM_DESTROY, etc. The DIALOG DOEVENTS statement also needs to dispatch these messages, so the DIALOG DOEVENTS statement is actually working right up to the very last message in the queue.

When DIALOG DOEVENTS returns from dispatching these final messages, the dialog size is retested (again) - at the point the dialog has been completely destroyed and it's handle becomes invalid, the loop will drop out because DIALOG GET SIZE willl return zero.

In summary, my suggested DOEVENTS loop is constructed so that DIALOG DOEVENTS is "never" executed unless the target modeless DIALOG exists.

Just to be clear, calling DIALOG DOEVENTS in any arbitary position in a DDT app is usually permissable, providing it's operation does not conflict with a loop that performs other tests before it drops out. Therefore the rule is that only a single message pump (loop) is required [per thread]. There is no need to double-up on message pumps.

Clear as mud?


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Colin Mair]

Thanks again Lance for the clear mud. I have a better
understanding of what DOEVENTS is doing now. I will change my
loop to look at the size as a means of detecting that the dialog
hasn't been closed.

Don't you Americans sleep ? It's nearly 9 am here in Scotland
and your're still working !



------------------
Colin Mair

[Lance Edmonds]

I'm not American... I'm a Kiwi!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>