MXP: send hint is cut at 88th symbol && UTF in hints is not converted

Posted by Erendir on Thu 19 Mar 2009 08:53 AM — 14 posts, 53,847 views.

Germany #0
1st problem:
MUSHClient receives

<send href="foo" hint="012345678901234567890123456789012345678901234567890123456789012345678901234567zzzzzzzzz">bar</send>

but shows as hint

012345678901234567890123456789012345678901234567890123456789012345678901234567z

only first 88 characters.

And yes, i need more than 88, because MUSHClient supports the &#10; entity in hints ;)

2nd:
MUSHClient doesn't convert UTF in MXP-hints. (UTF8-codes are ok: with Output->UTF-8(Unicode) checked same hint is correctly shown in output window.)

P.S.:
Text sent by MUSHClient from "Connecting->ConnectText. (Sent after connected):" memo doesn't appear in "Packet debug" window. Is this a feature?
Amended on Thu 19 Mar 2009 01:33 PM by Erendir
Australia Forum Administrator #1
Quote:

... only first 88 characters.



How do you get 88? I count 79. :P

The tooltip stuff uses the tooltip window supplied by MFC, the definition for a tooltip is here:


typedef struct tagNMTTDISPIFNOA {
    NMHDR hdr;
    LPSTR lpszText;
    char szText[80];
    HINSTANCE hinst;
    UINT uFlags;
#if (_WIN32_IE >= 0x0300)
    LPARAM lParam;
#endif
} NMTTDISPINFOA, FAR *LPNMTTDISPINFOA;


Note that there is only provision for 80 bytes, and after the terminating 0x00 at the end, that would be 79. Thus I cannot stuff more data in, even if I wanted to.

Quote:

MUSHClient doesn't convert UTF in MXP-hints.


The tooltip control does not support UTF-8, and even if it did, that would reduce the number of characters (perhaps halve it) as UTF-8 uses more than one byte per character, unless they are in the range 0x00 to 0x7F.

Quote:

Text sent by MUSHClient from "Connecting->ConnectText. (Sent after connected):" memo doesn't appear in "Packet debug" window.


It does appear in the packet debug.
Germany #2
1. Ok, is there any posibility to capture the OnHint-event and replace the tooltip-window by a miniwindow?
2. Hm, how easy would it be to implement the right-click-MXP-menus in miniwindows? Is there also any length restristions?
(I have just no experience with miniwindows now, thus the questions)
3. Ideed. :) The problem was, the server is sending a lot of text, plus the telnet negotiations... So i just haven't seen the very first packet from MUSHClient.
USA #3
Where did you get that type definition from?
If it was directly from a source file that would be compiled then you COULD change the value of it. Or redefine the structure within your own code. I know that you can fit load more in a tooltip simply from other programs I've used that let me load in nearly a full page in a tooltip. Even Autoit3 (v3.1.1.123 (beta)) allows this, as this example shows...

----------------------
$message = ""
for $i=1 to 98
$message = $message & 1
Next
ToolTip($message&"01"&@CR&$message&"02"&@CR&$message&"03"&@CR&$message&"04"&@CR&$message&"05"&@CR&$message&"06"&@CR&$message&"07"&@CR&$message&"08"&@CR&$message&"09"&@CR&$message&"10"&@CR&$message&"11"&@CR&$message&"12"&@CR&$message&"13"&@CR&$message&"14"&@CR&$message&"15"&@CR&$message&"16"&@CR&$message&"17"&@CR&$message&"18",0,0)
Sleep(5000)
----------------------

Each line is 100 characters + a return so 101 * 18 lines = 1817 (forgot last line does not have a return) characters in total.

Perhaps you can find the method they used to allow it to use such a lengthy tooltip.

I am pretty sure the developers would share such a secret, or at least point you in the direction they found it in.

Apparently the person that worked on the Tooltip interface of the scripting language was Jason Boggs <vampire dot valik at gmail com>, as per http://www.autoitscript.com/autoit3/docs/autoit_authors.txt

I suggest contacting them or via the forums on http://www.autoitscript.com/forum/index.php?act=idx

Who knows you might be able to bang the fix out in the latest minor version.

-Onoitsu2
Amended on Fri 20 Mar 2009 06:32 AM by Onoitsu2
Australia Forum Administrator #4
The type definition came from COMMCTRL.H.

I can't just change it, the implementation part would be inside mfc42.dll or whatever the exact name is.
USA #5
Well like I said there must be another way to do this, as it has been done. That little bit of code is proof that it works, whatever AutoIt3 uses.

I might ask about on their forums about the tooltip code they use, and might be able to get it from them.

-Onoitsu2
Australia Forum Administrator #6
Does zMUD / cMUD support larger send hints? If not, fixing it in one client is only solving half the problem.
USA #7
Well if it exists on a server then it ought to have a client out there that supports it. Besides using this "fix" would allow the client itself's use of larger tooltips.

-Onoitsu2
USA #8
I shot off a message to the person that worked on the Tooltip interface, as well as posted on the Developers Forum on their site, so hopefully within a few days we might have the code, or at least a place to look it up from for how to improve the tooltips within MUSHclient. Imagine if you were to add the same tooltip support to the Miniwindows that people create, AutoIt3 is able to use the same pictures that message boxes can, such as the !, ?, stop sign, and the i (information) within tooltips, including an optional title, and also to create it as a balloon tip, like those that show from the tray in XP.

Here's hoping they will be able to oblige this requested code.

-Onoitsu2
USA #9
Well their attitude on the forums and simply for any means of communication from the users of AutoIt has grown dark since I was last active on the forums. Their suggestion is not to use MFC.

I have looked over MANY sources listed as examples on the web, and the only way I see this happening is to alter the header file in which it is located, and allow it to be larger. Now me being a complete amateur programmer, more inclined to scripting, see that changing that as the only way, other than pulling in some example code for tooltips from the web, and having that called a million times over everywhere there is a tooltip used.

Not too happy at the moment, as this could have been a good push for miniwindows as well as the program itself could have gotten a slight visual feedback refresh.

-Onoitsu2
Australia Forum Administrator #10
I am really a client of that header file, if you take my meaning. Making it larger won't have much effect, except perhaps a rather spectacular crash, as I put things in it, where they aren't expected.

I'll see if there is another workaround, using miniwindows.
Netherlands #11
Can't you just -not- use the MFC facilities in this case? E.g. turn off the method they use for showing hints, and rig it yourself based on window messages and a call with HintWindow() I think it is?
Australia Forum Administrator #12
I have found a workaround. The field lpszText in the header is used if not NULL, and that can contain a much larger amount of text. I am fiddling around getting that working now.
Australia Forum Administrator #13
See: http://www.gammon.com.au/forum/?id=9342