WM_Help Context IDs for GUI Controls Topic is solved

[lmstearn]

Hi there,
Reference : here and here and here for dialogs.
A possible "easy" strategy for context help without a help file is just to use Traytip. Looking at something like:

Code: Select all

HELPINFO_WINDOW := 1, iCtrlId := 0, iCtrlHwnd := 0, dwContextId := 0, MousePosX := 0, MousePosy := 0

;WM_Help
WS_EX_CONTEXTHELP := 0x00000400
VarSetCapacity(lpHelpInfo, 28)
NumPut(28, lpHelpInfo, 28, "UInt")
NumPut(28, lpHelpInfo, 0, "UInt")
NumPut(HELPINFO_WINDOW, lpHelpInfo, 4, "UInt")
NumPut(iCtrlId, lpHelpInfo, 8, "UInt")
NumPut(iCtrlHwnd, lpHelpInfo, 12, "UInt")
NumPut(dwContextId, lpHelpInfo, 16, "UInt")
NumPut(MousePosX, lpHelpInfo, 20, "UInt")
NumPut(MousePosY, lpHelpInfo, 24, "UInt")

Gui -MaximizeBox -MinimizeBox +E%WS_EX_CONTEXTHELP%
Gui, Add, Button, gCloseMe w100 default
OnMessage(0x0053, "WM_Help")
Gui, show
Return

CloseMe:
GuiClose:
ExitApp

WM_HELP(wp_notused, lpHelpInfo, _msg, _hwnd)
{
iCtrlID := Numget(lpHelpInfo, 8) ; constant value
iCtrlHwnd := Numget(lpHelpInfo, 12) ; blank


traytip,, % " iCtrlID: " iCtrlID " iCtrlHwnd: " iCtrlHwnd
}

iCrtlID is fine, but HWND variables have to be defined for every control. It might be slightly less overhead to put dwContextId into an array, but how to generate them?
This Delphi thread looked promising, but the linked pas file at the end has moved on.
However we see from the bottom of this How To that the ContextIDs are mapped to the HWND anyway, so it looks as if what we are seeking is not very practical.
Any ideas appreciated.
Thanks.

[jNizM]

something like GuiControlTips (using ToolTips)?

[lmstearn]

@jNizM: Thanks, looks like a good option. Will have a look at that. Perhaps traytips in Windows 10 is a bit loud for context help for our purposes at any rate.

[lmstearn]

It looked like the code in the OP was completely non-functional, so updated it.
But it still is, but no reason as to why PhiLho's code works and not this. Anything missed?
Thanks again.

[jNizM]

Code: Select all

OnMessage(0x0053, "WM_HELP")

Gui -MaximizeBox -MinimizeBox +E0x00000400
Gui, Add, Button, gCloseMe w200 h40 default, % "Button"
Gui, Show
Return

CloseMe:
GuiClose:
ExitApp

WM_HELP(wParam, lParam, msg, hWnd)
{
    Size         := NumGet(lParam +  0, "uint")
    ContextType  := NumGet(lParam +  4, "int")
    CtrlId       := Numget(lParam +  8, "int")
    ItemHandle   := Numget(lParam + 16, "ptr")
    ContextId    := NumGet(lParam + 24, "uint")
    MousePosX    := NumGet(lParam + 32, "int")
    MousePosY    := NumGet(lParam + 36, "int")
    ToolTip, % Size " | " ContextType " | " CtrlId " | " ItemHandle " | " ContextId " | " MousePosX " | " MousePosY
}

/*
typedef struct tagHELPINFO {    //         x64    x86
	UINT   cbSize;              // uint      0      0
	int    iContextType;        // int       4      4
	int    iCtrlId;             // int       8      8
	HANDLE hItemHandle;         // ptr      16     12
	DWORD  dwContextId;         // uint     24     16
	POINT  MousePos;
} HELPINFO, *LPHELPINFO;

typedef struct tagPOINT {
	LONG x;                     // int      32     20
	LONG y;                     // int      36     24
} POINT, *PPOINT;

                                ----------------------
                                   sizeof   40     28
*/

[lmstearn]

@jNizM: Ah, thanks. We're almost there! But the itemhandle is zero for the control clicked. It just doesn't want to play nice!

[jNizM]

It works for me. Do you run the script as 64-Bit or 32-Bit?
If 32-Bit see in comments and change the values...

[lmstearn]

Got you now, Thanks.

[lmstearn]

@jNizM: Just slighly off-kilter here, but the DWORD type works fine for the 32 bit build. In porting over to 64 bit, is it necessary to change to DWORD64 or just leave as DWORD with the new alignment as you indicated.
As reference, could you suggest a list of other types to watch out for when porting over?
Thanks once more.

[just me]

Just another mistake in MSDN:

Code: Select all

typedef struct tagHELPINFO      /* Structure pointed to by lParam of WM_HELP */
{
    UINT    cbSize;             /* Size in bytes of this struct  */
    int     iContextType;       /* Either HELPINFO_WINDOW or HELPINFO_MENUITEM */
    int     iCtrlId;            /* Control Id or a Menu item Id. */
    HANDLE  hItemHandle;        /* hWnd of control or hMenu.     */
    DWORD_PTR dwContextId;      /* Context Id associated with this item */
    POINT   MousePos;           /* Mouse Position in screen co-ordinates */
}  HELPINFO, FAR *LPHELPINFO;

[lmstearn]

@just me: thanks for the info.
Just another thing (Sure there was something on this years ago) can we ever get a help context working for any item on the sysmenu? (the motivation for this was for rendering the close button non-functional with 0xF060). Expect the answer to be no as this is DefWindowProc internals territory.
But at any rate, the WM_Help question mark appears on the title bar mouse_over, so on activation one would at least expect a jump to good ole you know what.
Edit: All being "client area", just processing all the help messages for anything on a form not specified as control with a general reference doc. it's no big drama.

[lmstearn]

Winding on another 4 years, and experiencing weird behaviour when the GUI is created in a function. The Help system pulls up the chm file twice- as described here. The reasons given there have no immediate relevance to AHK, at least as far as VK_F1 goes, suffice to say Help handles function GUIs the same as CFrameWnd. As to the reference of time- a grand old windows featu-roo dating from Win16 still bouncing around against the receding horizon of HTML Help.