Forums Bug Reports $chr(32) bugs

mIRC doesnt work correctly with $chr(32), examples:
if you write //echo -a $chr(32) >> it returns * /echo: insufficient parameters

if you write //echo -a $chr(32) a >> it only returns "a"

if you write //echo -a a $chr(32) >> the same it only returns "a"

if you write //echo -a a $chr(32) $chr(32) a >> it only returns "a" "one of the $chr(32)" and "a"

the same happens if you want to save a variable, binvar, hash tables, .txt, .ini, with $chr(32) with that methods.

Khaled, could you fix it for the next version please?

Hi!

the $chr(32) is not a printable (alphanumeric) character.
There is no bug here.

Use $chr(160) - example:

//echo -a $chr(160) $+ a >> " a" (not "a")

Regards,

well I programme in another languajes as VB or C and it is printable why?

well I programme in another languajes as VB or C and it is printable why? and other thing write in mIRC this
//write test.txt a $+ $chr(32) $+ $chr(32) b
it will apear in test.txt a "1 space" b
but if you open a .txt and you write a you presh two times space bar and b it will apear a "2 spaces" b
why?

just use $chr(160) for creating spaces.

I don't know anything about C or VB so couldn't comment on that....

In your example, once again, you can just use $chr(160). For example: //write test.txt a $chr(160) b returns "a 2spaces b"

Just an FYI, you have 2 hours to edit your posts if you wish, just click the 'Edit' button. You can also delete posts.

Regards,

In VB and C strings are delimited by quotes, so the literal string hi in one of those languages would be typed as "hi". Since mIRC and IRC commands are designed to be run from the command line quoted strings aren't appropriate for a language like mIRC's, And since IRC and mIRC also use a space as the token delimiter for commands it makes sense that it strips multiple consecutive spaces since, from a command-line perspective at least, they're more likely to be undesirable typos than intentional spacing. The problem isn't that space ($chr(32)) isn't a printable character - it must be otherwise you wouldn't see any spaces in this text, the problem is that mIRC's script parser collapses consecutive spaces into a single space.

Binary variables can be saved correctly with the use of /bwrite.

no binary variables have the same problem example:
//bwrite &x 1 $chr(32)
* /bwrite: insufficient parameters

That's because you're using /bwrite incorrectly. /bwrite is for saving a binary variable to a file, to assign a value to a binary variable use /bset.

eg.
/bset &x 1 32 32 32 - &x now contains 3 spaces. You can then use /bwrite to save that value to a file. You can't display them or use the value as a parameter to any command that doesn't specifically accept binvars, but the point is that binary variables can contain multiple spaces and do have their uses.

While I understand why mIRCscript behaves this way, it does not make it any less annoying. Although using character 160 is a workable alternative in many cases, it isn't always appropriate and has some odd side-effects.

For example, if you display a line with every space character replaced with character 160, mIRC becomes unable to find clickable hyperlinks in the text, which is frustrating. If your script is intended to work on incoming IRC text, the moment the text is used in the script the extra spaces are truncated, which means lines such as /set %safetext $replace($1-, $chr(32), $chr(160)) have no real effect.

In short, it means it is not possible to perform any scripting on incoming text/data while still preserving whitespace. I admit to not having ever worked with binvars but I would expect them to fail as soon as you passed them to any text manipulation routines/commands.

I don't know how this could be avoided without breaking everyone's existing scripts, but I think it is worth considering.

It is also worth mentioning that this behaviour is only exhibited if the text passes through a script. If there are no scripts handling incoming or outgoing text then double spaces are displayed and sent correctly.