winHWND := hwnd()

Here's the request (many possible uses)... . I realize that there are a few ways to accomplish this using other methods but I think that this would be a simple and very handy solution...

GuiGetHWND(["Control", "GUI #"])

Returns the Unique ID (HWND) of the specified AutoHotkey window or control.

Control - classNN or variable name of an AutoHotkey control GUI # - The number of the GUI window where the control exists (defaults to the default Gui window)

- If Control is not specified then the function returns the HWND of the Gui Window instead- If both Control and GUI # are not specified then the function returns the HWND of the default AutoHotkey Gui window.

Edit: changed suggested function name.Edit Again: The following function seems to work in most cases using ClassNN to identify the control:

You probably already know that the HWND of a GUI window can be retrieved (even if hidden) via:

Gui +LastFound
hwnd := WinExist()

As for the hwnd of GUI controls: Although I can see that such a feature would be useful, I think the percentage of people who use control hwnds in their scripts is quite low. If true, adding a built-in function (especially one with such a short name) might not be justified.

However, there is a plan to improve SendMessage/PostMessage and some of the control-targeting commands so that it's easier to work with GUI windows and their controls (perhaps by allowing control variable names in place of ClassNN). If you have some scripting need for which you can't find a suitable solution, perhaps you could post it to see if anyone else can think of anything (and if not, that would help justify adding a new function or command).

Hi Chris. Thanks for the quick reply . I'd prefer not to use Gui +LastFound and wnd := WinExist() in some cases. I usually need to know the HWND of a Window and/or control before the window has been displayed and before any other code has been executed. Using the Active window for determining the HWND of a Gui window is not a reliable method IMO as other apps could be running that steal focus. As I mentioned, there are other methods of retrieving a HWND of a window/control depending on circumstances but I was hoping to simplify the code. I'm currently working on putting together a few Gui functions and an IDE for creating AutoHotkey Gui based scripts. A command like this could greatly simplify things (especially in making the code easier to read and understand) when working with dynamically created windows/controls.

I see your point about the name of the function. It is a bit short and not very creative. Something like GetHwnd or GuiGetHwnd (or any other name of you choosing) would work ok. I may be wrong but wouldn't this be a fairly quick addition to make as AutoHotkey should be able to determine a HWND of one of it's own windows/controls fairly easily?

I usually need to know the HWND of a Window and/or control before the window has been displayed and before any other code has been executed.

That can be done with +LastFound because it works even on hidden windows.

Using the Active window for determining the HWND of a Gui window is not a reliable method IMO as other apps could be running that steal focus.

The LastFound method does not rely on the window being active.

I may be wrong but wouldn't this be a fairly quick addition to make as AutoHotkey should be able to determine a HWND of one of it's own windows/controls fairly easily?

It would be very small in code size, but I've received criticism about the complexity of AutoHotkey and its documentation -- criticism that I agree with. Therefore, it seems best not to add new functions, commands, and built-in variables unless they would benefit more than 1% of users. This proposed feature might meet that requirement, but it would help to see more usage examples to help justify it.

In any case, the ability for non-GUI commands to work more easily with GUI controls is already on the to-do list. I wish I had more time to work on development, but lately hosting issues and other support tasks have been a distraction.

Thanks for the reply. Using Gui, +LastFound at the beginning of the script seems to work ok. It does seem really cryptic though. How many users would likely think of doing that to accurately get the HWND of an AutoHotkey window (even after reading the help)? While I understand wanting to cut down on unnecessarily adding functions and commands I think this one would simplify things considerably for anyone that looks in the help file for how to retrieve a HWND. I'm not sure I understand why many methods (most buried in the help) should be used instead of one generic one. As you have noticed there are many reasons to use a HWND of a window/control in a script. I'm guessing that's why you have recently added the ability to a couple existing commands. This functionality makes more sense as a function IMO though as this is where this type of data would be used in most cases.

I was about to request this feature too. I need this feature for a include script i am working on. I need to know the hwnd of the gui and contolls because i want to send messages to the scriptwindow itself and dont want the user of my includescript to have to find the hwnds with windowspy.

In case this is all that is needed i see no reason not to support it as this will greatly enchance the ability to create helpers for controls that take the vVariableName as the ControlID. This would make helpers much easier to use than by using ClassNN.

The code required to add the feature is not the issue. The issue is that adding a feature to treat the symtoms of a problem is not as good as directly correcting the problem.

In this case, the problem seems to be that some commands like SendMessage do not accept GUI variables as a means to uniquely identify a control. So perhaps such commands should be extended instead of adding a new feature that might quickly become obsolete. Since that requires careful planning, it should be prioritized against other planned features.

In this case, the problem seems to be that some commands like SendMessage do not accept GUI variables as a means to uniquely identify a control. So perhaps such commands should be extended instead of adding a new feature that might quickly become obsolete. Since that requires careful planning, it should be prioritized against other planned features.

Adding this functionallity make it aviable anywhere and not only in sendmessage like what you suppose. And as philho said. Its aviable in ControlGet why not add it to GuiControlGet?