Output area occasionally gets weird tooltip.

Since images say more than a thousand words, have a look at http://qs.merseine.nu/images/mush_bug_collage.png

The bug occasionally happens and I can't really reproduce it, but other applications do not show the symptoms. It generally happens after my monitors (yes I have two, and I only have it happen on this pc) go on power suspend mode. Again: it doesn't happen always - my monitors go on powersaving mode quite often and usually nothing is wrong.

Something I noticed just now is that I also have Ultramon running, and it showed something funky also. It had two 'useless' task buttons that would activate the MUSHclient application. With useless, I mean there were two buttons with the 'application has no icon' icon (resembles a window with blue title bar and white contents). I killed Ultramon and restarted it which made them disappear, before I realized I maybe should have taken a screenshot. Sorry about that. :/ In any case, I think the two may be related somehow.

If there's anything else you need to know, please ask but I can't even reproduce it - it just happens. :/

Edit: Oh, I forgot to say... the behaviour ONLY shows on the world-output area. It doesn't show with the tooltips on the toolbar buttons, for example.

Edit2: A friend reminded me to tell you I'm using a fully uptodate WXP pc. The theme may suggest Vista, but it's really XP with a uxThemes patch.

A Google for "tooltip themes mfc xp" seems to reveal a number of articles about people having problems with tooltips, under XP, when running themes.

One comment says:



It would appear that it (Windows) is trying to "theme" your tooltips, hence the different look. It isn't clear why the text isn't fitting as inside a function call (OnToolTipNeedText) which the tooltip "calls back" into MUSHclient, I simply calculate the text and supply that as a null-delimited string. Surely, even themed text should still display the whole string?

My problem here is that, from what I have read so far, there is no suggested fix, but you may find one perhaps. Obviously, removing the themes will probably help (or turning off the tooltips).

As a workaround you could (apart from those 2 ideas) make a plugin that effectively displays the same information in a dialog box, and is activated by hitting some keystroke. For example, if you really need to know what a certain line number is, and when it arrives, you could double-click a word in that line to select it, then use your plugin to find the line information.

I should point out that I haven't paid Microsoft for a new version of the Visual C++ compiler for some time now, so my copy isn't XP (or Vista) "aware". However it seems to work pretty well apart from some very minor issues - in fact this is perhaps the first one, and indeed there is no guarantee that the problem would be fixed by a more up-to-date compiler. Perhaps the theming code is simply to blame.

If you can find some web site that suggests fixing the problem by sending a certain message to the tooltip control, I can certainly add that message in. For example, there is currently:



That line of code tells the tooltip to disappear after 5 seconds. Now if there was something similar that said "don't use themes" then that could be a simple fix. However, on the MSDN page which has TTM_SETDELAYTIME I see no such message.

Hrm, nasty little bug that must be, then. I take it you didn't code the buttons on the toolbar yourself, but maybe you have access to the source and are able to compare them that way?

I have no C++ or msdn references installed, so I'm afraid I can't do more than suggest an odd thing or two.

Edit: doing a few google thingies on preventing controls from being themed, I read that ownerdrawing prevents it. Since the hint window isn't all that complicated in its visual appearance, perhaps it is an option to supply your own drawing routine?

I'll take a look, although it seems a lot of work to fix a bug in a themes package.

I should say that I don't really consider this a MUSHclient bug.

Looking at your screendump, the themed tooltip is shorter than the non-themed one, but if you allow for the fact that one seems to be a note line (and has ", (note)" added to it) they seem about the same length - although it is hard to be certain because of the length of the line number.

Anyway, it looks like the themed code is doing this:

• Calculating the size of the tooltip, based on the usual font.
• Drawing the tooltip in this size.
• Switching to the new, larger font, and drawing the text (which now doesn't fit).

Looks like a straight bug in their drawing code. This code is not inside MUSHclient.

Fair enough, but that still leaves me with the question: why do toolbars and other tooltips in MUSHclient not have this 'other' tooltip behaviour, whereas the world output area does? No other windows application seems to have this issue for me, so from the point of the user, the bug is in MUSHclient. It isn't like the user can change the MFC framework around for a wxWidget framework for example.

But that's just nitpicky of me. I don't mind if the bug doesn't get fixed - it just gets on my nerves when I need to lose my entire 500,000 lines of buffer when this happens.

As for the menus, I think the tooltips there are part of the standard Windows behaviour, so any change needed to make it work was part of the system (or, if they worked badly the theming thing would be fixed much more quickly).

Rather than losing 500,000 lines you could always turn the themes off. You could try turning themes off temporarily, then turning them back on, that might fix it on the fly.

I'll give that a shot next time. Thanks. :)

I am starting to suspect that maybe there is a maximum size limit on tooltip text (perhaps 30 characters). This doesn't seem to apply to normal operation, but the themed tooltips seem to be truncating and then adding "..." to the end.

I gather the real problem is you are missing all the information, rather than simply the different appearance?

Unfortunately the tooltip text does not seem to go through the translation functions I did for the internationalization, if it had you might have been able to shorten it (eg. a shorter date).

If the tooltip text could be customized, that might fix the problem, at least partly.

The missing information is the primary annoyance, aye, although I'm generally quite OCD with things like that. If a tiny thing isn't as it should be, it gets on my nerves big time. (How many scripts haven't I rewritten because of one thing I don't like... I lost count already. :D)

Well if I make the tooltip text customizable that should help. Perhaps you could translate more of the messages into Dutch while you are at it?

I think it will have to be a 2-step process - first the date/time part will need to be converted, and then incorporated into the message about the number of lines and type of line.

Version 4.23 now allows you to customize the tooltip - perhaps you can shorten it enough to fit relevant information into it.