passing parameters as strings v. numeric Topic is solved

[Flipeador]

Maybe the syntax could be changed to SendMessage(Msg, wParamType, wParam, lParamType, lParam, WinTitle, ReturnType, Timeout). Honestly I'm not sure how these parameters work (wParam, lParam) (I'm not talking about the built-in functions).
Actually I have never used the parameters "WinText, ExcludeTitle, ExcludeText", in fact I never saw a code that uses them... With respect to the 'Control' parameter, ControlGetHwnd can be used...
I have never liked these parameters mentioned above, nor the behavior of the parameters wParam, lParam, VarOrAddress.
This inherits things from old AutoHotkey versions, and sometimes you can come to think that AutoHotkey is a language for children who only want to do something without effort and once they have done it, they forget its existence; instead of a serious language... Sometimes you want to do things that make 'life' easier for the 'programmer' but only instruct bad practices, confusing and 'unethical' syntax... I'm not looking to offend anyone, maybe I'm wrong, it would be great to read other opinions
If these things would be 'corrected', and btw, if the 'VarSetLength' function could be incorporated in these months (I can not wait anymore ), it would definitely be great for this version.

[jeeswg]

- I had found the complexity of the AHK v1/v2 parameter-handling distinctions in NumGet/NumPut/PostMessage/SendMessage quite puzzling when I'd read about them in the past. Although having read through the help pages again now, I believe that I've managed to fully enumerate the possibilities below. The following are my suggestions for the relevant parameters in the NumXXX and XXXMessage functions (which I believe is essentially what the NumXXX functions use now):

Code: Select all

VarNum := 123
VarStringNum := "123"
VarString := "abc"

NumGet(VarNum) ;addr := VarNum
NumGet(VarStringNum) ;addr := VarStringNum+0
NumGet(VarString) ;addr := &VarString ;pointer to "abc" ;[quirky, a concession to AHK v1]
NumGet(123) ;addr := 123
NumGet("123") ;addr := 123
NumGet("abc") ;addr ;pointer to "abc" ;[quirky, a concession to AHK v1]

- I might also suggest that the WinTitle parameter be this kind of parameter: if numeric or a string containing a number, interpret that as an hWnd. And 'ahk_title' to force interpreting a string that contains a number as a title.

- For oFile.RawRead/oFile.RawWrite, I might suggest something like oFile.RawReadVar/oFile.RawWriteVar, to allow for more consistency.

- @Flipeador: I generally agree with your outlook. I would describe it as: sometimes by trying to make the language easier, it made things more complicated/difficult/quirky/confusing.
- Like you, I never use "WinText, ExcludeTitle, ExcludeText", I did use 'WinText' occasionally, but that was when 'ahk_exe' was not available.
- Perhaps 'ahk_xclass/ahk_xtext' etc could allow the (rarely used?) ExcludeTitle/ExcludeText parameters to be removed.

[nnnik]

I dont think it's quirky. It's just not like SendMessage or inconsistent with SendMessage.

[Helgef]

The quirk of v1 for these parameters are gone, in v2, you never need to do var+0 unless you do something ridiculous such as myNumbers := x "," y or myAddresses := &x "," &y.

Code: Select all

NumGet(VarStringNum) ;addr := VarStringNum+0

That would not only be quirky, inefficient and useless, it would render this

Code: Select all

NumGet(VarString) ;addr := &VarString ;pointer to "abc" ;[quirky, a concession to AHK v1]

useless.

I believe is essentially what the NumXXX functions use now

I give a brief summary of how it works, if there is still any confusion,

Code: Select all

wParam := 1 ; pure number
sendmessage , wParam ; the number 1 is passed
wParam := "1" ; (numeric) string, cf, type(wParam) vs. wParam is "number"
sendmessage , wParam ; the number &wParam is passed, and something like varsetcapacity(wParam,-1) is done after the call

The community's favourite word is concistency, and that is what we got with these changes (and performance and convenience), you can now pass a variable reference to these functions just as you can to any other built-in function. mousegetpos &x, &y anyone?

