Undocumented behaviour of Edit control's gLabel

Report problems with documented functionality
pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Undocumented behaviour of Edit control's gLabel

23 Sep 2017, 18:26

An Edit control's gLabel fires on control creation if attached to an UpDown control

This issue was reported back in 2013 here, but doesn't seem to have been addressed, so I am nagging you again here to fix it. Why? Because it causes noobs like me to pull their hair out for hours on end wondering why their program is doing something completely bizarre which turns out to be a gLabel firing without any documented reason whatsoever. How are noobs like me supposed to navigate this? Am I supposed to put a message box or sound effect on every single gLabel just to check it's not firing at any other time besides when the documentation says? What other things should I be doing to anticipate omissions in the documentation?

Code: Select all

#SingleInstance Force
Gui, New 
Gui, Add, Edit, vEdit gEdit 
Gui, Add, UpDown, vUpDown gUpDown
Sleep 500  ;to show it's happening on control creation not on Gui,Show
Gui,Show,w200 h35
return

Edit:
msgbox Edit is firing
return

UpDown:
msgbox UpDown is firing
return
The solution as the old forum post says is to add the gLabels after creating of the control, which fixes the issue.

Code: Select all

#SingleInstance Force
Gui, New 
Gui, Add, Edit, vEdit
Gui, Add, UpDown, vUpDown
Sleep 500
GuiControl, +gEdit, Edit 
GuiControl, +gUpdown, UpDown
Gui,Show,w200 h35
return

Edit:
msgbox Edit is firin'
return

UpDown:
msgbox UpDown is firin'
return
And yes I do realise it's "not a bug" , but more of a "problem with documented functionality".

Anticipated response: the script "changes the contents of the control" on control creation, which is when the documentation says the gLabel will fire.

Response: then please make it clear in the documentation that the contents of the control are being changed on creation, because there is no reason why any reasonable person would assume this would happen. N.B the act of creating something doesn't entail one of its properties has changed; there is no difference between a red apple that doesn't exist and a green apple that doesn't exist. The apple only has a property of redness once it already exists.
Last edited by pneumatic on 28 Sep 2017, 21:09, edited 2 times in total.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 01:25

Should we just add the line,
"Controls gLabel might fire at any random given time when anything totally unrelated happens, due to the way windows works. Checking whether this is a meaningful g-Label firing or not is up to you"
or how exactly do you mean this?
Recommends AHK Studio
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 03:25

pneumatic wrote:An Edit control's gLabel fires on control creation if attached to an UpDown control
should be
An Edit control's gLabel is triggered when it is attached to an UpDown control afterwards because its contents is set to the current value of the UpDown.
IMO, that's neither bizarre nor undocumented. Looking at your GUI you can see that the initial empty Edit has been set to 0, i.e. it has been changed. It's not surprising that the gLabel is called in this case. You get the same effect with

Code: Select all

...
Gui, Add, Edit, vEdit gEdit
GuiControl, , Edit, 0
...
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 11:18

More documentation is usually better than less, so I don't see how it can hurt to add a note like this

just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 15:24

pneumatic wrote:Response: then please make it clear in the documentation that the contents of the control are being changed on creation, ...
nnnik wrote:Controls gLabel might fire at any random given time when anything totally unrelated happens, due to the way windows works. Checking whether this is a meaningful g-Label firing or not is up to you
guest3456 wrote:More documentation is usually better than less, so I don't see how it can hurt to add a note like this
Because it's not true.
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 18:28

just me wrote:Because it's not true.
Then put whatever is true.

"Attaching an UpDown control to an Edit control will cause the Edit control's contents to be changed, which will also cause the Edit control's g-label to trigger"

pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Re: Bizarre, undocumented behaviour of Edit control's gLabel

24 Sep 2017, 20:31

