Run the following script:
Dialog>Dialog1
Caption=Dialog1
Width=445
Height=250
Top=24
Left=410
Edit=msEdit1,72,24,281,Message xyz
Button=Yes,48,128,75,25,5
Button=No,288,128,75,25,6
Default=Yes
EndDialog>Dialog1
Show>dialog1,r
Wait>1
Show>dialog1,r
message>%r%
If one choose “Noâ€Â
Default button declaration in a dialog.
Moderators: Dorian (MJT support), JRL
-
Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
Works fine for me - the Yes button remains the default all the way through.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
Macro Scheduler 7.4.009, Win XP Pro
I get the same results as Luciano. I tried several ways of rewriting the script and continue to get the same result. If "No" was selected the first time dialog1 is called, "No" is the default the second time it's called.
- Tried setting dialog1 to null after first call.
- Tried resetting the two dialog1.button to null.
- Tried using a different variable for dialog result in each call.
- Made sure that the case was the same for all instances of the word dialog1.
- Tried using a variable for "Yes" to eliminate the chance that Button=Yes and Default=Yes were not the same.
- Tried rearrangring the lines of the dialog.
Hope this is helpful,
Dick
I get the same results as Luciano. I tried several ways of rewriting the script and continue to get the same result. If "No" was selected the first time dialog1 is called, "No" is the default the second time it's called.
- Tried setting dialog1 to null after first call.
- Tried resetting the two dialog1.button to null.
- Tried using a different variable for dialog result in each call.
- Made sure that the case was the same for all instances of the word dialog1.
- Tried using a variable for "Yes" to eliminate the chance that Button=Yes and Default=Yes were not the same.
- Tried rearrangring the lines of the dialog.
Hope this is helpful,
Dick
-
Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
Still can't see what you mean. Yes remains the DEFAULT button throughout. *However*. If you select No the first time you will have had to click it with the mouse or move keyboard focus to it. You will therefore have focused that button. So the subsequent time the dialog is shown this button will have the focus. If you therefore just hit Enter without moving focus elsewhere No will be pressed. But this is not the same as it being the default. Move the mouse to the edit field and hit the Enter key and Yes will be pressed. Correct, because Yes is the default button. The default button is the one which will be pressed when you hit Enter in an edit field. So as far as I can see everything is happening as should be expected and as is the norm for Windows dialogs.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
Marcus,
Thank you for the clarification, I think this helps me understand other aspects of dialog behavior as well. Apparently, when a dialog is called it becomes a relatively fixed entity within the context of the script. Even if the dialog is "closed" it has already been defined and some aspects of it will not be redefined upon its reopening.
Luciano,
From Marcus' reply, it's clear the dialog is working as advertised. In answer then to your original question:
[quote]Is it possible to always set the “Yesâ€Â
Thank you for the clarification, I think this helps me understand other aspects of dialog behavior as well. Apparently, when a dialog is called it becomes a relatively fixed entity within the context of the script. Even if the dialog is "closed" it has already been defined and some aspects of it will not be redefined upon its reopening.
Luciano,
From Marcus' reply, it's clear the dialog is working as advertised. In answer then to your original question:
[quote]Is it possible to always set the “Yesâ€Â
-
Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
I think what most people don't realise is that when you Close a window/dialog it is really just hidden. It's properties remain as they were when it was closed. It still actually exists until it is "destroyed". None of the dialogs created by the script are destroyed until the script exits.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
Marcus,
You are correct for me anyway. Until today I was not fully aware that was the case. Now I'd like to know how much control you as the programmer have over what entities can be "redefined" in a re-call of a dialog? For example: Do you control whether or not labels can be altered in subsequent dialog calls?
Also is there a way for you to provide a comprehensive listing of what can be changed in dialog re-calls and how to do it? For example:
- Buttons can be named by a variable and if that variable value changes a recall of the dialog will rename the button.
- Text in a memo box can be changed in a dialog recall by changing the value of [dialog name].[memobox name]
- Whether a checkbox is True or False can be controlled each time a dialog is recalled by setting the value of [dialog name].[checkbox name]
- On the other hand, a label can be set by a variable but once set, changing that variable's value will not change the look of the label in subsequent calls of the dialog.
My examples are weak, but I only have my experience to relate and I don't want to mislead anyone with half-truths.
Luciano,
Sorry. Didn't intend to hijack your thread.
Thanks for listening,
Dick
You are correct for me anyway. Until today I was not fully aware that was the case. Now I'd like to know how much control you as the programmer have over what entities can be "redefined" in a re-call of a dialog? For example: Do you control whether or not labels can be altered in subsequent dialog calls?
Also is there a way for you to provide a comprehensive listing of what can be changed in dialog re-calls and how to do it? For example:
- Buttons can be named by a variable and if that variable value changes a recall of the dialog will rename the button.
- Text in a memo box can be changed in a dialog recall by changing the value of [dialog name].[memobox name]
- Whether a checkbox is True or False can be controlled each time a dialog is recalled by setting the value of [dialog name].[checkbox name]
- On the other hand, a label can be set by a variable but once set, changing that variable's value will not change the look of the label in subsequent calls of the dialog.
My examples are weak, but I only have my experience to relate and I don't want to mislead anyone with half-truths.
Luciano,
Sorry. Didn't intend to hijack your thread.
Thanks for listening,
Dick
Thanks again Dick. Your work around works fine. I give it a try in the complete dialog, a little bit more complicated, but I’m sure it will works perfectly.
Also thanks to Marcus for his clarification. It’s so simple …..if you have enough background information.
Greetings.
Luciano
Also thanks to Marcus for his clarification. It’s so simple …..if you have enough background information.
Greetings.
Luciano
