Forums Bug Reports Bug or Fix??

The new mIRC 6.2 has something which might rather be a fix to an old bug (if it was a bug at all), or a bug by itself.


In old versions of mIRC, if you would have created a window with tabs (window -t10,20,30,40), and then add a line:

//aline @window 2First $chr(9)  Second $chr(9) Third $chr(9) Forth

Then the 2 would only affect the tab that it was set on.
In fact, all wrapping would affect only the columns they were set on.

With mIRC 6.2 it 2 affects all that comes after it (it is not being stoped by the $chr(9) )

This would cause incompatibilities with older scripts which counted on $chr(9) breaking the wrapping.
For example You coded something that you have expected that color would return to Black after the $chr(9)

Another example is if you wanted a line to be bold then you would do:
/aline @window $chr(2) First $chr(9) $chr(2) Second $chr(9) $chr(2) Third $chr(9) $chr(2) Forth

But now this is not the case, and this would cause the columns to have Bold No Bold Bold No Bold



All I saw in the whatsnew.txt is:

123.Added aline/iline/sline/etc. -t switch, forces a re-wrap of all
lines in a window that have not yet been wrapped to the current
window size.


This might be related (It talks about wrapping the whole lines), or maybe it is the cause of the bug.....

Confirmed the behaviour. In addition, when you do:

/aline 4 @window column1 $chr(9) column2 $chr(9) column3 etc

... while in prior mIRC's, any column not containing colour codes reverted to the red-4 colour.

Column 2 did inherit the red-4 colour by adding a ctrl-K to the end of column 1, but that requires fixing some fline search-strings, etc.

The new /aline -t switch isn't mentioned in the /help file

So if it a fix ot a bug? LOL

looks like a fix, but it is not mentioned anywhere...

(undocumented feature) Isn't that what a bug is?

Because it breaks something that's been used for so long, I'm hoping it will be taken away, like the change in mouse-highlighting in 6.17.

Something possibly related to this bug, this example shows the problem. Having a sorted listbox window that uses a hidden value to sort the displayed string:

//window -c @test | window -ls -t1 @test | /aline @test $replace($str(_,50) $+ <tab>displayed string,<tab>,$chr(09))

This shows the 1st "_" of the column-1 index field, then "displayed string" correctly, both in mIRC 6.16 and 6.2. However, when the 50 is changed to a large value around 106 or higher, the "displayed string" disappears in mIRC 6.20, even though there are no colour codes at all. The 106 seems to decrease slightly when there are more -t tabstops used.

In 6.16, the display-string continues to be seen when the 50 is increased up to around 1000, where you get a $str too long error.

The new /aline -t switch has no effect. If there is a reason for the new behaviour, perhaps there could be a switch to use the new setting and let the default remain the old way.

This was due to a bug in the display routine in previous versions of mIRC which was incorrectly parsing control codes when tabs were parsed. I'd really rather keep it the way it is in v6.2 since it's parsing control codes properly now.

Thanks the issue with long tabbed lines not being displayed has been fixed for the next version.