I have this (annoying) little bug in my mIRC 6.21 where if I echo something to a custom window and there is a tab character in the messages, part of the message will not be displayed in the window. The text is there, because it shows up when I copy the line from the custom window by highlighting it, but it seems to be in a dimension of its own, invisible to me.

First of all, for some reason the tab character doesn't show in the forum post when viewing it as you are viewing it now, but does show up in the edit box when you press the Quote button at the bottom of this post. You should see it between the words "the" and "bug".
So quote my post, so the tab character shows and paste these lines into your mIRC (or open MS Word and press tab and copy that):


I'm not sure, but it seems that the first 8 characters of the echoed line always display, along with the text after the tab character.

This behaviour seems to be limited to custom windows and does not present itself when echoed to a channel/server window.

I do not know whether this bug is also present in the latest version of mIRC, but I would like people to try and recreate it there too.

Do you think it's interesting to reproduce/report a bug on an older version of mirc ?

And indeed, I can't reproduce the bug in 6.31.

While your effort is appreciated, before posting bug reports it's best to

• test them on the latest version of mirc, otherwise
• look in the full versions.txt for a fix in one of the versions that came after your own

Ugh, I (of course) checked the version changes, but for some weird reason obviously missed it. *sigh* Nevermind.

This bug still exists in 6.31. I've seen this exact issue in my custom windows quite a few times, but thought I was missing some switch for /window that would fix this and that I hadn't discovered yet. Never considered it to be a bug...
So after reading this, I tested it with the example the OP provided right away, on a clean 6.31 install, and just as expected, part of the message didn't show up. As the OP said, the text after the tab char is always displayed; the amount of text before the tab not being displayed varies depending on the font being used.
Not sure how some people can not be able to reproduce this though, unless other factors like OS play a role here.

Tested on Win XP Pro SP2

Screws up on blank mIRC 6.31

It is echoed as



but when copied, it is



(with the tab in it)

Ah true. I couldn't reproduce it before because it doesn't happen with all fonts; I'm using Fixedsys Excelsior. Switching to plain Fixedsys, I can reproduce the bug. Oddly enough, Excelsior v3 is the only font among the ones I tried that does not exhibit this problem (Excelsior v2 does).

However, there is another serious problem after echoing that line using Excelsior (v3): when the window is resized by dragging the right edge to the left, as soon as the text wraps, mirc freezes, consuming 100% CPU.

Thanks this has been fixed for the next version.

This is the only thread I can find that seems to deal with the 6.32 item in versions.txt

50.Fixed text in custom @windows being chopped at tab stops.

Was there a new switch added to avoid this "fix" and go back to the old display behaviour? This change is breaking one of the scripts I use. It uses a tabbed @window where a tabstop at 1 is used to hide an invisible index string that is used as a line identifier, as well as affecting the "/window -ls" sort order. There are several other tabstops that line up fields of a database in columns, regardless of the length of the field strings.

Suddenly in 6.32, this fix is causing the @window display to be distorted. Instead of the index text to the left of tabstop 1 being invisible, it pushes the other field texts to the right, and whenever any of the other field strings are too long to fit within its own tabstop, the undesired behaviour of showing the entire string causes the fields to no longer be lined up in straight columns.

I didn't view as a bug when the older mIRC's chopped the display so the next tabbed string appears at its correct tabstop position.

note: I found a rough work-around, but I'm worried that a later mIRC will 'fix' the work-around, since it appears to be relying on a mistake that doesn't 'chop' the text in all situations. An example is as follows:

/window -ls -t1,10 @tabtest

In older mIRC's, this creates a tabbed window where the 1st tabbed string is chopped at tabstop 1, which basically hides the 1st field, which is what i'm wanting to do. However, when you do:

//aline 12 @tabtest _ HIDDEN INDEX $chr(15) $chr(9) VISIBLE FIELD

Instead of "VISIBLE FIELD" appearing at tabstop 1, mIRC 6.32 pushes it to the right until it's finished displaying the "_ HIDDEN INDEX" string.

However, you can get mIRC 6.32 to mimic the older behaviour by using $+ so that the $chr(15) touches the TAB:

//aline 12 @tabtest _ HIDDEN INDEX $chr(15) $+ $chr(9) VISIBLE FIELD

I'm hoping that whatever fix there would be will allow us to continue having the old display behaviour - either by adding a switch to get the old way, or by not fixing the 'bug' where attaching Control-O to the TAB causes it to 'chop' the display. It appears that any of the BURKO colour-codes touching the TAB causes it to go back to the old 'chop' display. i.e. you can instead attach Control-R to the left of the TAB.

It sounds to me like your script was "broken" to begin with. Taking advantage of the display to hide information rather than putting it in the right place (in a variable / hash table) is a hack/workaround that shouldn't be used in the first place.. so I'm not too sure why you're all of a sudden worried about using yet another workaround to make it work again.

The real solution here is to design your script so that it isn't dependent on the display behaviour-- bugged or not. Information that isn't to be displayed simply shouldn't be. Store it somewhere else.

On a sidenote, the Control code bug will likely be fixed in the next version as well since it affects all windows now. I doubt this change will be reverted or a switch would be added unless there's some reasonable design issue-- it would have to be unrelated to the fact that scripts using such a display hack stopped working.

Yes, the previous behaviour can be reproduced using the next item in versions.txt, which is:

51.Added /window -M switch, chops text at tab stops.

If that doesn't work for you please let me know and I will look into it.