Preliminary apology: even though BBcode is enabled in my forum default preferences, it's turned off on the "post a new topic" screen, and there's no option to turn it on anywhere, so I can't properly format the code in this post.

I've discovered a bug in tbscript's run-time syntax analysis. Most of the time when there is a syntax problem, tbscript is good at letting you know. However, in the following situation with GetStr, at least sometimes, tbscript simply ignores an error altogether, both in terms of an error message to the coder and in terms of script execution. The script will execute everything surrounding the problematic command but not that particular command itself. However, as if there were actually something to the Tron movies--or at least as if Freudian psychoanalysis were valid for code--what is suppressed by the syntactically incorrect command slips out elsewhere, causing problems with other GetStr prompts.

Consider the following examples:

In this sample, both GetStr's behave as expected. Responding to the first prompt, the user presses Y (or N, or whatever) and then Enter; everything looks normal. The input is appended to the prompt and then the two printls separate the second prompt from the first. The second prompt then displays itself and the user presses Enter (or whatever they wish, and finally Enter) and the script simply terminates. No odd behavior:

=========================sub main()

;dummy valuesvRegbackNum=2vRegolder="regbak2"vCurrentHD=3

vCheckRegbak=GetStr("^R^NYou pressed "#vRegbackNum#", so you are about to restore the registry backup^R^Nfrom folder "#vRegFolder#". To proceed, Type Y and press Enter. If you^R^Nmistyped the number or wish to change the backup, press N to stop^R^Nthe current restoration and run it again:")printl("")printl("")

;TEMP DEBUGGING MESSAGEGETSTR("^R^NRegrestore has just run through its two nested WHILEs, and^R^Nhopefully it ignored the innermost loop since it shouldn't^R^Nfire on my system). The script is now at the bottom of the^R^Nouter shell WHILE and has just augmented increment var^R^NvCurrentHD, which is now "# vCurrentHD # ", so we're ready for^R^Nanother turn on the merry-go-round. Press Enter to continue.^R^N^R^N")

end sub=========================

However, here is a second test snippet which adds a new GetStr in the middle. This Getstr does not display at all, but tbscript fails to notify the user that there is a syntactical problem with it. Moreover, once this "invisible" GetStr is added, the first GetStr--the one beginning with "You pressed "#vRegbackNum#", so you are about to restore the registry backup"--which behaved normally without the (invisible) middle message, now adds an unwanted 0 to user input, as follows: it receives whatever the user types, then after the user presses Enter, it appends a 0 after the printl's, then the script continues execution. So the screen looks like this:

-----You pressed 1, so you are about to restore the registry backupfrom folder regbak1. To proceed, Type Y and press Enter. If youmistyped the number or wish to change the backup, press N to stopthe current restoration and run it again:y

0-----

The last GetStr still behaves normally. Here's this second snippet:

=========================sub main()

;dummy valuesvRegbackNum=2vRegolder="regbak2"vCurrentHD=3

vCheckRegbak=GetStr("^R^NYou pressed "#vRegbackNum#", so you are about to restore the registry backup^R^Nfrom folder "#vRegFolder#". To proceed, Type Y and press Enter. If you^R^Nmistyped the number or wish to change the backup, press N to stop^R^Nthe current restoration and run it again:")printl("")printl("")

; DEBUGGING MESSAGEGETSTR("^R^NRegrestore has just started a new iteration of the outermost loop,^R^Nthe shell, and ran GetHdInfo with parameter vCurrentHD. Currently,^R^NvCurrentHD is "#vCurrentHD#". Press Enter to continue."^R^N)

;TEMP DEBUGGING MESSAGEGETSTR("^R^NRegrestore has just run through its two nested WHILEs, and^R^Nhopefully it ignored the innermost loop since it shouldn't^R^Nfire on my system). The script is now at the bottom of the^R^Nouter shell WHILE and has just augmented increment var^R^NvCurrentHD, which is now "# vCurrentHD # ", so we're ready for^R^Nanother turn on the merry-go-round. Press Enter to continue.^R^N^R^N")

end sub=========================

Finally, in my real code in a file attached to this post, the third GetStr, which behaves normally in the test snippets shown here, also appends an undesired 0 to user input. Run it and see for yourself (to run successfully, create a dummy folder called "regbaks" at the root of one of your non-Windows-system partitions).

The cause of all this? Sharp-eyed forumers will have noticed that the invisible middle GetStr in the second snippet includes carriage-return/newline codes _outside_ the quotation marks rather than within them. That's the entire issue. Why this would make other GetStr's append zeroes to their user input remains a mystery buried within the tbscript engine, but investigators who run the attachment might wish to leave the error uncorrected and experiment with prompts that don't use variables. I had other prompts (now removed) that did not fall prey to the unwanted-zero problem, and none of those prompts used concatenated variables.

One last thought: I haven't tested the print commands vis-a-vis the unidentified out-of-quote problem, but if you have strange problems with them, check for this issue. It wouldn't be surprising to see them fall prey to it also.

Hope this saves someone else a few hours of wondering what the heck is going on with their error-checking messages.

It's actually correct because the ^ outside of a string is an xor
operation - so your string gets converted to 0 numeric value xor variable N
xor variable R which is zero and that gets converted back to a string for
output.

The cause of all this? Sharp-eyed forumers will have noticed that the
invisible middle GetStr in the second snippet includes
carriage-return/newline codes _outside_ the quotation marks rather than
within them. That's the entire issue. Why this would make other GetStr's
append zeroes

Ah-so...OK, I guess that explains why the middle GetStr doesn't get executed. However, it does not explain why the xor-created variable's value would be displayed after the other GetStr's which have prompts in which the intended carriage-return/newline codes are _inside_ the quotation marks. Those are clearly strings. So there's still something odd going on here.

It prints the zero (the result of the equation) and waits for input as it
should... ?

"schmibble" wrote in message news:5436@public.scripting...

Ah-so...OK, I guess that explains why the middle GetStr doesn't get
executed. However, it does not explain why the xor-created variable's value
would be displayed after the other GetStr's which have prompts in which the
intended carriage-return/newline codes are _inside_ the quotation marks.
Those are clearly strings. So there's still something odd going on here.