I'm developing a WPF application that's meant to live in the tool tray, so it doesn't involve any windows. Right-clicking the tool tray icon brings up a menu with a Configure Report Path... option, and I'd like to display a folder browser dialog to the user when this is clicked:
What I'm finding is that when the option is selected, a dialog opens and immediately closes unless I assign some window to Application.Current.MainWindow and show it before opening the dialog. This is the code I'm using:
public CounterIconViewModel(IMessenger messenger)
{
void ConfigureReportPath()
{
// Application window must be created and displayed.
Application.Current.MainWindow = new Window();
Application.Current.MainWindow.Show();
var browseDialog = new VistaFolderBrowserDialog { ShowNewFolderButton = false };
if (browseDialog.ShowDialog() != true)
{
return;
}
// (Separate issue) Command doesn't execute unless I comment out the line below.
//messenger.Send(browseDialog.SelectedPath, "ReportPath");
}
ConfigureReportPathCommand = new RelayCommand(ConfigureReportPath);
ExitApplicationCommand = new RelayCommand(Application.Current.Shutdown);
}
In this case I'm using VistaFolderBrowserDialog from Ookii.Dialogs.Wpf, but I've tried the same thing with another WPF browser dialog and notice identical behaviour.
Is there a reason why a browser dialog seems to require a window to be displayed to remain open, and any workarounds?
Update
I've found that if I initialize and pass an instance of Window to browseDialog.ShowDialog, the dialog remains open without me having to assign the main application window and display it:
if (browseDialog.ShowDialog(new Window()) != true)
I don't understand why this works. I'll post this as an answer if no others appear so that at least people in a similar situation are aware of this workaround.
Update 2
The other dialog I tested it with was CommonOpenFileDialog from Microsoft.WindowsApiCodePack-Shell:
var browseDialog = new CommonOpenFileDialog { IsFolderPicker = true };
browseDialog.ShowDialog();
My tool tray icon displays a rich tool-tip (a custom UserControl) if I hover over it, and with this browser dialog I found that:
If I hover over the icon to make the tool-tip display, then the browser dialog works fine when I try to open it on the first and every subsequent attempt.
If I try to open the browser dialog before displaying the tool-tip display, the browser dialog opens and closes immediately on the first try, but then remains open on every subsequent attempt.
This dialog also accepts a Window instance in ShowDialog but it makes no difference if I pass one or not.
My workaround (initializing and passing a blank window to the Ookli dialog browser) seems to work fine regardless of whether I first bring up the tool-tip, so I'm sticking with that for the time being.
I am having some very frustrating issues with my WPF window. The design I was going for is:
When the user minimizes the window it will minimize to a system tray icon (hide the window and icon on start bar). When the user right clicks on the icon, a context menu will show up with options and one of them will say open, which will open the app (show window again / unhide window agian). The user could also double click the icon as well.
Pretty simple right?
I have no issues minimzing to the task bar, I simply do the following on the closing event of the window:
e.Cancel = true;
this.Visibility = Visibility.Collapsed;
However, I am having issues properly restoring the window. I simply do this on the context menu click or icon double click event:
this.Visibility = Visibility.Visible;
this.Activate();
The issue is that the window is once again on the start bar with its icon but it is behind every single window the user has open. I want it so when the user goes to open the window it will be the top most window. I do not always want it to be the topmost, just only when they want to make it visible again.
I have tried many things like setting the show activate on the window to true, waiting a second after making it visible to then activate the window, activating the window multiple times (worked a few times but was maybe 1 out of 10 tries), etc..
I don't think showing / hiding a window should be this annoying and I am not really sure what I am doing wrong.
Any help is appreciated, thank you.
Only after posting this did I realize, the application minimizes first before hiding. When I show the window, it was showing as minimized.
After knowing this issue I was able to fix the issue. This may help others who do decide to hide the window after minimizing.
EDIT
Here is the code I used to hide the window (this is called after the event fires for state changed [minimized]):
Application.Current.MainWindow.Visibility = Visibility.Collapsed;
Application.Current.MainWindow.WindowState = WindowState.Normal;
You will notice I set the window state back to normal after I hide it. Even though the window is hidden and not being rendered it will in memory restore the window location / size.
Then when I want to see the window again I just do:
Application.Current.MainWindow.Visibility = Visibility.Visible;
Which will show the window just fine!
Hopes this helps someone out there!
Is there a way to open a new window instance within the primary application window and still wait for a user response before continuing with the main program? I just have a 3 option query with a picture to be offered to the user and a whole new window opening up seems like overkill, I would much prefer it opening in a frame within the current window.
Do something like this sans the separate window:
OptionWindow optionDialog = new OptionWindow();
optionDialog.Owner = this;
optionDialog.WindowStartupLocation = WindowStartupLocation.CenterOwner;
optionDialog.ShowDialog();
if (optionDialog.DialogResult == true)
{
something;
{
Seems like you could just have your "OptionWindow" be a frame that is on the WPF form, and when you want to show it, just disable all other panels and show the frame with your dialog, and after the user completes the dialog, enable all other panels and hide your dialog frame.
After I posted my answer, I saw that Mark Hall made an edit to his comment with pretty much the same suggestion. Sorry Mark.
I guess you are looking for modal window which can be achieved using Window.Showdialog.
Opens a window and returns only when the newly opened window is
closed.
I have a form which can be set to .Enabled = false;. The client still might click on it by accident which can turn out to be very annoying since every time you click on it you will get this ding sound. I was wondering whether it's possible to disable that or not.
Instead of setting Enable to false, you can hide the whole title bar with those two lines of code:
this.Text = "";
this.ControlBox = false;
This will result in user not being able to move the window, you can store the original title then restore it later if you want.
You could register to the Move event for the form and restore its location to wherever you want it to be (it should zero in to the top left corner IIRC).
I need to create a user control in C#.Net, which can be added to the application without being visible - just like the FolderBrowserDialog. It's a new window which I'll be using often so I think this is the right way. The window will be opened by envoking the showDialog-Method as known from the other dialog.
Any Idea?
Thanks and regards,
Daniel
Since all these "invisible" controls derive from Component class, you should start by reading the MSDN article on it: http://msdn.microsoft.com/en-us/library/system.componentmodel.component.aspx.
simply set Visible to false or isn't this what you're asking for ?
A UserControl is by definition not a Form; I think what you really want is a Component. That said, couldn't you really just create a new Form class that has the functionality you want? Whenever you want to display it, create a new instance and call ShowDialog. Or, if you want to preserve state, add an instance as a class member to your parent form, call its Show method whenever you want to display it, and add an event handler to its FormClosing event to check:
if (e.CloseReason == CloseReason.UserClosing)
and, if so,
e.Cancel = true;
Hide();
(This last part is to prevent errors if the user closes the form and then tries to display again after it's been disposed.)
I think more information may be needed, but if your crating a custom user control, the control should have a .Visible property. The follow is an example of how a button can be located on the form but hidden from a user.
button.Visible = true; // shows the button
button.Show(); // Shows the button
button.Visible = false; // hides the button
button.Hide(); // Hides the button
While the button may still be on the form/control, it will not be interactible by the user. You can still perform programmatic control on the button, but essentially it is not a user control while it is 'hidden'. If you want there to be a sort of hidden button that the user can click you will need to do other things to obtain this but It doesn't should like that is what you want.
This show/hide thought process sounds a lot like pains and confusion leftover from classic VB. The old form methods of show and hide, etc., were confusing and often left me as a developer in a position to not know whether an object existed or if was merely invisible. And checking was only trivial if you used On Error Goto to prevent a null reference. So right off I would advise not to think in terms of visibility unless you are doing something with a web page and need to maintain space and state.
First, create a Windows form and add it to your project, assuming that is the type of project that you are describing. Decorate the form with the proper controls, and where applicable, create properties to allow public access to the control values. Also set the DialogResult property of the buttons that either "OK" or "Cancel" the form. Give it an appropriate border style of either Fixed3D or FixedDialog. Maybe also set the property for where you want the form to appear on startup -- center parent, center screen, Windows default, etc. The event handlers for both "OK" and "Cancel" should invoke this.Close(); to close the window.
From the calling point in the code, here's some hypothetical code to get you going in the right direction. Write something like this in the place where you want to invoke your Dialog.
int intResult = 0;
string strResult = null;
MyDialogForm frm = new MyDialogForm();
frm.Title = "Select an Item";
frm.SomeProperty = 0;
frm.SomeOtherProperty = true;
if (frm.ShowDialog() == DialogResult.OK)
{
intResult = frm.Result;
strResult = frm.StringResult;
}
else if (frm.ShowDialog() == DialogResult.Cancel)
{
// User clicked the cancel button. Nothing to do except maybe display a message.
MessageBox.Show("Canceled Task");
}
...
// Somewhere further on down, but within scope, simply repeat
// what you just did, but without having to reinstantiate the
// form Window. But if you make it that far within the same
// scope, this method might be too busy and may need to be
// factored down.
So in short:
Scrap show/hide -- its not a good
practice.
Save the form data without
using an invisible form to save it;
that's the class's job.
If the UI requires a lot of flipping back and
forth between windows, check your
design for other alternatives for
solving the original problem. Maybe a design pattern such as MVC is for you, depending upon the size and complexity of your application.
Sound good?
You can put that control in a Panel. Set the panel height = 0 visible = false when you dont want to show the control.
And do the vice versa when you want to show it.
Derive from Control, not UserControl, and in the constructor set Visible = false.
Also create an event handler in the constructor.
VisibleChanged += new EventHandler(SetVisibleFalse);
Create a method named SetVisibleFalse.
private void SetVisibleFalse(object sender, EventArgs e)
{
if (Visible) Visible = false;
}