Potential Bug in elm.invoke?

[netdude78]

Hi there.  I seem to have found a bug, but I can't point to the line of code yet.  I'm going to try to build Au from source so I can step through the internal functions in my debugger.  This seems to only happen when there's DPI scaling... if my monitor is set 1:1 it works fine.

C# code:

Copy

var w = wnd.find(1, "Signal Paths", "Afx:*");
var c = w.Child(1, id: 59648); // SysListView32
c.Activate();

var activeSignal = elm.focused();
print.it(activeSignal.Name);
activeSignal.Invoke();


The is being run against a listview with many items.  I select an item then run the script above to "start" at the selected item.  The debug output prints the proper signal name..... but if DPI scaling is enabled (I usually run my monitors 4k with 150% scaling), the Invoke() method opens the properties window for an element about 5-6 items higher in the listView.

It's not so high priority because I can just run my monitors without scaling in 1080p mode...

[Gintaras]

It is a bug in that control. Invoke() just asks it to do something. When DPI-related anomalies happen, try to find/get the element with flag UIA. In this case there is no flag, but a bool parameter. Try

Code:

Copy      Help

elm.focused(true);

-----

This probably isn't the reason, but child windows cannot be activated and therefore c.Activate() activates w instead. You may want to c.Focus().

[Gintaras]

Anyway, I'll try to make it work better in high DPI mode.

[netdude78]

I wouldn't be a bit surprised.  This app was created long before DPI scaling

[Gintaras]

It's probably a Windows bug. Standard listview controls (

Code:

Copy      Help

SysListView32

) have this bug.

But part of the problem is in elm.focused. Unlike other elm find/get functions, it works like with flag NotInProc. In next program version it will work like other functions, and the problem should go away.

Now I can't release the next version, it's unfinished. But elm.focused(true) should work well in current version, I guess.