Is there a way to start off showing a dialog modally, but then instead of hiding it, to keep it visible while changing it to a non-modal dialog?
I want to show a dialog, blocking the method that shows the dialog. Then when the user clicks the 'Finish' button on the dialog I want:
The dialog to remain visible.
Control to return to the method that showed the dialog.
I've achieved this result by running the dialog on a separate STA thread, and using an event to block the main UI thread until 'Finish' is pressed, but there's a catch to this method: you can click on the close button of the 'main' window while the dialog is visible, and the main window closes when the dialog is hidden.
Update
Thanks for the responses so far. Sorry - it looks like I got the balance wrong between too much background and not enough.
The form is effectively a modal 'wizard' dialog - it appears, sits in front of the main app modally, and then is hidden. So as far as the user's concerned there's no non-standard weirdness going on. The only difference is that the dialog is driven from a series of callbacks from the UI thread, so I don't think making it truly modal (via a call to ShowDialog) for its lifetime would work. The first callback must show the dialog, and then block while the user sets their preferences via the dialog UI. After that, the dialog stays visible and displays a progress bar page while various other callbacks are made from the UI thread. Eventually the form is hidden. The user isn't interacting with the main window while the form is up. As far as they're concerned, it should appear to be 100% modal wrt the main UI thread.
(The form is a dialog for a Visual Studio wizard - these are driven from a series of callbacks on the UI thread). An alternative would be to show the dialog, hide it, immediately show a topmost 'progress' form instead and then hide that, but I think showing a single dialog is more seamless an experience for the user.
Again - sorry for the confusion!
Perhaps you want to rethink your interaction model? How are you going to explain this to your users? They have an internalized model of how computer programs work, and you better have a very good reason to break that. They know about modal dialogs, they know about non-modal dialogs, they know about inspectors. Choose one, and apply it.
Modal dialogs are made for short-time interaction. They should not block exiting the application. The user is in control of the interaction, the program only provides the minimum of restrictions needed.
[after the explanation, replaced]
What's wrong with showing the progress bar in the modal dialog? Start processing once ok
is clicked, disabling all buttons, only keeping the cancel button active? If it takes a long time, the user might want to abort the action. Only close the dialog when you're finished processing.
You could use a modeless dialog then have your main UI check if the user has clicked the Finished button. If the modeless dialog is open but Finished hasn't been clicked then don't respond to any users actions in the main form...
This is just a terrible idea - it's completely non-standard behavior and you're going to jump through all kinds of hoops to get something working that is just going to horribly confuse your users.
Like most of the other answers here stated, you're implement non-standard UI elements that will be confusing to most users.
If the dialog remains visible just to provide read-only access to the data, then why not have dialog window close normally and open a side-bar window in your application with the data from the dialog window?
If the dialog remains visible to allow the users to continue making updates in it, then perhaps, it shouldn't be modal to begin with.
Point is, there's a couple different ways you can accomplish your task without breaking standard UI metaphors.
I'd make it a flyout from the side or bottom of your app that shoves other things out of the way. If it's on top of other stuff that the user might need to see or interact with then it's just gonna annoy them.
I found that showing an an invisible modal dialog on the main UI thread during the blocking stage of the interaction works great.
Hidden modal dialog settings (so it's not visible): ShowInTaskBar=false, FormBorderStyle=None, size={0,0}, Opacity=0%, StartupPosition=CenterParent.
The hidden dialog is shown on the UI thread using ShowDialog. The visible dialog is shown on a separate STA thread. The thread is kicked off before calling hiddenDialog.ShowDialog on the main UI thread.
The visible dialog hides hiddenDialog when it wants the initial blocking state to complete. This stops the main UI thread from blocking.
The important bits of code:
void LaunchWizardForm(s)
{
// Show the wizard on its own thread.
ThreadStart t = () =>
{
_wizard = new WizardForm(s);
Application.Run(new ApplicationContext(_wizard));
};
var thread = new Thread(t);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
// Block this (main UI) thread
_hiddenForm.ShowDialog();
}
void EndModalEpisode()
{
_hiddenForm.Invoke((Action) (() => _hiddenForm.Hide()));
}
Related
I need to create a menubar with a number of menus that have submenus. When I open a dialog from a top level menu item, everything works as desired/expected. BUT when I open a dialog from a submenu, pressing the tab key closes the dialog.
I've tried several different ways of implementing the nested menus and settled on the approach discussed here: https://github.com/mui-org/material-ui/issues/11723
I've created sample code to demonstrate the problem here:
https://codesandbox.io/s/loving-heisenberg-rvwwb
You'll see this is forked from the submenu example I found on GitHub. There were a few things I changed because I wasn't sure how to add the opening of a dialog from that example, so I'm not sure the way I did it is correct.
The problem is that Tab is triggering close of the parent Menu which then causes the Dialog to be unmounted. You could use state to prevent the parent Menu from closing whenever the Dialog is open, but that leaves a different problem. Regardless of whether the parent Menu closes, when a Tab occurs it calls event.preventDefault() which then prevents the Tab from changing the focus location (the default browser behavior).
You can fix this by having the Dialog stop propagation of the Tab key event. This prevents Menu from receiving it, so Menu won't try to close itself and it won't call event.preventDefault(). I can't guarantee that this won't introduce some new issues, but this fixes the issue described.
const stopPropagationForTab = (event) => {
if (event.key === "Tab") {
event.stopPropagation();
}
};
<Dialog
onKeyDown={stopPropagationForTab}
In my fork of your sandbox, I upgraded the Material-UI version from 1.2 to 4.0 just because I wanted to make sure the issues weren't related to aspects that have changed. This threw off some of the styling, but the main behavior being addressed seemed to work the same in both versions.
A different way to handle this problem would be to rework the code such that the Dialog is no longer a child of the Menu. Then clicking a menu item that opens a Dialog would set state at the top-level for closing all the menus and opening the Dialog. This would probably be a better way to handle this, but it is a bigger change to the code structure.
I'm working on a Winforms project that uses CefSharp as a Gui. For several reasons I would like to implement a custom context menu using the Winforms ContextMenu class; rendering the menu in Html or customizing the ChromiumWebBrowser's context menu (using CefSharp.IContextMenuHandler) are not an option.
The context menu it triggered by Javascript code that calls a method on a .net object I passed to RegisterAsyncJsObject; the default context menu is prevented using Javascript. I'm invoking the method call on the Gui thread, because the call over the "javascript bridge" to the registered object comes from a different thread.
My problem: when manually showing the Winforms context menu over the CefSharp.WinForms.ChromiumWebBrowser the context menu does not get the keyboard focus (e.g. selecting items with the arrow key doesn't work nor can I close the contextmenu using Esc); instead the keyboard focus remains with the ChromiumWebBrowser control. And, if I click on the ChromiumWebBrowser's control area the context menu doesn't close either. I can only close the context menu by selecting an item with the mouse or clicking on another control within the form (in which the ChromiumWebBrowser is contained) or somewhere completely else (e.g. desktop or another application).
If I trigger the context menu from elsewhere in my code - ultimately using the same method that calls myContextMenu.Show() - the context menu gets the keyboard focus as desired. But one problem still remains: it doesn't close when I click within the ChromiumWebBrowser control.
I haven't used IFocusHander, IContextMenuHandler, IKeyboardHandler - should I?
I'm using CEF 3.2454.1344.g2782fb8, Chromium 45.0.2454.101 and .net 4.5.1.
Unfortunately extracting demo code isn't reasonably possible.
Anyone any ideas?
EDIT1:
After reading the comments, I decided to describe the code flow more precisely:
When right clicking Javascript sends a message to the registered .net object, containing the mouse coordinates. The default context menu is prevented by setting preventDefault on the MouseEvent arguments of the ContextMenu event.
The registered .net object receives the messages and calls windowForm.Invoke(Sub() ... ), because the message is not received on the Main/Gui thread, but must be processed there for the context menu to appear correctly.
The contextmenu is created and assigned to the ContextMenuStrip property of the UserControl that contains the actual ChromiumWebBrowser control.
It is displayed using ContextMenuStrip.Show(location) method.
Issues:
The context menu has no keyboard-focus.
All mouse events appear to be "swallowed" by the ChromiumWebBrowser: clicking there does not close the context menu.
Opening the context menu identically except for using a different "trigger" works fine, except for the 2nd issue.
In the end the solution is simple; everything works as implemented and desired, if the following steps are added:
Before showing the context menu disable the UserControl with the ChromiumWebBrowser and set the focus to the owning form; something like this:
Private Sub showContextMenu(position As Point)
Me.ctrlCefBrowser.Enabled = False
Me.Focus()
myContextMenu.Show(position)
End Sub
That takes the focus away from the ChromiumWebBrowser, giving the context menu a chance to respond to the keyboard inputs. And also, by disabling the control, the mouse events are not "swallowed" anymore so clicking on the browser area causes the context menu to go away again.
Then, finally, add an event handler to the context menu to re-enable the browser control again:
Private Sub myContextMenu_Closed(sender As Object, e As ToolStripDropDownClosedEventArgs) Handles myContextMenu.Closed
Me.ctrlCefBrowser.Enabled = True
Me.ctrlCefBrowser.Focus()
End Sub
That did the trick for me, now I have a fully customizable Gdi context menu for my webbrowser control :o)
Note:
A similar problem arises when using other menus as well, e.g. in a main menu or tool bar: clicking on the ChromiumWebBrowser control will not close the menu (because the mouse event is also "swallowed"). The same solution can be applied: when opening a drop down menu deactivate (Enabled = False) the web browser control. And when it closes, reactivate it. For my menus I used a derived class (Inherits ToolStripMenuItem) that adds listeners to the according events. That takes care of the problem in a global and simple way.
EDIT:
The proposed solution above left the problem that the click on the disabled browser control closed the menu as intended, but got lost, i.e. the browser couldn't process it. My current workaround now is:
Do not disable the browser control.
Using the openening events of menu items and context menus, keep track of which menu is currently open.
When the browser receives the focus (obtainable by intercepting WndProc messages) close the opened menu.
Implementing the actual solution caused some headaches in the details, but maybe that helps someone along anyhow...
New Thought, Maybe I am looking at this totally incorrectly. So Here is exactly what I am trying to do in case there is another option I am not aware of.
I have a WPF app, the main window shows a smaller dialog window using ShowDialog(), when a user clicks on the parent window that showed the dialog, I need to make the dialog window, flash, shake or blink.
AresAvatar posted a link that looks like it might be able to use, but is there another option I am not aware of?
My original Question.
Mouse click event when Modal window's parent is clicked in WPF app?
I have a wpf app that shows a modal window using ShowDialog().
I would like to fire an event when the user tries to click the parent window that is now disabled.
Is it possible on the parent to receive a click event when it has shown a modal window?
When I attempted this using an interaction trigger, the events never fired on parent window.
Otherwise, what suggestions / options are there.
Thanks
No WPF events are sent under these conditions. The only Windows message I can see that gets sent is WM_WINDOWPOSCHANGING. You could check for that message, and check if the window was disabled when it occurred. Here's a good article on checking WM_WINDOWPOSCHANGING.
Edit: that link seems to be dead. Here's an example on StackOverflow of checking window messages.
I know this is an old question but I'll post my solution in case any one needs it.
Set the dialog.owner prior to calling ShowDialog().
var dialog = new DialogWindow();
dialog.owner = MainWindow;
dialog.ShowDialog();
The result is that clicking on the main window, brings the dialog window to the front and makes the dialog window flash.
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.
I've got a "Main Window" containing quite a few things, including, in the status bar (at the very bottom of the window), a "Support" button, which the user can use at any time to open a window containing our support phone number, along with a little chat functionality if the user prefers to chat with us.
The problem is that if the program is displaying a modal dialog, the "support" button is not clickable anymore.
Stopping using modal dialogs is not an option ; I use them because I sometimes want to force the user into performing a specific task before I can do something else in the software.
What's the best way to let the user contact the support without having to close the current modal dialog?
Modal dialogs should behave as modal dialogs, the user won't expect to be able to click a button in the main window even if it were possible.
Your best bet is to put a support button on the dialog too.
Using a shortcut key instead of a button may be an option. The functionality could be factorized into a base form class like this :
public class BaseForm : Form
{
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.F1)
{
SupportForm f = new SupportForm ();
f.Show();
}
return base.ProcessDialogKey(keyData);
}
}
Not using modal dialogs is an option. You can disable other parts of your interface during the required interaction to get whatever it is that you need out of the user.
The solution is to avoid situations where the user 'must' do something. Modal dialogs often get in the way if, for example, the user wants to quit the application right at that moment, or see something in a backgrounded window, or refer to another part of your application. Instead of using them, design your interaction so that if there is a required action/piece of information, it's folded into the application logic.
Think about website design -- modal dialogs are very rarely found on the web, and for good reason -- they disrupt the user's workflow unnecessarily. And yet plenty of sites have 'required' information.
Don't use modal dialogs; they are a shortcut to avoid a better design.