Hi,
This seems to be reproducable, on win98se (not tried elsewhere).
Script, being run from main window (not in editor) is:
Let>STAY_ON_TOP=1
MessageModal>1 - modal - ok waits
Wait>1
Message>2 - message - ok no wait
Wait>1
MessageModal>3 - modal - but doesn't wait for me to click
wait>1
MessageModal>4 - modal - same - doesn't wait when it should
Wait>1
Goto>fin
...
Label>fin
...the modal messages 3 & 4 wait properly if the non-modal message 2 is commented out.
Version is 7.3.10e, and still seems to happen on 7.3.10.1 (including after the reboot which completed the install). I tried Wednesday's version after seeing it mentioned in the previous entry in this forum, and wondering since the fix was for other modal probs whether this issue was known...
Regards
Message prevents later ModalMessage waiting for ok click
Moderators: Dorian (MJT support), JRL
Did you (does anyone else?) get the problem before removing any blanks (do others see the blanks?) - it could be the modal problem was introduced at level 7.3.08e (I haven't got an older version).
Couldn't I legally have blanks at the end of at least the texts for the message & messagemodal lines anyway?
A strange thing to do with apparent blanks in the forum copy: I cut'n pasted from the web page back to a different pc, and there were no blanks at end of lines, ran it, got the problem, then looked at the script file in a hex editor - each line ends normally in x'0D' x'0A' ie crlf. (I didn't think I would have left spaces in the real script, can't check now am at a different place, but maybe the blanks came in as part of the cutnpaste into the posting).
So for me, the problem remains - 3 messagemodal with NO intervening message verb do their waiting properly, but WITH an intervening message the later ones don't wait - have reproduced here on NT4 too now.
Can anyone else get this error? I tried copying the script here again but preview shows blanks, wheres the same copy pasted into notepad shows no blanks, so there really aren't any...
Let>STAY_ON_TOP=1
MessageModal>1 - modal - ok waits
Wait>1
Message>2 - message - ok no wait
Wait>1
MessageModal>3 - modal - but doesn't wait for me to click
Wait>1
MessageModal>4 - modal - same - doesn't wait when it should
Regards
Couldn't I legally have blanks at the end of at least the texts for the message & messagemodal lines anyway?
A strange thing to do with apparent blanks in the forum copy: I cut'n pasted from the web page back to a different pc, and there were no blanks at end of lines, ran it, got the problem, then looked at the script file in a hex editor - each line ends normally in x'0D' x'0A' ie crlf. (I didn't think I would have left spaces in the real script, can't check now am at a different place, but maybe the blanks came in as part of the cutnpaste into the posting).
So for me, the problem remains - 3 messagemodal with NO intervening message verb do their waiting properly, but WITH an intervening message the later ones don't wait - have reproduced here on NT4 too now.
Can anyone else get this error? I tried copying the script here again but preview shows blanks, wheres the same copy pasted into notepad shows no blanks, so there really aren't any...
Let>STAY_ON_TOP=1
MessageModal>1 - modal - ok waits
Wait>1
Message>2 - message - ok no wait
Wait>1
MessageModal>3 - modal - but doesn't wait for me to click
Wait>1
MessageModal>4 - modal - same - doesn't wait when it should
Regards
Sorry Armsys, when I copy and paste the script in the Macro scheduler Editor, I do not see any trailing character. The Show All Chars in the Edit Menu is always on and I see nothing. Even after reducing all the messages to a simple number 1,2,3,and 4, the script is still running like Baldrik’s example. Also after completely retyping of the script, it's still running like the first example.
What's the meaning of the Let>STAY_ON_TOP=1 statement? Do you mean Let>MSG_STAYONTOP=1?
I'm running XP professional (SP1) with ms version 7.10.1
Luciano
What's the meaning of the Let>STAY_ON_TOP=1 statement? Do you mean Let>MSG_STAYONTOP=1?
I'm running XP professional (SP1) with ms version 7.10.1
Luciano
Let>STAY_ON_TOP=1
MessageModal>1 - modal - ok waits
Wait>1
Message>2 - message - ok no wait
Wait>1
MessageModal>3 - modal - but doesn't wait for me to click
Wait>1
MessageModal>4 - modal - same - doesn't wait when it should
The above script I edited with Multi-Edit 9.10.04. I ran it several times again but found nothing unusual. All MessageModal> did stop to wait for clicking OK. You may want to copy the above script to give it a shoot.
I recalled when editing your original script I found some control character between Wait>1 and MessageModal>3..... Therefore, once you delete the problematic Wait>1, you're home free. Good luck!
BTW, it's perfectly OK to have trailing space(s) at the end of the Message> or MessageModal>.
MessageModal>1 - modal - ok waits
Wait>1
Message>2 - message - ok no wait
Wait>1
MessageModal>3 - modal - but doesn't wait for me to click
Wait>1
MessageModal>4 - modal - same - doesn't wait when it should
The above script I edited with Multi-Edit 9.10.04. I ran it several times again but found nothing unusual. All MessageModal> did stop to wait for clicking OK. You may want to copy the above script to give it a shoot.
I recalled when editing your original script I found some control character between Wait>1 and MessageModal>3..... Therefore, once you delete the problematic Wait>1, you're home free. Good luck!
BTW, it's perfectly OK to have trailing space(s) at the end of the Message> or MessageModal>.
Hi Luciano,
That's weird. In fact, when testing Baldrik's script, after completing the test run, Macro scheduler pops up a message warning about trailing spaces. After turning on Edit>Show All Chars, all trailing spaces and a invisible char showed up.
You're correct about the misspelling of the system variable, ie, Msg_STAYONTOP. In this case, Macro Scheduler simply treats Let>STAY_ON_TOP=1 as a user-defined variable.
That's weird. In fact, when testing Baldrik's script, after completing the test run, Macro scheduler pops up a message warning about trailing spaces. After turning on Edit>Show All Chars, all trailing spaces and a invisible char showed up.
You're correct about the misspelling of the system variable, ie, Msg_STAYONTOP. In this case, Macro Scheduler simply treats Let>STAY_ON_TOP=1 as a user-defined variable.
Last edited by armsys on Thu Feb 17, 2005 10:34 am, edited 2 times in total.
Thanks, Luciano, I wasn't dreaming it all! Needs fixing then?
You're right about meaning Let>MSG_STAYONTOP=1, must have remembered it badly, or maybe I saw other name somewhere else it should be.
I see now there is a way to avoid getting blanks on the end of each script line in a forum entry when cut'npasting, by using the 'Code' tag (or direct typing etc) to make a preformatted block, like this
no blank at end of this line
Regards
You're right about meaning Let>MSG_STAYONTOP=1, must have remembered it badly, or maybe I saw other name somewhere else it should be.
I see now there is a way to avoid getting blanks on the end of each script line in a forum entry when cut'npasting, by using the 'Code' tag (or direct typing etc) to make a preformatted block, like this
no blank at end of this line
Regards
Don't worry - this has nothing to do with trailing blanks!
The reason is just that the message box is a single object and is already present when you try to make it modal. If you close the non-modal box before the messagemodal command it will appear modal correctly. You're just running into the limitations of the way it works.
Of course, if you want you can create your own dialogs that work how you want them.
But here's an undocumented feature that hasn't been fully tested. Set MSG_MULTI to 1 at the start of your script and it will create separate message boxes - so your non-modal one will stay present when a new modal one opens when you call MessageModal:
Let>MSG_MULTI=1
Message>Hello
Wait>1
MessageModal>Hello 2
As I said MSG_MULTI hasn't been fully tested which is why it hasn't been documented, so be warned.
Enjoy.
The reason is just that the message box is a single object and is already present when you try to make it modal. If you close the non-modal box before the messagemodal command it will appear modal correctly. You're just running into the limitations of the way it works.
Of course, if you want you can create your own dialogs that work how you want them.
But here's an undocumented feature that hasn't been fully tested. Set MSG_MULTI to 1 at the start of your script and it will create separate message boxes - so your non-modal one will stay present when a new modal one opens when you call MessageModal:
Let>MSG_MULTI=1
Message>Hello
Wait>1
MessageModal>Hello 2
As I said MSG_MULTI hasn't been fully tested which is why it hasn't been documented, so be warned.
Enjoy.
MJT Net Support
[email protected]
[email protected]
Thanks support, that makes sense.
What I'm trying to do is have progress of a script reported in a box, or series of boxes, with ideally only box in existence at a time, AND be able to decide which ones are "hold ups" (ie they wait for a mouse click or enter key) and which ones aren't hold-ups (ie they go away after a small wait). I see why they go away now, it seems unfortunate that the single message box's property can be changed from modal to non-modal but not the other way - a limitation of windows, or needs specific code in MS??
The first way I tried was
- Message - for the non-hold-ups and with no intentioin of actually clicking them, and
- Ask - for the hold-ups
the advantage of Ask is that you can choose whether to stop the script, eg
Ask>...ok to continue?,ok
If>%ok%YES,fin
but the disavantage is the ask box seems rather small so can't hold much of a message text, whereas MessageModal can be in a wider box set by
Let>MSG_WIDTH=... etc, and can be positioned explicitly.
So maybe you can see why I headed for a mixture of modal & non-modal Message's.
I can see that if I use MSG_MULTI there's a risk of filling memory with thousands of non-modal message objects.... would that happen with Dialogs too? any suggestion?
Thanks & Regards
What I'm trying to do is have progress of a script reported in a box, or series of boxes, with ideally only box in existence at a time, AND be able to decide which ones are "hold ups" (ie they wait for a mouse click or enter key) and which ones aren't hold-ups (ie they go away after a small wait). I see why they go away now, it seems unfortunate that the single message box's property can be changed from modal to non-modal but not the other way - a limitation of windows, or needs specific code in MS??
The first way I tried was
- Message - for the non-hold-ups and with no intentioin of actually clicking them, and
- Ask - for the hold-ups
the advantage of Ask is that you can choose whether to stop the script, eg
Ask>...ok to continue?,ok
If>%ok%YES,fin
but the disavantage is the ask box seems rather small so can't hold much of a message text, whereas MessageModal can be in a wider box set by
Let>MSG_WIDTH=... etc, and can be positioned explicitly.
So maybe you can see why I headed for a mixture of modal & non-modal Message's.
I can see that if I use MSG_MULTI there's a risk of filling memory with thousands of non-modal message objects.... would that happen with Dialogs too? any suggestion?
Thanks & Regards
