Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Known issus: Popup with “StaysOpen=false” steals PreviewMouseDown event #2166

Open
lindexi opened this issue Nov 8, 2019 · 1 comment

Comments

@lindexi
Copy link
Contributor

@lindexi lindexi commented Nov 8, 2019

When we set the Popup with StaysOpen=false that will steals the PreviewMouseDown and LeftMouseButtonDown etc event. And this is a known issus. Do we plan to break this behavior? I think it is difficult to understand.

Behavior:

We click the button to open the popup, and then we click a checkbox. We can find the popup close and the checkbox be checked but the PreviewMouseDown event in checkbox will not fire.

Popup with “StaysOpen=false” steals PreviewMouseDown event

Link: https://stackoverflow.com/questions/29889620/popup-with-staysopen-false-steals-leftmousebuttondown-event

The demo: https://github.com/lindexi/lindexi_gd/tree/46e813ad18655df1653e1fb9de6c238f91171443/NayfarwehelaFebeejochar

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Nov 8, 2019

I think this is part of a more general problem of the WPF input system where you can't easily process an event, update the visual/logical tree, and then re-raise the event for reprocessing.

This has come up repeatedly for me when programming controls where you have a "readonly" presentation by default but can click to enter an edit mode. Most known in data grids where you click into a cell for editing it and it switches out controls, but it also comes up repeatedly with custom controls (e.g. I recently built a calendar-like control and when you click on an item to get an inplace editor). When you e.g. have a checkbox you want those to be toggled after switching out presentations, so the user doesn't have to click twice. However when you click the "readonly" presentation focus changes and it switches out templates, the click event gets consumed without the ability for reprocessing it against the editor control from the new template.

The workaround is of course to manually pass the focus triggering event over to the switched-out template in case it wants to process it, but that leads to the problem that you now have to re-build a whole infrastructure for event handling and can't just use the already existing controls and their handling of events. Also note that this scenario not only exists for mouse inputs but also for keyboard inputs, sometimes I don't want to activate the edit template on focus but only when I start typing, in the current situation that consumes the first keystroke and I have to add a huge workaround to process keyboard input that isn't flowing through the normal WPF input event pipeline.

So coming back to this issue, while it might be certainly possible to implement a workaround where Popup doesn't consume the PreviewMouseDown event I'd like to see a general solution that I can use in my own controls. I think the best solution would be to add infrastructure and the ability to reprocess an event. I don't want this to be the default behavior, just the ability to do it in code when its required.

Perhaps this could even solve the obvious question "do we want to break the behavior" on the Popup class - just add a ConsumeClosingInput property (or however you want to name it) to make the behavior configurable, so you can set it as appropriate. ([edit] It probably needs to be ConsumeClosingMouseInput though, depending on how you're using the popup you may or may not want to reprocess input when closing the popup via escape key.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.