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.