I have a project with multiple forms and when, for example, Form A opens Form B which opens Form C, then Form C is closed, Form B and Form A have gone to the back of the window order, so that whatever other programs are open are shown in front of these other forms in the project.
Why is this happening and how would I go about making sure the last opened form is shown when another form is closed?
Ensure that you are setting the Owner property of forms that are opened by other controls or Forms, either by setting the property explicitly or by passing the owner in as a parameter to Show() or ShowDialog().
You could track the "last" form in each of your forms, and on close, activate it. ie: if Form B opens Form C, Form C could keep a reference to Form B (or any form to activate on close), and force it to the foreground when you close your form.
That being said, I personally think that it's often better to just let the operating system perform its normal window manipulation/handling, unless there is a specific reason to override it. Applications that force their windows into the forefront often annoy me - instead of being beneficial, it can be disruptive to your users.
You could have a series of Dialog forms opened from a single form, in order. What this allows you to do is check the DialogResult - you'd then be able to control the direction in which you open new forms or show old forms.
If you're worried about the z-order of so many forms, you might consider changing your UI to avoid multiple non-modal windows.
Well maybe you need to set up the new forms as a modal dialog with the ownership to the older forms. This way when the new form closes the new form will be visible. Additionally as long as the new form is open, nobody will be able to access the older forms.
Related
I'm making a WinForm app in C# (Visual studio) for fun. I came across a low-priority problem. It doesn't affect how the app works. But...
On the starting page, I have a button to open a Form1, inside Form1, there's a button to open a Form2 and so on.
At runtime, when I open a form, its parent form does not close and every form is a separate tab in the task-bar. As the layers grow, I'll have more-than-acceptable amount of tabs down there...
Is there a way to have only 1 tab?
I've tried:
Adding a parentForm.close() line when opening the form, but that was bad.
Instead of creating another form, putting everything in a panel, and bringing out another panel using code, but if there are too many layers, the code gets ridiculously long.
There has to be a simpler way right? Please shed some light.
Yes, you have a property in every form called ShowInTaskbar which is true by default. You can change that in the form properties under Window Style section or changing it by code manually:
Form2.ShowInTaskbar = false;
Form2.ShowDialog();
Configure to false all forms but the first one in order to achieve your desired behaviour.
Make sure your opened forms are dialogs or you are put them on top so user can never get in the situation where the form is behind and they cannot close it.
Anyway, with a proper form parenting configuration (if it fits your needs) you won't need this, as children forms won't appear in the taskbar.
If a form is parented within another form, the parented form is not displayed in the Windows taskbar.
Make sure you check the MSDN Documentation about this.
I have an application that some times requires the user to have two forms open at a time. I have the main 'home' form window, but also a calculator form window. It isn't a normal calculator so I would like the calculator to stay within the one application.
When filling out the main form, the calculator is needed to work out some data to input. Only problem is, when calculator.ShowDialog() is used, the main form loses focus. The calculator is opened to the right of the main window. So ideally, I would have which ever window is clicked, gain focus.
Just use form.Show() instead of ShowDialog
Me thinks that you can add Code line calculator.Activate();
I'm building a C# form application which contains several forms. (Login, Menu, Products, Users, Settings..etc).
This is the structure how the navigation happens.
Currently what I'm doing is hide the current form and create a new object of the next form and display it.
this.Hide();
Menu obj = new Menu();
obj.Show();
If I create objects for each visit to a form, there'll be lot of objects of that form. Right ?
Is this the correct way of doing it ?
And some of the navigation are bidirectional. There's a button on each form to go back.
So, what's the efficient way of closing the current form and go to next.
I think a better (this is subjective) flow would be:
Login and Menu are Forms that are considered top level.
When Login is complete, it is closed (not hidden), and Menu appears as the only form.
From Menu, you can pop-up Modal dialogs for the other screens. But only one of them can be open at a time. When they're closed, the user can control the Menu form again and open another screen.
Note, by Modal dialogs, they would appear on top of the Menu form, but Menu wouldn't be hidden. It is simply waiting for the modal to be closed before it regains control.
The problem with windows that appear and disappear (regardless of whether they are closed or hidden) is that the end result may be disconcerting to the user. They may feel that the program has quit and the link between prior and consecutive windows may not be easily understood.
UserControls
Alternatively you may want to consider replacing your other windows with UserControls. This way you have a main window that consistantly stays open and you simply embed a UserControl representing the other pages into it. Thus making it more obvious to the user that there is a notion of an consistent "app".
Users; Products and Settings, instead of deriving from Form would instead derive from UserControl. To move from say Users to Products, simply remove Users from the Controls property; create a Products control and add it to Controls ensuring that it is set to Dock.Fill.
I see no reason why Login still can't remain a modal dialog though.
I am using WinForms for a C# project and my main form has a simple button that uses ShowDialog(this) on a second form to show it.
Like this:
if (myParameterForm.ShowDialog(this) == DialogResult.OK)
{//stuff happens}
As per my requirements, when the child form is visible, you cannot access the parent form.
For the past year this child form has been the bane of my application as it mysteriously manages to hide behind its parent form from time to time. The reason this is such a big problem is because the software is designed to be used from a touchscreen kiosk, so the user only has access to a touch-screen, but the child form has locked input from any form but itself till it is acknowledged (closed with ok or cancel).
On load the child form uses "this.TopMost = true" just in case, I added this as an effort to fix my problem.
I use no other visualizing functions on the child form, the thread calling the form literally waits there till the form is closed.
Since the user has no access to a keyboard, or anything but a touchscreen I'm miffed as to how the child form manages to hide behind the parent form. I actually have been unable to replicate the behavior, and have only seen it as a result of responding to service requests.
I want to avoid using a timer to continually check if the form is TopMost because it just seems wrong. Should I reconsider? What event could possibly be occurring that is banishing my child form backstage?
I've tried using the search, but as far as I can tell I'm doing this correctly... Assuming that there is some sinister 3rd party application causing occasional hijinks, what is the best way to detect and rectify this situation automatically without throwing in a periodic check? I am not sure that the VisibleChanged event is what I'm looking for.
I can reproduce the behavior you are describing by minimizing the child window when it is displayed using ShowDialog. Is it possible that something is minimizing the child window? You could try disabling the control box for the child window to see if that helps. I would probably also set ShowInTaskbar to false for the child window (for usability reasons).
I would probably just implement the child form as a dynamically loaded user control instead. When you need it just load it on top of everything else. This way your main window is always in focus and the content you want to display is on top. this will obviously be a bit of work, but judging by the fact that this has been a problem for a year, you probably don't mind the work if it fixes the problem. There may be more intricacies that you'll have to deal with(i.e. having to make all other controls invisible until the child is done, etc.) but I think this is the easiest and most reliable fix.
In my experience TopMost windows and modal dialogs never behave very well ... as you can lock yourself out if a TopMost window happen to cover the modal dialog control. Are you applying TopMost to the main window anywhere in your code?
I have a form MainForm with several properties/methods that are accessed from another thread.
At some point I might open a form AuxForm with ShowDialog() and then while that modal form is open, the other thread still modifies the MainForm's properties.
This is all desired.
In one of the methods accessed from another thread I need to execute some code, but only if the modal AuxForm is not open. Is there any way to check this (by using .NET WF Form properties) or I need to use a flag variable?
NOTE: None of these properties/methods modify the controls (so no Invoke is required).
Well a flag would probably be the best idea. But just to also pass on some useless information, when a window shows a modal dialog the Window Styles are modified to include WS_DISABLED, basically the window is disabled, so you can check if the window is disabled.
maybe this can help... once you have all the opened windows of the application you can search the collection for your target window. You can tell if a form is modal by checking it`s Modal property.