Code: Select all

SendMessage(Msg, wParamType, wParam, lParamType, lParam, WinTitle, ReturnType, Timeout).

wParamType, lParamType is implied by what you pass, compare to dllcall, the implied type is "str" if you pass a string, the pointer is passed and strlen is updated. Otherwise it is int/uint on 32 bit ahk/target or int64 on ahk 64. Double, float not supported ofc. (@jeeswg, so you need round(x) and not x+0 )

VarSetLength

+1

I can only imagine strgetput will eventually distinguish between pure integer input and string type variables, for the address parameter.

Cheers.

[nnnik]

Oh I just read again and this is just your suggestion - I guess then everything is fine since your suggestion would not work properly.
What would happen if I have a variable containing the binary data of the string "1234" followed by a null terminator at the beginning?
Would AHK handle this correctly? The last time I checked AHK handled strings and binary data the same way.
When we would use your suggestion that would mean that AHK would try to access the address 1234 instead of reading the binary data presented to it.
And thats a way bigger problem than anything your suggestion fixes.

[Flipeador]

I never use "WinText, ExcludeTitle, ExcludeText", I did use 'WinText' occasionally, but that was when 'ahk_exe' was not available.

I cannot imagine... You can use WinExist anyway.

I'm still not convinced by the operation of these parameters ... it's very confusing for me to see a very extensive code and try to constantly guess how a parameter is interpreted depending on its content in this way. Maybe one solution would be to force the use of &str if you want to pass a string.

I might also suggest that the WinTitle parameter be this kind of parameter: if numeric or a string containing a number, interpret that as an hWnd. And 'ahk_title' to force interpreting a string that contains a number as a title.

Spoiler

mousegetpos &x, &y anyone?

Very nice, in general for OutputVar +1

---

Edit* I think we should have a more robust, restrictive and clear syntax/parameters; and not parameters that magically try to adapt to the strange things that the programmer tries to make work with the excuse of making life easier for new users, they should read the documentation, as it should be.

[Helgef]

What would happen if I have a variable containing the binary data of the string "1234" followed by a null terminator at the beginning?

As you realised, it wouldn't work, that is what I meant by

it would render this

Code: Select all

NumGet(VarString) ;addr := &VarString ;pointer to "abc" ;[quirky, a concession to AHK v1]

useless.

it's very confusing for me to see a very extensive code and try to constantly guess how a parameter is interpreted depending on its content in this way. Maybe one solution would be to force the use of &str if you want to pass a string.

There is no guessing required, the behaviour is unambiguous. If you do not know what the parameters are, always forceing &var doesn't help you, is it an address of a string or a number?

Very nice, in general for OutputVar +1

Only outputvar?

Cheers.

[nnnik]

What would happen if I have a variable containing the binary data of the string "1234" followed by a null terminator at the beginning?

As you realised, it wouldn't work, that is what I meant by

it would render this

Code: Select all

NumGet(VarString) ;addr := &VarString ;pointer to "abc" ;[quirky, a concession to AHK v1]

useless.

Hmm yeah I see.
I don't quite understand how you can say that the 2 statements are related - I tried really hard.
I envisioned an example. I chose a Hex Editor, this hex editor reads binary data from a file using FileOpen and raw read or FileRead.
Then it uses the variable that the binary data was written to on NumGet.
If the binary data from the file just happened to be

the binary data of the string "1234" followed by a null terminator

then what would happen?
Would it read the data from the file or would it treat it as a pointer?
This kind of problem would render NumGet esentially unuseable. It only gets worse if you imagine data getting send over the internet.
It's not an option

Your statements only concludes that a specific case would cause problems - I'm not aware of the internals but from what I have seen NumPut itself would just die like that.

[Flipeador]

is it an address of a string or a number

I think you have misunderstood me. I mean ... use & only when trying to pass a string, which is what AHK does when the variable contains a string and you simply pass var... The parameters always expect a number, either a memory address or not. This depends on the message, of course.

---

