Erik Falor wrote:
While writing a guitabtooltip function, I discovered that the
tooltips in Win32 don't properly handle backslash-escaped chars.
In particular, '\n' comes out as a box, and '\t' appears to terminate the
string like '\0'.
The GTK gui on Linux, however, works as expected.
Erik Falor wrote:
While writing a guitabtooltip function, I discovered that the
tooltips in Win32 don't properly handle backslash-escaped chars.
In particular, '\n' comes out as a box, and '\t' appears to terminate
the string like '\0'.
The GTK gui on Linux, however, works as expected.
Ben Schmidt wrote:
Erik Falor wrote:
While writing a guitabtooltip function, I discovered that the
tooltips in Win32 don't properly handle backslash-escaped chars.
In particular, '\n' comes out as a box, and '\t' appears to terminate
the string like '\0'.
The GTK gui on Linux, however,
Well, I suppose by 'works as expected' I meant that the string escapes
didn't blow up :)
What I think should be acceptable behavior is for the guitabtooltips to
behave the same as the tooltips given by the balloon-eval feature.
From debugger.txt line 103:
The Balloon evaluation functions are
On 02/01/2008, Tony Mechelynck [EMAIL PROTECTED] wrote:
On Windows, where the OS-standard line break is \r\n, shouldn't _that_
also be
used to break lines in a tooltip? And what about Mac?
Best regards,
Tony.
\r\n results in two boxes.
--
Registered Linux User #445632
On 02/01/2008, ap [EMAIL PROTECTED] wrote:
I think this information from 'h balloonexpr' applies.
To check whether line breaks in the balloon text work use this
check:
if has(balloon_multiline)
When they are supported \n characters will start a new line.
I think there are no
