I have $chr(8) character (the caracter itself, ascii 8) in code that act as a seperator for some stuff. It used to works fine with mIRC 6.35 but now there is like a CRLF after the character and the text editor act weird.

I noticed that as well.

Confirmed on both 7.0 and 7.1 (windows 7, 64b)

I'm sure this is caused by unicode attempting to display that character (a backspace). Why it goes to multiple lines, I'm not sure, but the "correct" display might erase the previous character when displaying. I don't really know how a backspace should be displayed in unicode.

I really don't think it's a good idea to use certain "key" characters (BS,CR,TAB,etc) as separators in scripts anyhow. You have thousands of choices that you can use that won't lead to potential problems. If you are concerned that a certain character might appear in text and that's why you're using this instead of something else, there are ways to avoid those situations.

That said, maybe Khaled will just make it so that character isn't displayed at all. I don't think that's "correct" behavior with unicode, but maybe it's best for mIRC. We'll have to wait and see how he handles it.

As Riamus mentioned, it's not a good idea to use non-printable characters (0-31) directly in any editor for the simple reason that they're "non-printable", which in practical terms means that their visual representation is undefined. Even using control codes like bold/underline/color/italic are problematic in the editor (*).

That said, mIRC should probably not display $chr(8) as a newline. However, if this gets fixed you should not necessarily expect it to display a box-- it might, as Riamus said, display nothing at all. In fact, that would be the correct behaviour for a "non-printable" character. It would be a good idea to change your separator to something that will be guaranteed to be visible in all environments, or at least use the escaped version ($chr(8)).

* Codes like bold/underline/etc. are generally exempt from this rule, since mIRC explicitly handles them. However there are issues in Vista/7 with mIRC not displaying control codes properly both in the editbox and in the editor. This is in fact a perfect example of why using non-printable characters is a really bad solution in the long run. mIRC might improve the displaying of those specific control codes in the future, but it would likely be only for those control codes, not all non-printable characters.

mIRC v7.x is using the latest version of the Windows richedit control for improved Unicode support. As far as I can tell, the richedit control considers backspace a special character. mIRC has no control over the way text is displayed in any of the editboxes, whether in the Script Editor, in windows, or in dialogs, so you would need to use a different character. The only other option is for mIRC to revert back to the old richedit control, however that might not be practical since the latest richedit control adds support for a number of features in addition to better Unicode support.

Why the heck would you even use that character.. i mean if you pasted your script to someone he might not be able to use it correctly as his MSN or Skype wont display it correctly

I always use the famous $chr() for special characters within my script or even colors i dont even use CTRL+K inside the script editor because that is very poor coding...

So Overall use $chr and problem solved not only this problem but multiple other problems