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

Unexpected UI behavior after closing OpenFileDialog #3986

Open
SparkyTD opened this issue May 24, 2020 · 6 comments
Open

Unexpected UI behavior after closing OpenFileDialog #3986

SparkyTD opened this issue May 24, 2020 · 6 comments

Comments

@SparkyTD
Copy link

I have created a TextBlock that shows an OpenFileDialog on the PointerPressed event. If I close the dialog, the entire window will become sensitive to that PointerPressed event which means that no matter where I click on the window, the dialog keeps opening.

I've tried setting the Cursor property of the TextBlock to Hand. Before clicking on it, the cursor only changes when I hover over it as expected. But after opening and closing the OFD, the entire window has the Hand cursor.

It looks like the OFD somehow confuses the hit testing code so it thinks that the entire window is that one label.

This bug affects Windows, I haven't been able to reproduce it on Linux (Manjaro) and I have no access to a Mac.

Here you can download a very simple project that demonstrated the bug. It only contains a window with a red label on the center. Click on the label then close the OFD (you don't have to select a file, but you can if you want to). Now no matter where you click on the window, the dialog will pop up.

dotNet: 3.1.2
Avalonia: 0.9.999-cibuild0007716-beta
OS: Windows 10 x64

@grokys grokys added the bug label May 25, 2020
@grokys
Copy link
Member

grokys commented May 25, 2020

Can repro, confirmed that it's still a problem on master.

@grokys
Copy link
Member

grokys commented May 25, 2020

This happens because a mouse down captures the pointer and then the dialog is shown, meaning that the main window doesn't receive the pointer up message to release the capture.

WPF handles this by handling the WM_CANCEL message

Not sure why it's not reproing on linux, not had chance to check yet.

I guess at least on windows at least we should handle WM_CANCELMODE?

@grokys grokys added this to Priority in 0.10.0 May 25, 2020
@danwalmsley
Copy link
Member

Can also reproduce with Panel.PointerPressed += WindowState=Minimized

@SparkyTD
Copy link
Author

SparkyTD commented May 25, 2020

In my project I am subclassing the window so I can handle that message. Is there a way I could manually release mouse capture on WM_CANCELMODE before this gets fixed?

EDIT: I didn't have to handle any low level stuff, I just called args.Pointer.Capture(null); on the PointerPressed event and that seems to fix it.

@grokys
Copy link
Member

grokys commented May 26, 2020

@SparkyTD glad you figured out the hack. That's what I was going to suggest.

@xingxing21
Copy link

I have a Button to open the OpenFileDialog.
Also, this Button has the ToolTip.
In order to open that dialog if I move the Pointer to the Button then show this tooltip.
And this tooltip doesn't hide after pressing the button.
Only the one hide after closed that dialog.

AvaloniaUI version: 0.9.12
OS version: macOS Catalina

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
0.10.0
  
Punt to vNext
Development

No branches or pull requests

6 participants