@Jimmysan
I apologize for not considering your situation. Sorry.
Next time, please provide more specific details about your own situation. As someone answering, there's no way to know if you're a novice or have some experience.
At least in this case, I didn't assume you were a beginner.
Before I begin,
@Noitalommi_2's code is excellent on its own.
Initially, I aimed for a similarly concise response.
However, due to a slight delay, I couldn't respond earlier and since I was already crafting a response, I decided to adjust the direction towards a more specialized explanation.
After all, there's no need for identical responses, right?
The first code I provided is the most standard-like method.
Essentially, it monitors the
WM_HELP message and extracts information from the
lParam, which contains the address of the
HELPINFO structure, whenever a message is received from the
Gui window owning the
MsgBox.
While the first code might seem complex at first glance, personally, I store the HELPINFO part in my personal library and
#Include it, so writing that much code isn't often necessary. (The code is designed for reusability.) This approach is useful beyond just using WM_HELP for
MsgBox's Help button; for instance, you might want to obtain the mouse coordinates at the time WM_HELP is received. You may also want to obtain the hWnd of the MsgBox itself.
Anyway, I've had occasions where I needed to use the HELPINFO structure frequently, and I prefer managing one message in one function, hence I tend to write it this way.
However, I admit, the first code I provided isn't particularly straightforward.
It was quite cumbersome to calculate the memory location to reference for obtaining the HELPINFO structure information each time.
Although I designed it to be easily reusable using the
Class's
Meta-Functions, it's not very straightforward. (This isn't a common practice, so to prevent confusion, I wrote down the traditional method of retrieving structure information from a specific memory address at the bottom as a comment.)
The second response was crafted to be more user-friendly.
It creates a temporary
Gui and
callback just before the
MsgBox is created, enabling the MsgBox to receive WM_HELP messages, and removes the Gui and callback when the MsgBox is closed.
The complexity compared to
Noitalommi_2's code arises from its actual complexity.
MsgBoxes can be invoked across multiple threads, up to a maximum of 7 simultaneously.
Providing different Help options for each
MsgBox in such cases requires more complex code.
While I prefer handling this in one message callback, it requires prior information about the
MsgBox and the
Gui object associated with it, making dynamically assigning message callbacks challenging.
Thus, if each newly created
MsgBox were to be assigned individual callbacks, the code would become even more complicated.
The order of callback creation alongside MsgBoxes for each
thread, and the actual sequence of pressing the Help button, may vary, so in practice, the callback and its corresponding MsgBox should be designed to be mutually exclusive.
I didn't want to create a new
Class instance every time to handle multiple threads, hence I used
ObjBindMethod to tie the callback to the
hRootWnd of the
Gui, which has been preprocessed with
+OwnDialogs.
However, even this isn't easily understandable code.