Edit* Basically it is what has been discussed here, and that I am not entirely in agreement with the answer that lexikos has given. They are not functions that a new user whitout previus experience
normally uses, I believe that making the change and improving the documentation would be ideal; there should be no mistakes, and therefore, no need of automatic bound-checking. Well, I seem to be mixing topics and diverting the main one

[jeeswg]

- Ah, I read:
'it contains a string (not a pure number)'
as:
'it contains a string (a string that is not a pure number)'.

- @Flipeador: It amuses me how strongly you word(/image) your opinions, likewise, I thought this idea was terrible:
SendMessage(Msg, wParamType, wParam, lParamType, lParam, WinTitle, ReturnType, Timeout)
Although I like what you say in general.
- I know ironically that I'd be asking for WinTitle to be a 'smart' parameter, but it really should take an hWnd without needing "ahk_id ", and 99% of the time you don't have a window title that starts with a number, and you could do something like "123 " or "123 ahk_class Notepad" if needed. (Perhaps WinTitle should *only* accept an hWnd, but it would be too big of a change to only allow an hWnd.)

- @Helgef: It is *very very* common to obtain a number derived from a string: vNum := "1", in which case '+0' is required. The new behaviour in AHK v2 could break an absolute tonne of scripts. It would force users to be too careful/twitchy when handling string types, draining a lot of energy from the user.
- Generally speaking, a user should be able to pass a number (numeric type) or a string containing a number (string type) interchangeably. It's a fundamental principle. There can be exceptions, like key names in COM objects, but these should be minimal. Otherwise AutoHotkey loses a key part of its convenience, user-friendliness.
- PostMessage/SendMessage do not need to have special support for sending strings, it looks like the best idea is to drop support for strings entirely.
- What do you mean here: myNumbers := x "," y, that's a string, and would not be treated as a number, var+0 wouldn't work.
- NumGet(VarString) wouldn't be useless, it would be a fallback to keep a greater number of older scripts that omit '&' operational.
- What do you mean by 'consistency'? The particular NumXXX and XXXMessage parameters are inconsistent compared to other parameters, right?
- Re. Double/Float, in general, the function itself should do Round() where needed. Also I meant to say that any function that allows "X1 Y1" should also support "X1.0 Y1.0" to avoid the use of Round(). E.g. when people do things like width/2 to centre a window.
- NOOOO! StrGet/StrPut actually works properly at the moment, if anything NumGet/NumPut should work like StrGet/StrPut. That would be the ideal situation.
- You make an interesting point about &var. In theory &var applied to a numeric type wouldn't make sense, therefore the best AHK could do is assume you meant to point to the start of the Int64 where the number is stored.

