AutoHotkey Community

This simple script doesn't work in AHK v2.0-a100.

Why should that work?
See: The Control Parameter
Why would one try to get the HWND of a control by its HWND?

[Moderator's note: Topic marked solved by lexikos.]

The documentation states that the right parameter should be the information about the window that contains your Control.
The left parameter states that the right parameter should be the information about the control.

In the first case you use this in a valid way to get the hWND of a control.
In the second case you use this in an undefined way - you provide information about a control on the right side and provide no information on the left side.

The documentation does not state anything about your specific case - expecting any sort of behavior here is bad practice.

If the function had slightly different functionality and would not care whether it searches through windows or controls and if you could use "" to imply that you just want to find the first control and if the container itself is subject for search then you could expect the behavior that you have given.
This might be a valid suggestion and we have to see through the advantages and disadvantages.

@just me:
Not only the ControlGetHwnd function uses this sort of lookup, but all ControlGet functions.
Maybe you want to get the ClassNN given the hWND.
Yet they all share this lookup.

- Ever since I started using AutoHotkey, if you want to use a control hWnd in a ControlXXX function, you use "ahk_id " hCtl in the *WinTitle* parameter.
- (Perhaps it would make sense if you could also do this in the *Control* parameter. But it would still be useful if WinTitle could continue to handle both control and window hWnds.)
- @just me: Yes, the example script is not particularly representative.
- Either the change was intended or unintended. If prolonged, (a) this would have major conversion costs, and, (b) IMO the a099 behaviour is more useful, as hinted above.
- If Control/WinTitle can accept an integer/object with hWnd property, that's great, but I wouldn't simultaneously reduce the functionality of the Control/WinTitle parameters.

jeeswg wrote: ↑

28 Oct 2018, 12:13

- Ever since I started using AutoHotkey, if you want to use a control hWnd in a ControlXXX function, you use "ahk_id " hCtl in the *WinTitle* parameter.
- (Perhaps it would make sense if you could also do this in the *Control* parameter. But it would still be useful if WinTitle could continue to handle both control and window hWnds.)

Could you provide another reason, that is slightly better than just saying "I always did it like this"?
Even if you succeeded doing it like that before, it was never meant to work in the first place.
Using it like you used it is an uncaught error - it should result in throwing an exception in v2, v1 should just return "" and set the ErrorLevel.
What is the specific reason you want to use it in this specific way.
It would be more logical consistent to use the normal way to do this.
Is there any specific reason as to why you want this behavior other than "I have done this before" and do you have any prove for "It is useful" that could show how it is more useful than the current behavior?

ControlGet - Syntax & Usage | AutoHotkey
https://autohotkey.com/docs/commands/ControlGet.htm

To operate upon a control's HWND (window handle), leave the Control parameter blank and specify ahk_id %ControlHwnd% for the WinTitle parameter

Also, the WinTitle parameter supports ahk_id %ControlHwnd% for WinXXX functions: Repeatedly using a window/control hWnd is faster than repeatedly using window/control criteria to refer to a window/control.

Oh you are right this worked in v1.
Also you can already use the controls hWND in v2.
The syntax is just different from the way you used it.

a100 wrote: Changed usage of Control parameter with Control functions and SendMessage/PostMessage.

• Can be a HWND (integer)
• Can be an object with a HWND property
• Mandatory in most cases
• Omit to use target window itself (ahk_parent is removed)
• Blank values are invalid (never default to topmost control)

A control's handle (HWND) can be used as a valid and unique control identifier in the Control parameter know. It doesn't need to be and should not be used in the WinTitle parameter of Control functions. (Besides "two-way compatible conversion logic" it doesn't make sense.)

lexikos wrote:Note: Specifying a window (WinTitle) by HWND still requires ahk_id for now. WinTitle will get similar treatment to Control in a future update.

What do you think this means? ControlGetHwnd("", "ahk_id " hCtl), specifically, "". It should mean that you want to find a control which has the text "", in the window identified by hCtl. Does the edit control in notepad have any controls?

Consider this example, Would you like controlgethwnd to return the same hwnd as g.hwnd? That wouldn't be very useful.

A quick look in the documentation doesn't really tell me that blank values are invalid, as the quote above suggests. It should result in an exception if it is invalid. In your example, errorlevel is set to 1, which indicates a problem.

Cheers.

The helpfile doesn't explicitly state that blank values are invalid.
However blank values are not among the possible values for the expected input types.

Sure, although type('') is String, '' isn't Text, I can agree. I do not know if searching for controls with no text is a thing. In any case, it should be an exception if it is not valid.

I stand corrected. With the text option being available directly and the TitleMatchMode possibly being set to 3 "" is a valid input.
That being said it was simply unthinkable for me that the text option was available directly like this.

it was simply unthinkable for me that the text option was available directly like this.

I guess it is done this way because the ambiguity is empirically known to be insignificant.

just me wrote:A control's handle (HWND) can be used as a valid and unique control identifier in the Control parameter [now]. It doesn't need to be and should not be used in the WinTitle parameter of Control functions.

- Let's say someone intentionality/unintentionally put a control hWnd in the WinTitle parameter, what would be the most useful behaviour? To allow it.
- Besides, occasionally you want to refer a control within a control within a window, necessitating a control hWnd to be used in the WinTitle parameter. - All things considered, IMO, 'Control' as a blank string makes sense as omitted (not an hWnd/a ClassNN/text to search for).

- No-one's said this directly yet but perhaps you believe that ahk_id is no longer needed in AHK v2, since you can specify an hWnd directly.
- But what about this as one example, it should succeed or fail depending on whether the window is hidden or not: - ahk_id is also useful because it means you do not have to force the hWnd to be of numeric type. E.g. I often operate on comma-separated lists of hWnds via an InputBox or via the selected text.
- Btw does anybody seriously want to downplay the cost of removing ahk_id etc from every script ever written in AutoHotkey?

- Let's say someone intentionality/unintentionally put a control hWnd in the WinTitle parameter, what would be the most useful behaviour? To allow it.

To tell you you made a mistake.

- Besides, occasionally you want to refer a control within a control within a window, necessitating a control hWnd to be used in the WinTitle parameter.

That makes sense in a way but then again causes issues with ClassNN.

- No-one's said this directly yet but perhaps you believe that ahk_id is no longer needed in AHK v2, since you can specify an hWnd directly.

It's not needed since you have the absolutely unambigous option to pass an object containing the hWND parameter.

- ahk_id is also useful because it means you do not have to force the hWnd to be of numeric type. E.g. I often operate on comma-separated lists of hWnds via an InputBox or via the selected text.

Instead you force the hWND to be a string.
How is that an advantage? At least when using the object you can pass the hWND in any form.

- Btw does anybody seriously want to downplay the cost of removing ahk_id etc from every script ever written in AutoHotkey?

I plan to rewrite scripts rather than maintain any of the old ones.
But yeah if any of my scripts would be moved to v2 it wouldn't be too difficult since my focuses lie on maintainability and reusability.

On a general note the amount of work a breaking change introduces for old, in this new version broken scripts should be a lower priority than any other concern regarding usability and maintainability.
Also rewriting scripts is more useful than maintaining, unmaintained old ones.

Besides, occasionally you want to refer a control within a control within a window, necessitating a control hWnd to be used in the WinTitle parameter.

No one said a control's hwnd can't be used in the wintitle parameter, the point is that the traget window / control is not considered in the search, the search is conducted on the controls of the taget window / control. Your script should work if this FindBarClass1 control has a control with classNN Edit1.

All things considered, IMO, 'Control' as a blank string makes sense as omitted (not an hWnd/a ClassNN/text to search for).

This is what I guessed you thought your code was supposed to mean, the fact that the parameter isn't optional should hint to you that you should ask for help on how to use the function instead of claiming there is an issue, And no, it doesn't make sense.

No-one's said this directly yet but perhaps you believe that ahk_id is no longer needed in AHK v2, since you can specify an hWnd directly.

It is off topic. The documentation has an actual valid example of combining ahk_id with other criterias, see Mulitple criteria. In any case, we can only hope that this ahk_xxx-mess gets replaced by something more readable.

Btw does anybody seriously want to downplay the cost of removing ahk_id etc from every script ever written in AutoHotkey?

Why do you continue to fight progress?

Cheers.

Helgef wrote: ↑

31 Oct 2018, 06:10

Btw does anybody seriously want to downplay the cost of removing ahk_id etc from every script ever written in AutoHotkey?

Why do you continue to fight progress?

because all he cares about is writing 2 way compatible scripts, despite the very specific quote on the AHK v2 page:

"AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility."

the whole ahk_id thing is really bad language design and it will be nice to have it gone

- This is simple to understand conceptually:
- Internally, ControlXXX functions operate on an hWnd.
- WinTitle, WinText, ExcludeTitle, ExcludeText determine that hWnd.
- If the Control parameter is not empty, it is used to determine a 'control' hWnd within that hWnd.
- (Or perhaps if the Control parameter specifies an hWnd, that overrides the other hWnd.)

- Here are 3 simple rules:
- If the Control parameter is blank, operate on the window.
- Keep ahk_id, some tasks will always require it.
- If you use "ahk_id " hWnd, hWnd can be a string, if you use hWnd by itself, you must convert it to an integer to guarantee avoiding an error.

- A question for other people:
- How do you distinguish between a 'window' hWnd and a 'control' hWnd? (I have an answer for this, let's see if you've actually thought this through.)

- @nnnik: AFAIAC, using a 'control' hWnd is perfectly fine, anyhow, how would you tell apart 'control'/'window' hWnds?
- 'issues with ClassNN'!?
- ahk_id *is* needed, e.g. when you need to combine multiple ahk_xxx tags. (And using an object makes things more verbose and slows things down.)
- (OK, so you do downplay the costs of rewriting, at the moment, not that you wouldn't regret it later, in small ways, on a daily basis, including when working on other people's or old scripts. And you do choose to neglect to mention that not everyone is a 10-year user of AHK.)

- @Helgef: I kept my OP short and sweet, stating no assumptions, hoping for clarification, to be honest, I thought that only lexikos could provide an answer, but everyone chimed in with their opinions anyway, like they always do.
- Why would you contradict this: a blank control parameter should mean: operate on the window specified by WinTitle/WinText/ExcludeTitle/ExcludeText. Your reasons for this are not clear.
- Re. progress. My general view of suggestions on the AutoHotkey v2 Development forum is that people get things partially correct, anywhere from 50% to 95%. But that 5% error can be 'devastating'. Every so often I see what I consider small missteps with big consequences, I try to nudge things along in the right direction by suggesting the minimum of tweaks.

- @guest3456: As always, if a change is 'tough but right', I support it, if a change is a (severe) misstep IMO, I challenge it, especially if the change will cause confusion or unwarranted degrees of wasted time for the userbase.
- What's your point, 'sacrificing backward compatibility' is not 'sacrificing backward compatibility for the sake of it, even if the change is bad' or 'ignoring backward compatibility' or 'rejecting backward compatibility'.

- @Helgef+@guest3456: ahk_xxx is very readable. I doubt that you'll invent a better/more readable/non-verbose system. I thought that it was the one slightly quirky feature that would likely remain in AutoHotkey, but it's useful and I like it. Out of interest, I had wondered if someone would propose an alternative, to exist alongside it, but I would keep it nonetheless.

- OK, well I believe I have figured everything out.
- I was pleased to find out that ControlSend now allows you to omit the Control parameter and operate directly on the window, which it didn't before. However, other controls now *require* the Control parameter.
- For the sake of simplicity, and avoiding a 'doomsday' conversion scenario, and weird bugs in all kinds of places, I would suggest that the Control parameter be omissible in all ControlXXX functions.
- Where "" was used to omit the Control parameter but will now fail, the user can search through script lines that contain both "" and Control and fix these manually, inconvenient, but acceptably so. (I might suggest that blank and omitted be equivalent, but that's another discussion.)
- I have been working on updating the ControlXXX and WinXXX functions in my 'AHK v2 functions for AHK v1' library, and it's been tricky to work out in full what the AHK v2 functionality is (or will be in the case of WinXXX). A lot of people have wanted this functionality for AHK v1/v2 anyway, but being able to detect when a parameter is omitted would be really useful when writing these functions. Cheers.

The problem here is that "" can be perfectly valid if you look for a control that contains no text.
For that you would have to set title match mode to 3 though.
If the title match mode is 1 or 2 "" will match any control.