11.Fixed various tabbed text display bugs in @window text/listbox.

May I ask is the newer (6.2+) nature of a non listbox windows TAB stops, to now over write data extending into that tab, if a tab then follows the that data.

ex
//window @ex fixedsys 1 | echo @ex $str(A,100) | echo @ex $str(B,100) $+ $chr(9) $+ $str(C,100)

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

* first line ishows data extends past the tabstop
** second line shows tabstopped data backing up to the tabstop and overwritting the previous data


--Mirc 6.21--

Im happy with it either way, but would like to know what it is, as i havent patched any scripts to deal with this newer behavour up to now, as i thought it was a bug.

Yes this is the intended behaviour now. In previous versions the tab behaviour was behaving differently in text and listbox windows, so it was changed for consistency. Since tabs were generally being used to delimit columns this behaviour seemed best.

Thankyou, for the confirmation.

Previously as stated I wasnt sure if it was a bug that had crept in or a feature. And as such hadnt been prepeared to make use of it, as it might have vanished next release.

Given this , would it not be advisable to have a switch that swaps between the functionalities? I would think that the default would be to insert spacing, with a switch to provide 'columning' for when that's required. It would then not give unexpected behaviour when set up with no arguments.

(I hope that isn't opening old discussions. I don't remember there being any great debate about tabstops, though)