Page 1 of 1

1.1.31.00 Listview G-Label "e" no longer works

Posted: 18 Oct 2019, 11:42
by afe
Hello,
When I updated to v1.1.31.00, I found that Listview g-Label "e" no longer works.

When I finish editing the first field of a row, I can't use LV_GetText(OutputVar, A_EventInfo) to get the new value.

Edit:
else if ( A_GuiEvent == "e" ) will not be executed

This is a shorthand script, but it works fine:

Code: Select all

Gui, Add, ListView,r10 w200 -ReadOnly AltSubmit glv vlv, Title|
LV_Add(, 1)
Gui, Show
return

lv()
{
	Gui, +OwnDialogs
	Global name

	if A_EventInfo
	{
		if ( A_GuiEvent = "Normal" || A_GuiEvent = "RightClick" )
			LV_GetText(name, A_EventInfo)
		else if ( A_GuiEvent == "e" )
		{
			MsgBox, % A_GuiEvent
			LV_GetText(newname, A_EventInfo)
			if ( newname != name )
				msgbox % newname
		}
	}
	return
}
e (lowercase E): The user has finished editing the first field of a row (the user may edit it only when the ListView has -ReadOnly in its options). The variable A_EventInfo contains the row number.

Re: 1.1.31.00 Listview G-Label "e" bug

Posted: 18 Oct 2019, 19:06
by lexikos
Please post a complete and functioning (on v1.1.30 but not v1.1.31) example.

Re: 1.1.31.00 Listview G-Label "e" bug

Posted: 19 Oct 2019, 03:51
by afe
Since my script is associated with too much content, I have abbreviated it, but the implementation is the same. But what is confusing is that this shorthand script works fine.
The original script runs on v1.1.30.3 and v1.1.31.00 respectively, and the result is normal and one is not. I found that in the original script, v1.1.31.00 does not execute the else if ( A_GuiEvent == "e" ) section. But I can't reproduce it with a shorthand script, which is confusing.

I can't find the cause of the problem. The same script, without any modifications, works fine on one version and not on the other. This script was written when I was still using v1.1.30.3 and did not use the new features of v1.1.31.00, such as Switch.

But if ( A_GuiEvent = "Normal" || A_GuiEvent = "RightClick" ) can be executed.

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 19 Oct 2019, 07:44
by lexikos
I assume it is related to this:
Fixed menu and GUI events causing CPU-maxing loops in some cases. Specifically, when a modal message loop is running and the script is uninterruptible, menu and GUI event messages were repeatedly re-posted. These are now discarded, as they can't be handled or kept in the queue. This is consistent with hotkeys, etc.
If so, your larger script must have:
  • something that triggers a modal message loop (probably the ListView itself)
  • an uninterruptible thread, such as OnExit or a thread calling Critical
If it worked before, it must have been re-posting the message (perhaps multiple times), but eventually (perhaps very quickly) cancelling out one of the above conditions; i.e. exiting the modal message loop, making the uninterruptible thread interruptible, or finishing the thread.

The workaround is probably to avoid making any threads uninterruptible while the user may be interacting with the ListView.

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 19 Oct 2019, 09:41
by afe
Thank you for your analysis.

My code is the same as this example implementation, except that the former has a lot Menus and right-click context menus and so on. This example works fine on v0.1.31.00, so there is no problem with this g-Label method. I will try to simplify my code again to see if there are any errors I have not found. Thank you!


Edit:
When I removed most of the code and left only a small part, the program worked fine on the latest version.

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 19 Oct 2019, 13:27
by afe
I found out where the problem is.
There is also a ~LButton:: hotkey in my code, and I need Sleep, 1 to capture the current Focus. It is because of this Sleep that the code is not implemented as expected in v0.1.31.00.

But I don't understand the exact reason.

I need to use Sleep, 1 to determine that the cursor has moved from one control to another. I haven't found any other way to replace Sleep.
Although there are other ways to modify the first Column of the ListView, this method is more convenient. If both can be used at the same time, it will be expected.



Re-edit:

Code: Select all

Gui, +HwndGuihwnd
Gui, Add, Edit,w200 vedit, Default
Gui, Add, ListView,r10 w200 -ReadOnly glv vlv, Title|
LV_Add(, 1)
Gui, Show
return

lv:
	if ( A_GuiEvent == "e" )
		MsgBox, % A_GuiEvent			; Unable to be executed
return

#if ( WinActive("ahk_id" . Guihwnd) )
{
	~LButton::
	~RButton::

	GuiControlGet, focus, FocusV
	if ( focus = "edit" )
	{
		sleep, 1				; The problem is here

		GuiControlGet, focus, FocusV
		if ( focus != "edit" )
			GuiControl, Text, edit, Default
	}
	else
	{
		sleep, 1				; The problem is here

		GuiControlGet, focus, FocusV
		if ( focus = "edit" )
			GuiControl, Text, edit
	}
	return
}

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 19 Oct 2019, 16:45
by lexikos
Even after correcting the comment flag in your example, I am unable to see any problem.

What do you mean by "capture the current focus"? Why is it necessary to use a mouse hotkey?

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 20 Oct 2019, 02:48
by afe
I updated the code. In this example, when modifying the first column of the ListView, MsgBox, % A_GuiEvent will not be executed in version 0.1.31.00. But the previous version can.

Sleep here is to get the current cursor on which control. When the mouse clicks outside of Edit, Edit will restore the default value. Otherwise, the Edit is cleared.

Re: 1.1.31.00 Listview G-Label "e" no longer works

Posted: 20 Oct 2019, 16:45
by guest3456
the only way i can trigger an edit of the first row in the listview is to click it once, wait, and then click it again, wait, and then it becomes editable

on 1.1.31 it is weird, sometimes the msgbox triggers and other times not. I can't figure out anything repeatable

edit:

ok, so if you edit the listview item, and then click away to either 1. the Default textbox, or 2. the listview Titlebar, then the msgbox always triggers

but if you click away in the same listview row, or lower down in the listview, its hit or miss whether or not the msgbox will fire