I have a WPF window myWindow, which I open using myWindow.ShowDialog() ?? true and listen to the DialogResult (DialogResult = true) to execute some code.
When I set it to either true or false, the window is disposed, is there a way I can prevent this window from closing while also getting the DialogResult? Also, is there a another way I can approach this problem?
What do you want to happen? For example:
You might want a modal dialog (so users can't interact with the rest of the UI while it is visible) but you want code to run in the main program in response to some user action in the dialog. In this case, add events to your dialog that the main program can respond to.
Or you might actually want a modeless dialog, which lets users interact with the rest of the program without completing the dialog. In this case, don't use ShowWindow, just show an owned window.
Related
For cross-platform parity reasons, my GetOpenFileName() specifies no owner and I explicitly disable all toplevel windows myself. The problem is re-enabling. In order to re-enable these windows correctly, I need to re-enable them before the dialog closes.
In the case of the user choosing a file, this is no issue: I just check for CDN_FILEOK in the hook procedure. No issues, no messed-up focus.
How can I do the same, but for cancelling the dialog box?
I have tried WM_DESTROY in the hook procedure, but that runs after the dialog box has been hidden (too late). I have tried WM_COMMAND, but that doesn't seem to cover all cases. I'm not sure what other options I have.
I need to target Windows XP and newer for now; that also means no Common Item Dialogs. Thanks!
Alternative: if there was a way to do a callback-based GetOpenFileName() that returned control to my message loop, like on Mac OS X with beginSheetModalForWindow:, I could be able to specify a parent window and avoid this hack.
There is no CDN notification when the dialog is canceled. If the user presses the Cancel button, you could try intercepting the BN_CLICKED notification that it sends to the dialog, or even subclass the button itself. But if the user cancels the dialog through other means (clicking the red X, pressing ESC, etc), you will likely have to catch the WM_CLOSE message instead.
I am storing values of extjs desktop window in a database.
Case:
When user minimized a window and logs out,
the window should stay minimized when he logs in again.
Now on logon the before minimized window pops up
The values are all there! But I cant find the property to set...
I tried hidden:true, but no effect.
I was looking for a property to set when creating the window for extjs-desktop. But a superior function is invoking creation, takes window as response and does "win.show()". At this point i am checking the "minimized" value delivered by AJAX.
I am working with a WPF application.I have two text boxes and a button in my first window.Based on some DB operations i need to open the copy of the first window(if possible open like a new tab) provided both windows can be accessed simultaneously.I used
var MainWindow = new MainWindow();
MainWindow.ShowDialog();
and
var MainWindow = new MainWindow();
MainWindow.Show();
both of them doesnt meet my expectations.Can anyone help me.
When you use ShowDialog(), it opens a single modal dialog that is expected to be closed when complete.
If you want to open multiple windows and not block form control, try using Show() instead.
var window = new MainWindow();
window.Show();
I would advise you to read all of the relating pages on MSDN so that you can learn how everything works.
For the Show method:
Opens a window and returns without waiting for the newly opened window to close.
For the ShowDialog method:
Opens a window and returns only when the newly opened window is closed.
From the Remarks section of the Window.Show Method page:
When the Window class is instantiated, it is not visible by default. Show shows a window and returns immediately, without waiting for the window to be closed. Consequently, the opened window does not prevent users from interacting with other windows in the application. This type of window is called a modeless window. Common examples of modeless windows are properties windows, toolboxes, and palettes. To restrict a user to interacting with a specific window, the window must be opened by calling ShowDialog.
Calling Show achieves the same end result as setting Visibility property of the Window object to Visible. However, there is a difference between the two from a timing perspective.
Therefore, for your solution, I would recommend that you use the Show method instead.
Surprisingly one can show more than one dialog at a time by putting the ShowDialog() call on the Dispatcher:
uiDispatcher.BeginInvoke(new Func<bool?>(myWindow.ShowDialog));
How come this works and still the UI remains running responding to user interaction once the dialog is shown (I would have thought not since ShowDialog() blocks the thread it is on which has to be the UI thread), one can even go on showing new dialogs:
Window myWindow;
for(int i = 0; i < 5; i ++)
{
myWindow = new Window();
uiDispatcher.BeginInvoke(new Func<bool?>(myWindow.ShowDialog));
}
And the UI is still responsive.
Is there something I should beware of relying on this behaviour? (I want to show one dialog on top of another when some background thread wants to - this works - the only unwanted behaviour seems to be when switching apps sometimes WPF does not know which dialog should be on top - but still allows you to bring one of the dialogs to the front by clicking on it which is unusual for a dialog as clicking outside a dialog is usually not allowed).
UPDATE: One issue I have come across is if you hide one of your dialogs the user can interact with all other Windows again! (not just the other dialogs). See: WPF Dialog not modal?
Showing a dialog does not block the UI thread -- otherwise you won't be able to interact with the dialog.
It merely marks the fact that there is a modal dialog outstanding, and that it should disable inputs to all other non-dialog windows.
If you shuff a ShowDialog call into the dispatcher, the dispatcher will allow an additional dialog to be created because you are not doing something which is prohibited when a modal dialog is outstanding -- which is to input into other non-dialog windows.
Your new dialog is fully functional, because it is a dialog, and you are not trying to input into non-dialog windows.
Switching applications should bring any modal dialog out to the front, but since you have more than one modal dialogs, the system will get confused as to which one should be top-most. I'd suggest you trap the activation event and just manually bring the necessary dialog top-most.
I'm creating a simple win32 program with one main window and a modeless dialog.
I know that using IsDialogMessage() the program will dispatches messages to modeless window (like keyboard events).
// step 3: The Message Loop
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
if(!IsDialogMessage(g_hToolbar, &Msg))
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
}
But without using IsDialogMessage(), the modeless window still get events like click and some other events dispatched by the mouse.
Why? How can this modeless get these messages if the main loop isn't dispatching messages to it?
I just want to know how it works internally.
IsDialogMessage filters out some of the messages, but allows most messages to hit the TranslateMessage / DispatchMessage part of the message loop and be dispatched normally.
The reason that IsDialogMessage has to process some messages is that the messages were going to be delivered to the wrong window.
Consider - normally - keypress messages are delivered to the control with focus. However, the tab keystroke is meant to move focus to the next control on the dialog.
Rather than making every control have to process tabbing, IsDialogMessage catches tab keystrokes before they are delivered to the actual currently focused control, and ensures that the dialog box code handles the tab logic.
Most other messages - mouse overs and painting and so on - are going to be delivered to the dialog boxes window proc anyway - and so are handled the normal way. Its really just the subset of messages that were destined to be sent to controls, but need to be handled by the dialog box, that IsDialogMessage filters out and processes.
A modal window will disable its parent window, the fact that your HWND is called g_hToolbar tells me that this is not a modal dialog...
Modal dialogs (DialogBox*) create their own message loop (And work like MessageBox etc), you must be talking about modeless dialogs (CreateDialog*) You will get all messages from the window manager without IsDialogMessage, IsDialogMessage performs dialog manager tasks like handling TAB and default button focus.
See this blog post for info about using IsDialogMessage on non dialog windows. See this post series for a great overview about the dialog manager and how to write your own.
Without IsDialogMessage some dialog features, like changing focus when Tab key is pressed, are not working. IsDialogMessage implements these dialog-specific features. If it returns TRUE, current message is already handled, and there is no need to call TranslateMessage and DispatchMessage.