mIRC Homepage

Bug or Fix??

Posted By: Dr_Brom_sung_

Bug or Fix?? - 29/07/06 01:02 PM

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.....
Posted By: maroon

Re: Bug or Fix?? - 29/07/06 05:11 PM

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
Posted By: Dr_Brom_sung_

Re: Bug or Fix?? - 29/07/06 05:27 PM

So if it a fix ot a bug? LOL grin

looks like a fix, but it is not mentioned anywhere...
Posted By: maroon

Re: Bug or Fix?? - 29/07/06 11:36 PM

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

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

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.
Posted By: Khaled

Re: Bug or Fix?? - 31/07/06 04:18 PM

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.
Posted By: Khaled

Re: Bug or Fix?? - 31/07/06 04:19 PM

Thanks the issue with long tabbed lines not being displayed has been fixed for the next version.
© 2021 mIRC Discussion Forums