nnnik wrote:Should we just add the line,
"Controls gLabel might fire at any random given time when anything totally unrelated happens, due to the way windows works.
I was under the impression AHK is supposed to be an API that translates my commands into "the way windows works".
just me wrote:[Looking at your GUI you can see that the initial empty Edit has been set to 0, i.e. it has been changed.
Creating the Edit control with an initial value of 0 still triggers it though. I remember reading in another thread a post by SKAN I think it was describing that it was due to a windows message being sent on control creation. I think it's just a quirk of windows and would be nice if that quirk was mentioned in the documentation somewhere. A quirk/bug in windows behaviour = a quirk/bug/undocumented AHK behaviour = a bug in my AHK script :lolno:
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

25 Sep 2017, 03:39

There's no quirk at all. But if you think it might be helpful, guest3456's suggestion could be added to the docs.
pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Re: Bizarre, undocumented behaviour of Edit control's gLabel

25 Sep 2017, 19:03

just me wrote:There's no quirk at all.
I presume Windows has some good reason for sending a message of "controls contents have changed" on creation (even though they haven't in the case of Edit=0 and UpDown=0). If there is a good reason, then ok fair enough, it's not a quirk with Windows, but it's still a quirk of AHK which doesn't mention it. I hope you can appreciate just how disastrous it can be to have a function occurring for no reason in the middle of a program! In my case I'm writing to the GPU LUT (SetDeviceGammaRamp) and user opens GUI triggering gEdit which loads a different LUT causing the display colours to be wrong. Very hard to detect when the display colours are only "a little bit wrong" and nothing else to tell me the gEdit fired. I feel lucky I found the cause, but others may not be so lucky. I will say this though: finding bugs seems to be a core skill of programming, so maybe I should be less critical here. But! AHK is meant to be a kind of noob friendly language, so maybe less emphasis on bug finding.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

26 Sep 2017, 03:00

A) The content actually changes and it might be neccessary for others to get that info - just because it was a bug in your case doesn't mean it will be a bug in every case.
B) If AutoHotkey wanted to go against the API, it is meant to run, in we would need 10 times the developers we have now. And since that isn't the case AHK will remain as it is.
C) What you are doing is obviously not noob friendly in any language, since you already try to use advanced concepts. AHK is noob friendly for Windows Manipulation and sending Keystrokes afterwards it actually isn't noob-friendly at all anymore.
Recommends AHK Studio
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

26 Sep 2017, 03:49

MS Windows 'common controls' are complete child windows providing their own window procedures which start to process control related events immediately after the control is created. They are documented in the Control Library.

Code: Select all

Gui, Add, Edit, vEdit gEdit
creates an Edit control without calling the Edit's g-label 'on creation', even if you assign a value to the control.

Code: Select all

Gui, Add, UpDown, vUpDown gUpDown
creates an UpDown control without calling the UpDown's g-label 'on creation', even if you assign a value to the control.

So none of the g-labels is called when the associated control is created.

But because you used the default options when creating the UpDown
  • The UpDown will snap the previously created Edit as its 'buddy control' and immediately synchronize the Edit's contents with its own.
  • This is done by sending a WM_SETTEXT message to the Edit which replaces the current contents of the Edit.
  • This causes single-line Edit controls to notify the parent window about the change by an EN_CHANGE notification and the g-label is triggered. The Edit does not compare the previous and the new contents to detect a 'real' change.
For Edit controls the documentation already says:
A g-label such as gMySubroutine may be listed in the control's options. This would cause the MySubroutine label to be launched automatically whenever the user or the script changes the contents of the control.
If you attach an UpDown to an Edit you want the Updown to change the Edit, so it's clear that the script (in this case a control created by the script) might change the Edit. You expected this won't happen when the UpDown is created. What's your reason for this expectation? From my own personal experience, every programmer relying on own expectations will run into massive problems sooner or later.
pneumatic wrote:In my case I'm writing to the GPU LUT (SetDeviceGammaRamp) and user opens GUI triggering gEdit which loads a different LUT causing the display colours to be wrong.
If so, the default value of the UpDown must be wrong respectively should be set to a value which doesn't change the LUT.

AHK is noob-friendly, especially when used for noobish tasks in a noobish way. You will not find many other languages allowing you to create a GUI with event handling with such a few lines of code. But I agree with nnnik, I don't think that your project can be called a task for a noob. And even the 'noob-friendliest' scripting language cannot prevent errors and wrong expectations.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

26 Sep 2017, 04:16

just me wrote:From my own personal experience, every programmer relying on own expectations will run into massive problems sooner or later.
I think what you meant to say here is that, every programmer, that sololy relies on his expectation from a few cases, to be correct for every case is going to have to face problems when a special case arises.
Your sentence basically says that every programmer will run into bigger problems sooner or later, since the application of any kind of knowledge comes down to relying on own expectations.
Recommends AHK Studio
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

