Forums Bug Reports Text on top of other text?!

I've been running this script for a while, and I just recently upgraded to v6.2, and noticed something funny:


I looked throught the scripting reference again, and didn't see any changes that needed to be made.....anyways, if someone else has seen problems with this (tabs causing text to appear over other text), please let me know so I can confirm that this isn't a script bug. Until then, I'll try and add in some more tabs as a workaround.

Thanks in advance.

Are you sure your tabs are correctly set?

How do you set them incorrectly in the first place to cause this? O.o

Can you post the /window and /echo commands that reproduce this issue?

The window line:
window -enk0xz @BlackMagic

The echo line (triggered by a CTCP to myself):
echo -t @BlackMagic 12[11 $+ $network $+ 12] $+ $chr(9) $+ 15Lag:00 $calc(($ticks - $1) / 1000) $+ $chr(9) $+ 07(08 $+ $nick $+ 04@09 $+ $server $+ 07)

Edit: for some reason the ctrl+k color codes aren't appearing on the forum after the word wrap....but it should be kinda obvious where they are.

I believe you forgot to paste the tab parameters from your /window command. Could we also have those? (eg. window -enk0xz <tabs> @BlackMagic)

I see this bug in custom windows too. But I see it differently (perhaps because I have no background set)... It seems the tabs are forcing the character after the tab to be left-shifted.

I used the same text as used above. And did not use any tab settings in the /window commands... It seems using the /window -t option can make things worse... I tried, "/window -t5,10,15,20,25 @Test", and it left shifted even more.

It is a drawing problem, because copying the text to the clipboard works correctly, so the whole line is there...

Also, beacuse of another post, I have the non-default options of "Process ANSI codes", "UTF-8 display" and SJIS/JIS conversion enabled.

My Display Settings: 1024x768, 32-Bit Color.

This has been reported before, by me and someone else as well.

Mainwindow (non listbox) tabbiing in 6.2 moves BACKWARD to the tabstop of that tab, rather than moving forward to the next free tabstop (the same as it already did in LISTBOX's)

ie: assuming tab stop was 5.5 characters in and you sent this line //echo ABCDEFGH $+ $chr(9) $+ XZY
>You would see ABCDEFXYZ (but with only the left half of F showing)
>This is the effect with no background the text is written, erased, from the tabstop, and the remaining text is writtin from there.

You however have discovered something else about it as well, if you insert a graphic into the background, the erase process is not done (likely because it might be gonna erase the background ), so the text is still written from the tabstop and it writes over the last text.

I beleive this is a bug personally, it may however be a unlisted feature of @windows now, time well tell.

[edit]
If it is a bug, i would love that it could be fixed, but remain inplay as a feature you can turn on about the window :-) <hint hint Khaled>

[edit2]
Hey try truning off the background, and all the text that was under the other text well disapear, you still have the missing text problem, but it demonstrates how the background has an effect. Pretty neat effect actually, makes for the option of adding flashing text.

Thanks this has been fixed for the next version.

DaveC looks like you're going to have to stick with 6.2 to keep the extra functionality :P

lol. it wasn't "erasing", it's just that when you echo text into a window with a solid background, it draws the text with a solid background. When you echo text into a window with a background, it draws the text on a transparent background.