Is there a possibility to detect if a Popup is activated or deactivated? Such as the Window-events Window.Activated and Window.Deactivated.
I want to detect if the user has clicked outside of the popup (I can not use the Popup.StaysOpen=false option).
Update
I have forgotten to remark, that I dont want to add any handler or code to a parent-control of the popup.
Capture mouse clicks for your main application window (MousePreview type event) and for popup - when user clicks into popup, main window event doesn't fire and vice versa.
Sounds like you could just use the Popup.Opened and Popup.Closed events.
Related
I am creating an windows form application and I want to know how to check when the maximize button is clicked.
Can someone please help me?
The re-size even handler is not detecting when the form is maximized or normal.
And I don't see any event handler for the maximize button on the control box.
Or is there any script in windows form that constantly run over and over.
You need to hook up into ClientSizeChanged event. In this event you can monitor WindowState.
To show a messagebox when window is maximized, add following code into forms ClientSizeChanged event:
If(WindowState == FormWindowState.Maximized)
{
MessageBox.Show("Maximized")
}
Hi I have main form in which I am displaying user controls like ManageDepartment. I have few buttons like RESET in main form.
I want to have event in ManageDepartment to reset controls.
When user clicks on Reset Button on main form, the button should call the reset event on displayed control i.e. ManageDepartment
Can any one suggest me how can I achieve this?
If this is duplicate question, please direct me to original question.
You don't call an event. If the user control has a Reset event then that event would get raised by that control.
It sounds more like what you need is a Reset method on the user control. You would handle the Click event of the Button on the form and call the Reset method of the control. In that method you would do as required to reset the control, e.g. call Clear on each TextBox.
I have a vb.net WPF application that has a modal dialog window that has an "Ok", "Cancel" and "Apply" button. The "Apply" button does the same work as the "Ok" button but when the "Apply" is clicked the modal dialog box should stay open. Normally I like to call ShowDialog to display a modal but that results in the modal closing when it returns so I can't use that with a modal the has an "Apply" button. Can someone provide me with an easy work around? The alternative is to display the modal dialog window using .Show but in this case I'm not sure how to properly return values when the user clicks on one of the buttons.
Thanks!
The closing of the dialog is handled by the code that executes when the user clicks the OK button. So you could move all of that code to a function with the exception of the Close() call and the call that sets the DialogResult. Then you can call that function from both the OK handler (or ICommand) and the Apply handler (or ICommand). Then just don't call Close() from the Apply button.
Dialogs with an "Apply" button aren't generally modal, but one approach would be to instantiate your dialog and supply it with a ViewModel via DataContext where your dialog data can be shared between the function calling the dialog and and the dialog itself. Then, wire your "Apply" button to be handled by the modal dialog and whatever ViewModel code you have, perhaps via an ICommand binding.
Let us know if a sample would be useful.
I have a WPF user control with some buttons inside it. I need to intimate the main window when button click happens inside the WPF control. The main window has to initiate some actions upon receiving this message from the button click event inside the user control.
You can add a Click handler to all your Buttons, and in that Click handler, call the UserControl's OnClick method to generate a click event coming from the user control.
Check out Commands:
http://msdn.microsoft.com/en-us/library/ms752308.aspx
I have a button which launches a "modal dialog" - it just creates a transparent grid covering everything, with the "dialog" created on top of that.
However I have a strange issue - if I double/triple click the button really fast (or add some delay in the event code), the button click event is executed multiple times, creating multiple overlapping modal dialogs. If the first action in my event is to disable the button (IsEnabled=false) it seems to prevent this.
My guess is that Silverlight is being multithreaded with input - it is not only recording the second click in another thread (while the button's click event is running), but it is jumping the gun by evaluating which control should be the target before the previous event has finished executing. Even though that event alters what control is at those mouse coordinates, it doesn't matter.
Does anyone know anything about this behavoir, or a way around it? If I have something like a save window, where the user clicks a save button, a blocking grid ("Saving...") is placed up while it saves, and then the whole "window" is closed, I'd like to avoid the user being able to queue up multiple save event clicks (this could lead to unpredictable program behavoir).
If you've ever worked with WinForms or WPF, this is expected behavior. Your button is broadcasting its Click event until your modal dialog covers it up. Unfortunately, there is some amount of time between your first click and when the modal dialog covers the button which allows multiple clicks to the original button.
You have two solution choices:
Disable the button after the first click and then re-enable after the modal dialog returns. You've already mentioned that this works.
Write code in the Event Handler of the button to determine if a modal dialog is already being displayed. This way, you're putting the responsibility in one location rather than splitting it up (disabling and re-enabling the button). This would be my preferred solution.
I think what you're seeing is the behaviour of Silverlight's routed events.
You can set the Handled property of the event arguments to true to prevent the event from bubbling.