I am creating a windows mobile application that has several different screens. At the bottom of each screen is a menu bar which the user can click on to navigate each screen.
My question is should I use a new form for each screen and clone the menu or use one form and have all the other screens as a control and add them to the main form?
Cheers
I'd vote for controls.
Both mechanisms can achieve the flow you want, and from a fundamental perspective neither is going to really be worse (as in load times, memory consumed, or what have you) so it's largely a personal style decision. Me, I use a UI framework that lends itself heavily to UserControls, so that's what I use.
Generally speaking, when I create an app I have a single parent/host form that has Workspaces where I put my Views. Thos Views are UserControls. Whether I use a tabbed workspace or a desk workspace, they still end up as Controls. The only reason I use more than one full-up Form is if I have a dialog (warnings, inputs, etc) where I will be doing a ShowDialog call.
Per this link, there is no MDI functionality in Windows Mobile.
In our application, we use different forms for each screen.
There are two ways to open up new windows:
formName.ShowDialog(): the new screen will be opened as a child of the other screen. In this case, you won't be able to access your parent form until the child is closed.
formName.Show(): the new screen will NOT be opened as a child of the other screen. Hence, you can access your parent even if the child is not closed.
You can use TabControl in single form with each tab having it's own controls. No need to add controls dynamically. And one single form. The way to achieve this is discussed in more detail in this answer.
Creating Wizards for Windows Forms in C#
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'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 have a WPF application that loads a realtime live chart in a window,
But I end up having 10+ windows open on my desktop (as many windows as there are charts).
So my need is basically to group/embed all these WPF windows in a single window.
I tried WPF MDI but I had serious trouble since it requires the windows to be usercontrols instead, and in that case, my live chart displays but stays empty and does not refresh nor plots realtime data. Same behavior when I put my chart controls inside a Page instead of a Window (chart does not update). This is why I guess I really need to stick with windows at this point.
I welcome any simple & straight solution
Are you sure you want to have a last century MDI in your WPF application? I'd recommend to switch to other, less expensive and more flexible content arrangement. I'd organize the charts in some kind of scrollable or swipeable container, maybe with some kind of navigation or tabbing facility... If your users really want to have one or some charts in a separate window(s), let them drag the charts out of the main container and create separate window on demand (something like dragging a tab out of Interent Explorer).
I'm currently designing an MDI application (a custom CRM) in .net 4.0 and i'm starting to dislike the whole interface simply because there's no real way to track which windows are open or closed and it'll probably lead to a very confusing interface.
What is the best way to avoid this?
- Should i implement a taskbar to track every open mdi child?
- Should i use dialogs instead to prevent multi-tasking?
- Is there any way to change the size of a minimized window on a mdi container (why are they so small, you can't even read the full form title that way...)
Sorry for so many questions, thanks in advance.
MDI has its uses, but as you've found can easily lead to a cluttered, hard-to-use interface. The current in-vogue way of dealing with this is to add a tab control (as in any web browser, or most text editors/IDEs) to allow switching between open views. This is close to a task bar I guess.
Other options are controls like the Outlook bar (the big view chooser down the left-hand side of Outlook) or possibly just a simple list box with the currently open views.
Alternatively, consider how often you really want multiple windows available and whether most of them are "tool windows". If so, perhaps look at using docking windows for these tool windows, and a Single Document interface for the rest of the app. All depends on what you're actually doing!
The MDI windowing management already has the built-in to track open windows by way of the menu. The ToolStripMenu has an MdiWindowListItem that you can set to a reference of the menu item that will contain the list of open windows. If the menu is attached to the MDI parent window, child windows automatically populate the menu item.
One of the objectives of MDI is to allow multitasking. If that's not what you want, use a different design.
As far as changing the size of the minimized windows, apparently it's not possible using the standard Windows interface. See more info here: Is it possible to change size of minimized window in MDI C# Winforms. But you could remove the standard Minimize button, add your own, and do what you want with the windows in a Normal state.
For instance, I have an application that has a main window and then child windows inside of it.
http://screenshots.rd.to/sn/e3hek/sapienfullwindow.png
http://screenshots.rd.to/sn/e3hek/appscreen8.png
What i need is to grab each individual child window of that application, and display them as tabs in my application, or on a panel's handle.
I already have code to kidnap the application and put it into mine, and it works great.
MDI support is already present in the C#. So the first screenshot is using the MDI option.
The second screenshot is using tabbed windows. Now you have two options:
Use this opensource library DockPanelSuite which will let you have tabs in your application. something similar to visual studio interface. You can create forms and then tab it based on your needs. You can even dock them anywhere in the parent form by drag and drop. Just like in visual studio.
The second option is to create a form with tab control covering the whole windows. There you create tabs using the resource editor and hide/show based on the forms you want to display to the end user.
In my opinion, use the first option which gives you lot more customization. Also if you use the dockpanel, you can switch between the views shown in your first screenshot and second one. So user has better control as to how he wants to view. Dockpanel is free to use even in commerical apps and comes with source code. So you can either use the dll or directly incorporate the code in your application.