EVT_TREE_STATE_IMAGE_CLICK() and the second monitor Topic is solved

[Alan Stewart]

wxWidgets 3.0.2, Windows

I have implemented a wxPanel, displayed within a wxPropertySheetDialog, containing several controls, including a wxTreeCtrl. Everything works fine when the dialog is displayed on the main monitor, and also on the second monitor, except for one thing that I have found so far. EVT_TREE_STATE_IMAGE_CLICK() is not fired when the user clicks on an item's state image. WTH?

TIA for any ideas/leads/solutions.

[doublemax]

Do you see the same problem in the "treectrl" sample?

If yes:
Which Windows version?
What's the display scaling setting for both displays?
Is your app marked as "DPI aware" through the manifest?

[Alan Stewart]

Thanks, Max. I haven't done any wxWidgets development in a few years, so I'm no longer setup to build wx or the samples. It'll take a while.

Meanwhile, this is a plugin to a third party host application. A customer reported the issue to us, I currently don't have any information about his setup. I've reproduced in-house with a setup using two identical monitors running at the same resolution and Windows 7.

[ONEEYEMAN]

Hi,
Did you try the sample or you plugin?

Thank you.

[Alan Stewart]

Still working on building treectrl.

I just learned a weird thing. My development environment is VMware running on a Mac host. When the VM is hosted from the main (left) Mac monitor I can't reproduce the issue. Only when my VM is hosted on the right monitor does the issue occur.

[Alan Stewart]

I'm also still waiting on my tech support people to get more info from our customer about their system.

But I have theory base on what I just discovered about the left-right relationship. I'm guessing Windows or wx has a display coordinate system where the origin is on the primary monitor? Then when the primary monitor is to the right of the secondary monitor that secondary monitor is in the negative X portion of the display coordinate system. Someone can't handle negative X coordinates.

[PB]

I'm guessing Windows or wx has a display coordinate system where the origin is on the primary monitor?

This is true, e.g. here, my primary display i.e., wxDisplay(0) / DISPLAY1, is right to my secondary one and check the coordinates rows. You can also use the bundled display sample.

No idea whether this is the source of your problems though.

[Alan Stewart]

I now have a build of treectrl.exe. It has the same behavior as my code. When the secondary monitor is to the left of the primary monitor and the dialog is on the secondary monitor the tree control item checkboxes do not work.

[Alan Stewart]

And after debugging into I see the same thing that I found with my code: EVT_TREE_STATE_IMAGE_CLICK() is never called.

[doublemax]

Someone can't handle negative X coordinates.

Interesting theory. But i couldn't reproduce this in the "treectrl" sample. This is especially unlikely since wxTreeCtrl is a native control. Or are you using the generic version by any chance?

[PB]

But i couldn't reproduce this in the "treectrl" sample.

Neither could I, using wxWidgets 3.04 on Windows 10.0.17763. When I click the checkbox of a selected item, the item state change gets logged and the checkbox toggled, regardless of a monitor on which the sample is. My primary screen has a high DPI, the secondary does not (unlike v3.1, wxWidgets 3.0 are by default process-DPI aware).

[ONEEYEMAN]

Hi,
Another VM oddity?
Unless the OP is trying to use a generic version...

Thank you.

[Alan Stewart]

I'm using the 3.0.2 sources delivered except for upgrading the sample solution and project files to vc10. The source shows USE_GENERIC_TREECTRL being disabled.

[PB]

I'm using the 3.0.2 sources

wxWidgets 3.02 was released in October 2014.

This commit which may be of relevance here is from January 2015:
https://github.com/wxWidgets/wxWidgets/ ... 4070b00085

[Alan Stewart]

Good news! I downloaded 3.0.4. The issue does not happen with that version.