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.
Related
I'm writing a WPF application which has a main canvas area, where the user can open a number of windows, drag and drop them and generally move them around the application as he or she pleases.
What I've done so far basically opens windows using the Show() method, and I have hidden them from the taskbar. However, when the main application is minimised, the small windows which have been opened all appear on the desktop. What I am lookign for is basically a way to keep the windows contained within the application.
Is this possible?
Yes but you need to design some infrastructure to replace what MDI used to do ( though often quite badly)
So when you open a new window in your app, add it to a list.
When it closes, take it out
When your main app is minimised, minimise all the windows in the list as well.
You can also trap child window move events and keep them in bounds, take the children with you when the main app moves. Docking, cascade, tiling...
Key bit it to get this list of managed child windows going.
What you want to do is called MDI.
WPF MDI
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#
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.
Our WPF application in the current design opens new windows for list screen.We don't have restrictions on the number of windows you open etc.We are using a ribbon control and well it has tab support.Which is better a new window or a tab? (With windows 7 having a better group of window management etc) Should I go in for tab or leave it as window. I can't make the detail screen tab since well the user click of a item in the grid to select and edit.Any valid suggestions? Thanks in advance.
Tabs in a Ribbon shouldn't change the view. The Ribbon is an enhanced toolbar, not a view changer.
If your using the MS Ribbon via OfficeUI, then there is a stipulation in the design guidelines that the view should never change the appearance of the ribbon (apart from loading context tabs) and that they ribbon should never wholesale change the view.
In regards to your question, do you mean that you have list/grid and you want a view to be able to change the data in the row. Eg. they double click a row, a view appears that gives them the ability to edit that row?
The right way is to ask your users what they like more. If you can't ask users, ask yourself - what you find more convenient - to open\close windows or switch between tabs. I wouldn't rely on win7 task bar as it's grouping behavior can be disabled or users may use another OS. Also I would suggest to check Microsoft guidelines for using ribbon.
Do you need to see more than one pane's content at once? Windows allow this, but tabs do not.
Tabs make management of the various windows easier at the expense of some flexibility.
Are your users likely to be running on multiple windows?
It is really hard to give a confident answer to you on this one without knowing more about your application and your user's requirements.
Windows 7 displays multiple previews on grouped windows of the application, however in case of tab, like IE, you will have to write quite a good custom code to show your tabs in preview of Windows 7 taskbar, which in case of Multiple Windows, it will be done automatically.
Not only that, Windows 7 also lets you put seven toolbar buttons on the preview windows, very few people knows about it because no application currently does it.
For tabs you will need to do extra programming to support multi window preview.
So its better to stay with multi window solution for now.
However in case of IE, if you try to use Windows 7 taskbar, the tabs dont align themselves in correct order of what is displayed in preview, it could be bug, but yes there might be certain limitations because when user chooses the tab to preview you will not be able to show them preview unless you make it active and thats why its little bad.
I recommend playing with Mozilla Firefox and Google Chrome if you want to see tabs at their finest.
Notice that tabs can be teared out into a separate window and windows can be docked as tabs.
I am trying to create a panel which will have a set of "buttons" on it.
These buttons should have the following behaviour:
Appear similar to a tag (with
rounded edges)
Contain a red
cross to remove the filter/tag from
the panel, similar to the way internet
explorer tabs have an embedded cross to close the individual tab.
allow the user to click
on the tag and respond like a normal
button (as long as the click is not
in the red cross)
Number 1 is no problem, this is just appearance, however, regarding numbers 2 and 3, I am not sure if there is already code out there do to something similar...and I dont really want to reinvent the wheel if I can avoid it!
My question is: Does anyone know if there is something out there in infragistics which will do this simply, or will I need to write this myself by subclassing winform buttons?
Thanks in advance!
Is this new development or maintenance of an existing project?
If it is maintenance, you have a somewhat tougher time ahead. You'll implement a UserControl, probably segmented into two buttons. Use docking to get the behavior as correct as possible. The far right button would contain your cross image; the left (which would need to auto-expand as you resize the control) would contain your primary button behavior. Play with the visual styles until you get them right (EG, removing borders, etc).
If this is new development, and you haven't gotten too far into it, you might consider using Windows Presentation Framework (WPF) instead of WinForms. It will be easier to build the control and get it to look exactly how you want it. WPF includes an extremely powerful control compositing system which allows you to layer multiple controls on top of each other and have them work exactly as you'd expect, and it carries the added advantage of allowing full visual control out-of-the-box.
Either way, this is more work than dropping in an external component ... I've used Infragistics for years, and I can't think of anything they have which is comparable. The closest, but only if you're building an MDI application and these controls are for window navigation, is the Tabbed MDI window management tools -- and there, only the tabs (which replace window title bars) have this behavior.
I don't think that infragistics can do something like this. The UltraButton control can't.
Implementing a own control wouldn't be that hard.
your probably going to have to make a costume control for this type of work.