- @nnnik: I thought about 'the binary data of the string "1234" followed by a null terminator' situation. See the comment about 'fallback', in the response to Helgef. [NumGet(VarString) wouldn't be useless, it would be a fallback to keep a greater number of older scripts that omit '&' operational.]
- The fundamental point is that these functions should only pass string data by using &. Passing a variable to XXXMessage, expecting the address of the string to be passed, very unintuitive. Who does that anyway?

[Flipeador]

I know ironically that I'd be asking for WinTitle to be a 'smart' parameter, but it really should take an hWnd without needing "ahk_id ", and 99% of the time you don't have a window title that starts with a number, and you could do something like "123 " or "123 ahk_class Notepad" if needed. (It would be too big of a change to only allow an hWnd.)

No, no, no, this would make things even more confusing. Truthfully, I would not call this 'smart', but rather ambiguous... differing from Helgef. You should be as explicit as possible and avoid confusion, so anyone who sees your code will know exactly what you are wanting for.

PostMessage/SendMessage do not need to have special support for sending strings, it looks like the best idea is to drop support for strings entirely.

If I understand you correctly, I think I totally agree with this.

You make an interesting point about &var. In theory &var applied to a numeric type wouldn't make sense, therefore the best AHK could do is assume you meant to point to the start of the Int64 where the number is stored.

I refer to this The fundamental point is that these functions should only pass string data by using &. Passing a variable to XXXMessage, expecting the address of the string to be passed, very unintuitive.

I thought this idea was terrible:
SendMessage(Msg, wParamType, wParam, lParamType, lParam, WinTitle, ReturnType, Timeout)

Well... maybe delete wParamType and lParamType, otherwise, I do not see the terrible idea.

---

Edit* I added some things, read again please.

[nnnik]

It is *very very* common to obtain a number derived from a string: vNum := "1", in which case '+0' is required. The new behaviour in AHK v2 could break an absolute tonne of scripts. It would force users to be too careful/twitchy when handling string types, draining a lot of energy from the user.

Could you show me where I ever use it?
And if it is so common can you prove that that is the case?

Some stuff how & is the new syntax and how we should accept this new syntax as our lord and savior

I haven't heard of or seen this change in any way. The & syntax has it's advantages and restrictions like any other syntax.
It has many advantage when it comes to versatility over the normal syntax without & simply because it allows all sorts of data to be accessed even if it wasn't created by AutoHotkey.
The main advantage of the NumPut without the & is saving the & and allowing for automatic variable resizing.

Honestly I don't think that a language like AutoHotkey is a language that is allowed to force people to use the & syntax.

[Flipeador]

Well, as nnnik says, maybe we're trying to make AutoHotkey a language that is not... In my opinion, I would like AHKv2 to take a different perspective, let the user know that it is a pointer, and make & a more 'common' operator. Let the user really know what a string is. But, maybe it's not what lexikos wants... what most people want...

[nnnik]

Well I don't see many interpreted languages work with pointers.
In fact I don't see many modern languages working with pointers in general.
Pointers have become an obsolete construct towards most modern languages.
I don't really see the point in learning them for other languages and if we can avoid it in AHK it's even better.

[derz00]

It's common in AHK for parameters that expect string data, to handle numeric types as strings, and vice versa, and that's a strength of AutoHotkey. Also, introducing greater consistency is an aim and strength of AutoHotkey v2.

That is, rather, an inconsistency of AutoHotkey. In more consistent languages, "str"+0 would raise an error.

did not remotely suspect the cause

It is easy for anyone to miss the real reason for a bug. Usually this skill comes with much time and sometimes training. Therefore, as your post(s) illustrate a few poor debugging methods and, parallel, less training and good experience than other proficient programmers, will make your words of less effect. Just a observation--not an offense.

[Helgef]

I don't quite understand how you can say that the 2 statements are related

In

it would render this

Code: Select all

NumGet(VarString) ;addr := &VarString ;pointer to "abc" ;[quirky, a concession to AHK v1]

useless.

the word it refers to jeeswg's suggestion that

Code: Select all

VarStringNum := "123"

would be interpreted as a number, i.e., NumGet(VarStringNum) ;addr := VarStringNum+0 which means you cannot use

Code: Select all

NumGet(VarString)

for the reasons you pointed out.

---

I think you have misunderstood me. I mean ... use & only when trying to pass a string

No I got you, my point is I might want to pass the address of a number, then I would need to do &var as well, and you would be in false belief that var holds a string. Also, from an implementational (word?) view, it doesn't make sense to construct the variable concept, only to the ask the user to pass &var to built-in functions, when var already knows &var and more.

---

It is *very very* common to obtain a number derived from a string: vNum := "1"

See:

In more consistent languages, "str"+0 would raise an error.

I'm glad you brought it up, if any thing, this should be the case. We should have functions for converting strings to number when needed. (could also be useful to convert from eg int to uint and such). As a side note, at least "quotedString" + 0 actually is an error, but not varContainingString + 0

---

In theory &var applied to a numeric type wouldn't make sense, therefore the best AHK could do is assume you meant to point to the start of the Int64 where the number is stored.

I have no idea what you mean. Me commenting as such on this specific quote doesn't imply I know what you mean about everything else you said.

---

NumGet(VarString) wouldn't be useless, it would be a fallback to keep a greater number of older scripts that omit '&' operational.

So it all comes down to you wanting to make it easier for yourself, making your converter? How would it fallback? I will make an explicit example, a typical scenario where you pass a struct to a function, via dllcall, and want to retrieve some numbers from the struct after the call,

Code: Select all

/*
struct data {
	unsigned int a;
	unsigned int b;
	unsigned int c;
}
*/
varsetcapacity(myDataStruct, 12, 0)
dllcallMyFunc(myDataStruct)
msgbox "regular numget:`n`n" hex(numget(myDataStruct, "uint")) ; :=)
msgbox "jee_numget:`n`n" jee_numget(myDataStruct, "uint") ; :=(

; Side note:
pmyDataStruct := &myDataStruct
msgbox "side note:`n`n" hex(numget(pmyDataStruct, "uint")) ; :=) didn't work in v1 (the quirk)

