Your scheme #2 comes closest to what I wanted, but still depends
on variables defined outside the scope of the dialog proper. Even
so, these are only module-global and not application-global so
they are well contained. The technique of using a separate module
for unusual or complicated dialogs has a lot going for it; I do
use that a lot myself, and in fact is how I chose to solve it in
the real application I was working on (the Lady or Tiger game was
just an illustration). In a sense, using a separate module is
like extending a dialog "class" by adding new private properties
and methods while still limiting what's exposed. Unfortunately,
you can't create private "methods" in mapbasic (ALL subs and
functions are public), so you have to be careful how you name
them when you're assembling a large application on the slab.
Two flavors of Dialog Remove would be my first choice, but since
I can't have that, this is the next best thing.
- Bill Thoen
Spencer Simpson wrote:
> Here's the problem. "Into" clauses work *only* with
> OKButtons.
>
> Think of it this way: when a user presses a CancelButton,
> he or she is saying: "Wait a minute, I changed my mind, I
> don't want to do this."
>
> It's much more difficult to back out of an action if the
> process of cancelling changes variables. So MapInfo
> doesn't update the variables.
>
> The same holds true for using Dialog Remove in
> ordinary Button controls: There's no way for MapInfo to
> tell if that's an OK, or a Cancel. So it does the conservative
> thing: It doesn't update the "Into" variables.
>
> (You certainly can't expect
> CommandInfo (CMD_INFO_DLG_OK)
> to be set to ant meaningful value after a Dialog Remove,
> so why should you expect it to set the Into variables?)
>
> Granted, it would be nice if there were two flavors of
> Dialog Remove: an OK-like one and a Cancel-like one.
>
> Until then, you should use one of three schemes for
> exiting from any MapBasic dialog:
>
> Scheme #1:
>
> This scheme is the *only* way you should use
> OKButtons, CancelButtons, and Dialog Preserve.
>
> -One OKButton and one CancelButton.
>
> -"Into" clauses on controls that return values.
>
> -If you need to validate control values, do it in
> the handler for the OKButton. If they don't pass
> the test, use Dialog Preserve.
>
> -In your CancelButton, you *might* want to ask
> the user if he/she really wants to cancel. If they
> answer no, issue a Dialog Preseve.
>
> Scheme #2:
>
> You would be surprised how little complexity you
> have to add to a dialog before you need to use
> this scheme over Scheme #1. Usually, when I write
> such a dialog, it goes in its own .MB file.
>
> -Ordinary buttons only.
>
> -dim variables for the values of your controls
> at the top of your .mb file. Also dim a success/failure
> variable.
>
> -One button acts as an OK button. It validates control
> values. If they're not valid, it does nothing. If they're valid,
> it sets the success/failure variable to indicate "success"
> and issues a Dialog Remove.
>
> -One button acts as a Cancel button. It sets the success/failure
> variable to indicate "failure" and issues a Dialog Remove.
>
> -After the dialog, check the success/failure variable.
>
> Scheme #3:
>
> -Ordinary buttons only.
>
> -One button acts as an Action button. It validates control
> values. If they're valid, it performs the action the
> dialog is supposed to control.
>
> -One button acts as a "Done" button. It simply issues a
> Dialog Remove.
>
> I'll invoice you when I get an address ;)
>
> HTH
> Spencer Simpson
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
