ADVISORY

[PepsiHog]

Macro Scheduler v12.1.6

Hello Everyone,

I just had about a 3 hour spat with MS 12. Let me say first that there may be more to this than I am currently aware of. And for the record.....
I LOVE MACRO SCHEDULER 12!!!

As far as I know the Dialog Property "ModalResult" is for backward compatability. I don't even bother with this property because I use Adddialoghandler. ModalResult is usually set to zero. It tells you what will happen if you change this property in the help.

There is also a property "Kind". I only know of this to be a property for buttons. And I don't believe this to be a backward compatability command. Yes, in a sense it could be, but not so much.

Well the property "Kind" allows you to create a type of button that is displayed with graphics. It gives a dialog a professional look and feel.
I use this mostly for the cancel button more than any other.

Ok. So I used it for my OK button. I was showing MS to someone. My dialog kept on exiting. I couldn't figure it out. I thought I must have forgot how to program in MS. My dialog was modal. So unless I specify for it to exit, it should remain in control and not close. But it was closing.

Alright here is why. The property "Kind" when you select type of button to be "OK" it changes the "ModalResult" to 1. Hence, because I am not using the old method of programming, my dialog exits.

Edit: The Following is not true. Read other posts for more.
I just discovered that the "Cancel" button does NOT change the "ModalResult" to 2. In fact, it doesn't change it at all. It stays set to zero. Which leads me to believe it is in-error that the "OK" type button changes the "ModalResult" to 1.

But if you have used this property or start using it, I thought this might be usefull information for all. As I am now bald.

[Marcus Tettmar]

ModalResult is most certainly not for backward compatibility. It is what it is.

Kind changes to 1 for an OK button and 2 for a Cancel button which is what I would expect:

http://docwiki.embarcadero.com/VCL/en/B ... itBtn.Kind

[PepsiHog]

Ok. It does set the ModalResult to 2, I was incorrect. But it appears as though it doesn't change until after you close the Dialog Designer. Then when you re-open to edit, it is set to 2.

Kind changes to 1 for an OK button and 2 for a Cancel button which is what I would expect:

Yes. So would I while using the old programming method. I guess maybe it's a choice or a preference. Do I use ModalResult or AddDialogHandler?

What advantages does this offer beyond what is already possible with the newer commands in v12.1.6? Why use both methods? Can't both methods be used to accomplish any given task?

I can't think of any reason to use ModalResult instead of AddDialogHandler. That's why I thought it was for backward compatability.

Please explain, and maybe post an example of when it would be useful to use the old method instead of AddDialogHandler.

[Marcus Tettmar]

Use whichever makes the most sense for you. As for advantages, well, I would offer that using ModalResult cuts out a lot of code. E.g.:

Code: Select all

Show>Dialog1,r
If>r=1
  //user said OK, so let's continue
Else
  //user cancelled ... perhaps do nothing
Endif

I.e. If you have a simple modal dialog and just want to know if the user hit ok or cancel, then why bother with dialog handlers when all you need to do is look at the modal result?

But of course it all depends on what you need to do. If you need that OK button to do some additional processing BEFORE the dialog is closed, then you would need an event handler. Even so, there's still no reason why you shouldn't check the modal result anyway ....

[PepsiHog]

Ok. I never thought about the fact that AddDialogHandler would have coding behind it. I knew that, but never considered it. So one very good reason might be to cut the exe file size down. And as you said, if it's a simple dialog why bother with AddDialogHandler.

Even so, there's still no reason why you shouldn't check the modal result anyway ....

Sorry. This is a little confusing......

Will you indicate what you meant by this? Please. Is that if not using dialog handlers? Or is it a good idea to use ModalResult in concert with dialog handlers? Can't really see why one would do that though.

[Marcus Tettmar]

Ok. Look, it's as much down to personal taste as anything else. BUT modal result is returned by the dialog when it closes. So for a modal dialog where you want to know what button was pressed after the dialog is closed, looking at the modal result is a nice quick and simple way of doing it. AddDialogHandler is for when you need to react to some action on the dialog WHILE it is still open. One is not a substitute for the other. But if you really wanted to you could write your own button OnClick handlers and close the dialog, imitating what ModalResult already tells you. Usually though I would use both. ModalResult to know if the user OK'd or Canceled the dialog and AddDialogHandler where I want to react to activity on the dialog while it is being used. But there are no rules. Use one, or other, or both.