26 Sep 2017, 08:20

Knowledge is gained through experience, not expectations.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Bizarre, undocumented behaviour of Edit control's gLabel

26 Sep 2017, 11:02

just me wrote:Knowledge is gained through experience, not expectations.
I never said otherwise. But experience is nothing but matching up your expectations with reality.
Recommends AHK Studio
pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Re: Bizarre, undocumented behaviour of Edit control's gLabel

27 Sep 2017, 05:59

Even the workaround of adding gLabels afterwards is STILL not good enough, because putting new contents into the control with GuiControl causes the gLabel to fire, and there doesn't seem to be any way of preventing it. You may not think it's important to update a control without triggering glabel, but in my script it is absolutely critical. Maybe it's not even possible to fix it in the AHK source code, because there may be no way to tell apart a legitimate EN_CHANGE/WM_SETTEXT from an annoying one.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Bizarre, undocumented behaviour of Edit control's gLabel

27 Sep 2017, 06:17

You may not think it's important to update a control without triggering glabel, but in my script it is absolutely critical.
@ pneumatic, then handle it, you can turn off or on the glabel as you please. Or if you find it more convenient, define a variable which causes the routine to return if set to (eg) true,

Code: Select all

changeMyControl:
	doNotTriggerMyLabel:=true
	;...
	doNotTriggerMyLabel:=false
return		
mylabel:
	if doNotTriggerMyLabel
		return
	; ...
return
Cheers.
pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Re: Bizarre, undocumented behaviour of Edit control's gLabel

27 Sep 2017, 16:47

Helgef wrote:define a variable which causes the routine to return if set to (eg) true
I don't think that would work reliably enough for me because the EN_CHANGE/WM_SETTEXT event is happening in the background in its own thread according to its own timing and can't be guaranteed to have finished before putting the "dont do gsub" var back. While I was debugging this problem out of my script I found that about a hundred or so lines of code could be executed after adding the control before the EN_CHANGE/WM_SETTEXT event would occur (and it would interrupt critical as well). So I would have to set the "dont do gsub" var, then GuiControl, and then just guess a safe amount of time before setting the "do gsub" var back. I mean sure, you could sleep for a longer time or something safe to give it time, but it's still a dodgy solution that I wouldn't want to use.
Helgef wrote:turn off or on the glabel as you please
This could work, but it would need rigorous testing to ensure that EN_CHANGE/WM_SETTEXT is exactly mirroring the on/off state of the glabel. Thanks!
pneumatic
Posts: 338
Joined: 05 Dec 2016, 01:51

Re: Bizarre, undocumented behaviour of Edit control's gLabel

27 Sep 2017, 21:54

Yes, the variable method doesn't work, but the -g method seems to work. -g must actually be turning off the associated WM altogether , because if not and it's simply ignoring the WM, then +g should be executing before the WM arrives, as per the case with variable method. I hope it's not just a luck of timing causing it to happen this way, because I need to be 100% certain it's not going to fire.

Code: Select all

#SingleInstance Force
Gui, New 
Gui, Add, Edit, vEdit
Gui, Add, UpDown, vUpDown
GuiControl, +gEdit, Edit 
GuiControl, +gUpDown, UpDown
Gui,Show,w200 h35


sleep 500
dont := 1
GuiControl,,Edit, 123
dont := 0


sleep 500
GuiControl, -g, Edit
GuiControl,,Edit, 456
GuiControl, +gEdit, Edit
return


Edit:	
	If (dont)
		return
	Else
		msgbox Edit is firing
return

UpDown:
	If (dont)
		return
	Else
		msgbox UpDown is firing
return
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Undocumented behaviour of Edit control's gLabel

28 Sep 2017, 01:58

Both methods dont 'turn off' any message. They just try to cause the script to ignore the message in different ways. Can you provide a simplified example about what you do within the lables related to the involved controls? There might be other options to work around your issues.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: Undocumented behaviour of Edit control's gLabel

28 Sep 2017, 02:15

try,

Code: Select all

sleep,-1
dont:=false
sleep,-1 wrote:Sleep -1: A delay of -1 does not sleep but instead makes the script immediately check its message queue. This can be used to force any pending interruptions to occur at a specific place rather than somewhere more random.
sleep

Return to “Bug Reports”

Who is online

Users browsing this forum: niCode and 35 guests