Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

How to? Use of @repeat or Embedded 'Extended' Characters

Mar
4
0
Hi..

I have found something strange with using @repeat.

In short, when a string is assigned to an environment variable in a batch file, you can issue a command like:

echo %ENVAVR

...and see the string you assigned.

However, the display varies depending on whether you use @repeat or embedded 'extended' characters (for example, character 176 - a 'graphics' character).

The attached example .btm file illustrates the problem.

Is the use of the embedded string the only way to get the 'graphical bar' -type output I'm looking to create?

Version Info: TCC LE 14.00.9 x64 Windows 10 [Version 6.3.17134]

...and in Australia, using Code Page 850.

Thanks a heap.
 
Please include your example as code block in your message.

The code cannot be included as code block - this forum software cannot process it. I expect it's because it includes embedded 'extended' characters, which are critical to describing/illustrating the problem.

I'll try to simplify the code and will repost, if possible.
 
An alternative - an image of the execution of the batch file:-

gdisp-output.png
 
Note that @CHAR produces Unicode characters. 176 = 0xB0, and Unicode U+00B0 is the degree symbol. If you want to use @CHAR, have a look at the Unicode Block Elements and Box Drawing characters.

I think %@CHAR[0x2591] or %@CHAR[0x2592] might be what you want.
 
In code page 850, the character with code 0xB0 (176) is "░"; in Unicode the character with that code is "°", which is what you are seeing. In Unicode the code for "░" is 0x2591 (9617).

Use %@char[0x2591] or %@char[9617].
 
This thread makes me curious. I am not talking about TCC/LE. Can someone tell me what this (below) means?

Alternative Keyboard Input Method:
The method mentioned above for Alt-255 can be used to generate other characters. You must use the number keys on the numeric keypad, not the row of keys at the top of your keyboard. When this Alt + keypad approach is used in a Unicode environment, TCC will assume that a 3-digit decimal value means an ASCII character, while a 4-digit decimal value mean a Unicode glyph.

I can't figure out how to get any high-bit character from the current code page by entering its 0-255 code. In CMD, with CP 437, Alt-1-7-6 followed by Alt-0-1-7-6 gives me this.

1584732216339.png


In TCC, the same gives this.

1584732317026.png
 
In TCC, or in Take Command? I think the behavior of the Alt-keypad input differs between console and Windows programs.
 
... Or not. Alt-keypad entry works the same here in TCC, CMD, Notepad, and MS Word.

One oddity of Take Command that might be relevant here is the way it hooks one or the other (or both, or none) of the Alt keys. That might affect Alt-keypad entry.

(That phrasing is strange; Unicode character values can be more than four decimal digits. I thought the difference was whether the sequence began with a zero, not the number of digits.)
 
... Or not. Alt-keypad entry works the same here in TCC, CMD, Notepad, and MS Word.

Are you sure? Here, it's definitely different in TCC (as described earlier). ... any guesses why?

(That phrasing is strange; Unicode character values can be more than four decimal digits. I thought the difference was whether the sequence began with a zero, not the number of digits.)

Yes, that's the way I always understood it to work. As far as I can tell, in CMD, Alt-n (n not starting with 0) gives the code page character with index (n mod 256); if n starts with a 0, you get the Unicode character with index (n mod 65536) ... no surprise if one stuffs the number into a BYTE and the other into a WORD. It's rather cool, in CMD, Alt-6-4 and Alt-3-2-0 both give '@' and Alt-0-6-4 and Alt-0-6-5-6-0-0 also give '@'.
 
Are you sure? Here, it's definitely different in TCC (as described earlier). ... any guesses why?
No, not really. Is it the same for left-Alt vs. right-Alt?

Yes, that's the way I always understood it to work. As far as I can tell, in CMD, Alt-n (n not starting with 0) gives the code page character with index (n mod 256); if n starts with a 0, you get the Unicode character with index (n mod 65536) ... no surprise if one stuffs the number into a BYTE and the other into a WORD. It's rather cool, in CMD, Alt-6-4 and Alt-3-2-0 both give '@' and Alt-0-6-4 and Alt-0-6-5-6-0-0 also give '@'.
Now a Unicode character can be >= 65536. But I guess that wasn't true at the time they were creating Windows....
 
When Windows added Unicode support, it looked like they would only need two bytes for all characters. That's how they ended up with UTF-16 today. One of those things that seemed like a good idea at the time.
 
In code page 850, the character with code 0xB0 (176) is "░"; in Unicode the character with that code is "°", which is what you are seeing. In Unicode the code for "░" is 0x2591 (9617).

Use %@char[0x2591] or %@char[9617].

That's done it, thank you.. An example of the line of code I'm now using:-

Code:
set USG_BAR=%@repeat[%@char[0x2593],%USG_LEN]
 
Back
Top