Jee_Numget(byref x,p*){
	if type(x) = 'string' && x is 'number'
		return numget(x+0,p*)
	return numget(x,p*)
}
dllcallMyFunc(byref d){
	numput(0x00370037, d, 0, "uint") ; eg, 0x00970037 would work with jee_numget
	numput(0x00370037, d, 4, "uint")
	numput(0x00000037, d, 8, "uint")
	return
}
hex(x){
	return format("{:#0.8x}", x)
}

Cheers.

[jeeswg]

- @Flipeador: Re. WinExist parameters. Sometimes I had hotkeys on Open/Save As dialogs, but where the controls differed, all with the same title and class (#32770). So I needed to use the WinText parameter until ahk_exe came along.
- Re.

maybe we're trying to make AutoHotkey a language that is not

You should have more confidence in your arguments. The consensus on this forum is usually for small changes that maintain or simplify functionality, in line with your ideas. By contrast, nnnik says things that are neither right nor wrong, but that usually involve some paradigm shift, and would end up with everything in AutoHotkey being completely different. I would welcome a full report on nnnik's ideas, it's hard to keep track of the proposals.

- @nnnik: You appear to be getting things backwards. I don't think I've ever seen strings used like this in a script:
SendMessage, 0xC, 0, "New Notepad Title" ; 0XC is WM_SETTEXT
The only argument for letting SendMessage do something like this is for 'convenience'. However the real convenience lies in commands like WinSetTitle/ControlSetText.
- If the argument is to be newbie-friendly. Consistency and predictability are the key. Passing numbers one way with success (as numbers), and another way with failure (as strings), in a way that works on all other functions. Not newbie-friendly.
- When people use numbers (stored as strings) they often do so without realising it. Why? Because numbers stored as String/Integer types are interchangeable in AHK v1 for SendMessage. Because it's never been a problem before, I've never looked at other people's scripts to see if they pass numbers stored within strings before. I've done a lot of debugging, and a lot of conversion, looking to see if a variable was defined as a string or integer, not nice.
- Passing numbers as strings is something I've done regularly, particularly when parsing parameter lists.
- I haven't found the automatic variable resizing to be sufficiently useful as an argument, and sometimes I *don't* want it to occur, so it's a disadvantage. I'm fine with doing a VarSetCapacity line. Also, unpredictable behaviour like this led to some bugs in some scripts I had.
- When I see variables without the &, I think, is that the variable's contents or address being passed. That's why I like to see the &, always. I added it in to all of my scripts and libraries.
- I'm very surprised at your objections to the concept of pointers. One of many uses is to store object references when looping through an object hierarchy. How do we solve that?

- @derz00: Re.

That is, rather, an inconsistency of AutoHotkey. In more consistent languages, "str"+0 would raise an error.

- You're using the word 'consistent' to mean 'normal' (perhaps based on your own programming prejudices, something we all have). AutoHotkey is consistent. There were good reasons that AutoHotkey chose this route, maybe AutoHotkey was right.
- As was pointed out, "str"+0 causes an error in AHK v2. Anyhow, both AHK v1 and AHK v2 have some type specification and differentiation functionality, and I'm glad they do, but for most functions it's better to ignore types.

It is easy for anyone to miss the real reason for a bug. Usually this skill comes with much time and sometimes training.

- This and other points read like 'I know every programming language ever, and have experience with every programming language, therefore I can inform you ...'. Which I usually interpret as 'I know Python, and Python does it differently'. I think it's reasonably common in C++, AutoHotkey and other languages, for a bug to occur, and for the reason to be unclear, especially for something that worked in AHK v1, but not in AHK v2 (which is still in alpha by the way). I generally welcome your posts, and of course, if your post was more information-laden, I might be more swayed by the arguments.

- @Helgef: Re.
"quotedString" + 0 actually is an error, but not varContainingString + 0
The handling of object keys in AutoHotkey would collapse without this. I would not be against functions like MakeString or MakeNum, although "" and +0 are nicely short.
- Re. 'fallback', in my view, NumGet/NumPut should accept either Addr or &Var. If you have 'Var', when what is meant is '&Var', NumGet/NumPut could check whether Var is a numeric or string type that contains a number, if not, it could pass its address (to allow older scripts to remain functional in AHK v2).
- Very nice, I like your Jee_Numget function muchly.

[nnnik]

It is consistent however you don't draw the lines between numbers and text but between string types and integer types.
Also I'm not refering to SendMessage in any way - I couldn't care less about it tbh.
I think we talked about why NumGet( var ) would be impossible if it would switch meanings depending on the content - unlike the content type.

Also the transition from a language that does use pointers to one that doesn't will take a long time and is a goal for the very far future and not very important.
However when we have a simple choice like this a simple choice against it will help going in the right direction.

[Helgef]

The handling of object keys in AutoHotkey would collapse without this

You are incorrect .

If you have 'Var', when what is meant is '&Var', NumGet/NumPut could check whether Var is a numeric or string type that contains a number, if not, it could pass its address (to allow older scripts to remain functional in AHK v2).

Did you look at my example? It (jee_numget) does what you describe*, and it doesn't work. *I guess I could misunderstand your wording.

Cheers.

[jeeswg]

- Well well smart people, what about when you do InputBox. You will then use that number in SendMessage. But wait, we must convert it to a numeric type otherwise it will send the address of vInput and not it's value. Oh dear. A new source of bugs no doubt.

Code: Select all

vInput := InputBox(,,, 1)
MsgBox(Type(vInput)) ;String
vInput := InputBox(,,, "1")
MsgBox(Type(vInput)) ;String

- AFAICS I don't want SendMessage to interpret Var (where Var is a string) as &Var, I never need that, and using &Var and VarSetCapacity is fine. In fact, I'm not aware of anyone using it this way. It's very common for people to pass numbers (as strings) to SendMessage, people have been able to do this with no problem since AutoHotkey began. The InputBox scenario is an example of this.

- I'm not thrilled with how NumGet/NumPut/oFile.RawRead/oFile.RawWrite work, but I can live with it. The new SendMessage behaviour could be a major headache for users generally, even for people who think it won't affect them (e.g. in a library you use).
- Re. NumGet/NumPut, one argument was that if you pass the var ByRef, AutoHotkey can check the variable, although I don't want/need that special checking. But you could still have that checking if desired, there could be special handling for variables when & is seen.

- '+0' to convert var (string) to var (numeric) is good. AutoHotkey v2 does this, which I find fair:

Code: Select all

var := "1"
;MsgBox("1" + 1) ;(error)
MsgBox(1 + "1") ;2
MsgBox(var + 1) ;2
MsgBox(1 + var) ;2

- There are further examples here:
string hacks - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 86#p161886
- [EDIT:] And here:
Sending email works in test script but not in large script - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 55#p208655

- @Helgef: You say I'm incorrect, admittedly it was a bit of a generalisation, however, AutoHotkey does need a way to change the type but maintain the content (and one way is to use +0 or ""). Let's say you wanted to refer to a folder/file when using an Explorer window object, '10' could be a folder called '10' (a string), or the 9th item in a 0-based list (a number). So you might want to force either a string or number. What's your solution for this?