Fixed ParameterChar in TCMD.INI no longer working

[rconn]

Depends on your code page. But nothing in the 128-255 range is going to be a valid Unicode character.

 

[rconn]

Depends on your code page. But nothing in the 128-255 range is going to be a valid Unicode character.

And be aware that your console code page may not match your GUI code page.

 

[myarmor]

1) Why are you using ParameterChar? It has been obsolete for at least 12 years; it was added many years ago to ease transition between 4DOS and 4NT batch files, and changing it now only makes your batch files incompatible with everybody else (and vice versa).

2) Why did you choose that particular character? It's one of a handful in that character set that don't translate between code pages. (Each code page and font combination have between 0 and 10 characters that are mangled by Windows during translation to & from Unicode; your 0xF8 is one of them.)

The questions wasn't to me, but here goes.
1. ParameterChar value seems to be controlled by Advanced/Parameter in the option dialog, so maybe you should ask "why does that dialog use that value".

2. This one is probably quite easy to explain. On the nordic keyboards (at least on mine) you'll have to hold shift and press the key having ^, then press space, before it actually shows (the space char isn't typed/printed). ø is a single keypress without modifiers, and it is one of those characters you (almost) never encounter in executable filenames, commands etc.
In other words, it won't clash with anything.

The lower keyboard in the linked post seems to be the pan-nordic layout.

 

[vefatica]

Depends on your code page. But nothing in the 128-255 range is going to be a valid Unicode character.

That nasty character, ø, Latin Small Letter O with Stroke, is character 248 (0xF8) in codepage 1252. It's also the Unicode character 0x00F8. ECHO %@CHAR[248] produces it in every one of the 108 codepages on my system. Why is it not a valid Unicode character?

And that character exists in Andale, Arial, Cambria, Consolas, Lucida, MSSansSerif, Tahoma, TimesNewRoman, and scores of other TT fonts. Why can't the OPTION dialog deal with it (and many others, even with a Unicode INI file)? Note that TCMD can deal with it in the label of a toolbar button, even with a non-Unicode INI file.

 

[vefatica]

And, the OPTION dialog can deal perfectly with 'ø' when it's in the name of the command history file. That character is not corrupted, neither visually in the OPTION dialog, nor in the non-Unicode INI file.

 

[Detlef]

I ran your batch file through the debugger in both v16 and v17, and there is a difference (and a bug) between the two versions. However, the bug is in v16 (actually in the RTL), not in v17 (which is using an updated RTL).

I made a change to build 59 (already uploaded) which should resolve your issue, though it does break compatibility with CMD.

I do have two questions:

1) Why are you using ParameterChar? It has been obsolete for at least 12 years; it was added many years ago to ease transition between 4DOS and 4NT batch files, and changing it now only makes your batch files incompatible with everybody else (and vice versa).

2) Why did you choose that particular character? It's one of a handful in that character set that don't translate between code pages. (Each code page and font combination have between 0 and 10 characters that are mangled by Windows during translation to & from Unicode; your 0xF8 is one of them.)

Hello rconn,
sorry i did not yet respond, end-year business is sometime hard. :-)
#1. I am using many BTM files that were built years ago and just took everything over as is. If you have BTM files that pass parameters from one to the other then it is easier to use this method instead of writing %1 thru %9
#2. Probably the only one someone found working above #128 :-) All the other below #128 are either unusable control chars or used as other control chars or in use by normal chars.

I will get the latest release this week an test. However, with that what I learned here (obsolete parameter) I will go ahead and change my BTM routines to avoid using that ParameterChar behaviour. I will do that with normal maintenance routines and here and there when I get time. So when you work on a version 18 you shall get back to a state where you do not break compatability with CMD.
Thank you very much for the support.

Regards,
Detlef