...presumably Ask is a different object to the single Message/MessageModal object. So, if Message & MessageModal were different I'd acheive the aim.
(ok, the Message wouldn't be reused until the next Message, ie max of 2 boxes at a time, but it wouldn't use up memory with thousands).
Any chance?? Or for now, I guess I'd have to use a Dialog equivalent.
Message prevents later ModalMessage waiting for ok click
Moderators: Dorian (MJT support), JRL
I've realised that what I'm really after is a "text console" for the running script - ie a window that can be positioned & resized etc, and which contains lines of text put there by one-liner script statements, maybe with the possibility of requesting text input (but actually, the small Ask box would be ok, with the long text being in the console).
I suppose the console window belonging to a particular script instance would have to be able to be ignored by that script's window-finding or focussing statements (a system variable to say so?). Otherwise the same mixups that can occur with Stepping or Tracing through Message & SetFocus statements in Editor Debug might happen? (that's why I'm running with Messages instead of using Debugging in the first place)
Have I gone too far now... or is there a Dialog out there that does some of this?
Thanks
I suppose the console window belonging to a particular script instance would have to be able to be ignored by that script's window-finding or focussing statements (a system variable to say so?). Otherwise the same mixups that can occur with Stepping or Tracing through Message & SetFocus statements in Editor Debug might happen? (that's why I'm running with Messages instead of using Debugging in the first place)
Have I gone too far now... or is there a Dialog out there that does some of this?
Thanks
Wouldn't it be easier just to output to a log file? Use the TimeStamp command. Also enable logging. Have TimeStamp log to the same file that you set up in logging. This is by far the best debug aid in my opinion.
But a simple dialog with a memo that you output diagnostics to would also work - just that you'd need more lines of code to handle that. TimeStamp is neatest approach.
But a simple dialog with a memo that you output diagnostics to would also work - just that you'd need more lines of code to handle that. TimeStamp is neatest approach.
MJT Net Support
[email protected]
[email protected]
Use TimeStamp to output anything you want - including variable values.
MJT Net Support
[email protected]
[email protected]
Hi,
Yeah, that's fine & understood, I was just suggesting there could be a lazier/easier (therefore more productive??) way of logging extra info for each executed command line, so we can see its line number and more importantly, what the statement is BEFORE AND after variables are substituted in it (if it contained any)
That way, you'd get 2 lines for commands that contained paired % signs - first with the %variablename% as it appears in the script, then again with the current value substituted (which is the only one of the 2 the current logging does). (Both these log lines would say the same line number.) May not be much of an issue normally, but if you're using variables set 100's of lines earlier you might want reminding in the log which ones you used, without having to modify the script.
Yeah, that's fine & understood, I was just suggesting there could be a lazier/easier (therefore more productive??) way of logging extra info for each executed command line, so we can see its line number and more importantly, what the statement is BEFORE AND after variables are substituted in it (if it contained any)
That way, you'd get 2 lines for commands that contained paired % signs - first with the %variablename% as it appears in the script, then again with the current value substituted (which is the only one of the 2 the current logging does). (Both these log lines would say the same line number.) May not be much of an issue normally, but if you're using variables set 100's of lines earlier you might want reminding in the log which ones you used, without having to modify the script.
We'll consider adding more logging options then. As well as looking at seeing if we can change what happens when a modal message is called and a non-modal is already active. More for the list
MJT Net Support
[email protected]
[email protected]