I'm writing a WinForms based application for Windows Mobile, targeting the CompactFramework 2.0 and coding in C#.
My application has a menu which the user can select severeral job functions from.
My question is this:
For the job specific screens, should I load a UserControl into a panel in the main form, or is it better to open a new form on top of the main form?
They both seem to meet my needs, and I don't know if there is a "right" answer here.
Is one method more correct than the other?
Forms are Controls (just look at the inheritance chain), and a Form itself doesn't have a whole lot of overhead in and of itself. It creates a native Window, but that's about it.
What should drive your decision is how you use and display your UI elements in your solution. Forms are conducive to many UI architectures, and they're what most developers are familiar with. The designer supports them well, and creating, showing, hiding and closing Forms is a well documented, often used paradigm that works just fine. Yes, you have the load penalty whenever a Form is created as it creates all of its contained controls, but you're going to pay that even if it's a UserControl. The child controls have to be created in either case.
One might argue that Forms require that you recreate them every time, but that's not true. If you use ShowDialog or Hide instead of Close, you can reuse your Forms and pay the price once. The advantage here is that the Form holds your Controls in teh collection and manages all of that for you, so you have little to worry about with the GC and remembering what roots you have alive.
The UserControl paradigm is more complex - you have to manage loading and unloading controls yourself to keep memory pressure low. Complexity also increases cost - cost to maintain, cost to support, and likely cost to develop. However there are some clear advantages to UserControls in some scenarios too. If you use an MVC/MVP pattern and some form of framework that handlesyour Views, a USerControl makes a really good View with the Form becoming the Workspace (the SCSF for the desktop is a classic example of this, and so is the OpenNETCF.IoC framework for the CF).
So which is "better"? It depends on how and where you're using the elements, how your team is already doing development, and how you've architected the solution you're plugging in to. In short, the is no one right answer.
In my experience, depending on your hardware, loading controls far outperforms launching distinct forms. Our devices (Motorola WT4090 with 32meg) have no hardware acceleration, and drawing complete forms seems to really tax them. There is as much as 4-6 second delay any time a form is launched; controls, however, are almost instantaneous.
Maybe the best answer is to create a series of user controls and experiment with loading them onto the main form. It should be a fairly easy matter to then try to create a series of forms that have just the user control to see if you can improve performance.
If you don't see any performance benefit either way, it seems that it would just be a matter of preference.
Use Forms. It's the way the other applications behave. It's the way the user expexts your application to work.
Look at the pre-installed "Contacts" application: On startup you get a contact list. Once you select a contact, a new form is being opened on top of the current window. It's showing all the contact's details. Selecting "edit" from the menu will open yet another form, allowing you to edit the contact. The "Tasks" applicatoin behaves just the same way.
So the user knows: Clicking somewhere will open up a new form, and closing that form will get me back to the last form. You should work with that knowlegde rather than against it. When you use a single form, the user might repeatedly close it while he actually wanted to get back to tha last form.
From a performance point of view I find that forms open fast enough (<1 sec) on my WM 5 and my WM 6 devices.
And while it's possible to achieve form-like behaviour with UserControls, it seems more straitforward to use forms when you need form-like behavior.
So my bottom-line is: Use Forms!
P.S.: There's a good article on CodeProject on : How to create MDI Application in Compact framework
Depends on the complexity of the form/Control. Going the UserControl route will provide better performance as you will not have all of the form create functionality to also deal with.
My advice is to create a new Windows Form for every different logical action. If you need a form that is logically independent, then is better to have a separate Windows Form for it.
To speed things up you could construct all your forms in application's start up. This way you will have a delay when your application is launching (most users will be OK with this), but afterwards everything will run faster.
Related
Rather than have a large collection of small desktop applications, I was wondering if there's a way I can combine them into one 'Master Form' with links to each?
I have many similar applications and the ideal situation would be to have almost like a website hierarchy, where the user can navigate to the application they want.
I have considered a solution that sits on top of the rest and calls the others in some way, but I can't find if this is possible or not, is every separate application effectively stand-alone?
Yes you can directly disign on master form for it.
keep menus for each exe(Application) and,
give command in following way for onclick of that menu in master>>
System.Diagnostics.Process.Start("billing.exe",strCmdText);
Or directly Process.Start("C:\\");
I'm working on somewhat large application that is divided into groups by functionality. Since every functionality is mostly independent (they all use the same database, but there is no direct interaction between different functionalities), I'm using the user defined controls and treating them as individual "applications". The way the application works is this:
The "root" application only contains the main menu and 2 panels. The main menu is used to select the group of functionalities.
After the group is selected (on application startup the first group is automatically selected), the functionalities (represented by buttons) from that group are displayed in the first panel.
The user selects the functionality (by clicking on the appropriate button) he/she wants and the user control that contains the "form" is displayed in the second panel.
The code that displays all of the user controls looks like this:
panel2.Controls.Clear();
UserControl1 uc1 = new UserControl1();
uc1.Location = new Point(0, 0);
panel2.Controls.Add(uc1);
label6.Text = "User control 1";
So, when the user selects one of the functionalities, the application clears existing controls, and displays the selected one.
The application works fine (the part I implemented so far), so this is my question - how does this approach manage computer resources, mainly the memory. Specifically, if the user uses one functionality, and then switches to another one, will the .NET's services release the memory used by the previous functionality (I think garbage collector is in charge of that) and will the SQL connections, that I use to communicate with the database, be closed?
Also, are there some other issues that I should be aware of?
As I said, the functionalities work properly, but I'm still very far from full testing of the application as a whole (I only test every functionality individually when I create it, and only on the computer I create it on, so I can't consider it as a proper testing). Because of that, I am worried that the application's performances might deteriorate if the application is constantly used over a longer period of time.
I'm using VS 2010 (C#) and SQL Server 2005 to create this application.
If you have any suggestions, please write them. With this question, I'm trying to prevent major reconstructions of the application once it comes to the phase of testing and implementing due to bad resource management.
Thanks.
Garbage collector is in charge of freeing up the memory that belongs to objects that are not referenced anywhere. If your Windows Forms' Form shows many controls at once, they are all somehow referenced by the form at the time, so the GC won't clean anything up here, you need to be careful not to load too many objects in these controls. Furthermore, you may run into memory issues if you do not properly Dispose the controls before calling the panel2.Controls.Clean().
I'm creating an application like this too. What I experience is a lot of difficultys when it comes to managing the controls (See my question here on stackoverflow)
My expectations are that the memory used by the application can become a lot. You should close controls you do not need anymore to prevent this. Also the connections with SQL, I'd reccomend to open/close them manually, so you can be sure there are no conflicts later.
I am working in a Windows Forms application, it needs a lot (and I mean a lot) of controls. Using tab controls to organize them (sometimes nested tab controls).
I was reading how to load the App faster and a lot of people said to think twice if the controls are really needed. Well, to be honest I think that it's possible to reduce the number of controls used BUT the client requested it that way, so there's almost nothing I can do about it.
I was reading that I should use multithreading tactics but there's a hardware limitation: the application MUST run on an average neetbook. It's really a pain because I'm limited in terms of load time and how much space I can use to put the controls.
I was wondering if I can just load one or two tabs before the form is shown and then load the others, would that be possible/correct/efficient? If it is, how could I achieve it? I also was planning to use MDI childs but I need to retrieve all the information in all the controls at some point (from absolutely all the tabs and nested tabs).
Can you please give me some tips? Do you have any experience working on something similar?
One strategy is creating your main page with a TabControl holding empty TabPages.
Then you can design several auxiliary forms (one for each TabPage you require) each containing a single Panel control with Public visibility (change the Panel's Modifiers property to Public) holding the real UI elements that you would have placed on the TabPage.
When the empty TabPage is clicked by the user, then you create the auxiliary Form (you don't show it, just create it), and then access the Panel control in the auxiliary Form, then you can reparent it to your empty tab Page, like this
AuxForm1 frm = new AuxForm1();
frm.MainPanel.Parent = this.tabControl1.TabPages[0];
This will delay the TabPage's control creation until the panel is clicked by the user :)
Hope this helps!
I was wondering if I can just load one or two tabs before the form is shown and then load the others
You could make each "tab" contain a UserControl, and load that UserControl on demand, when the tab is activated. That would, at least, prevent you from having to initialize everything on startup.
"lots of controls" is not a requirement anyone can answer. A dropdown list with tens of millions of rows is a very different problem than a wizard UI with thousands of steps and require different answers.
Why has the client "requested it that way"? We need to know the actual deliverable requirements to answer your question. Have you shown them alternatives?
First, post some of your mockups. If you don't have mockups yet, make some and perform paper testing with them, then post them.
Who's "a lot of people"? Testers? Customers? Anonymous forum posters? Post your mockups to https://ux.stackexchange.com/ and ask for comments.
"I can just load one or two tabs before the form is shown"? Of course you can do that, but why are you presupposing that your UI will be "one or two tabs" before you have shown us any requirements at all? Get requirements, make mockups, then ask specific, answerable questions.
I am working on a WinForms project which feels sluggish. It is composed of a literally hundreds of User Controls. If there is a piece of a UI functionality (even if not used anywhere else in the app), it's encapsulated in a User Control. I've gone through the project a number of times with the ANTS profiler and most of the heavy code appears to be in various control constructors.
Before I start ripping out User Controls, do they represent significant overhead to a WinForms application versus just laying out the form without User Controls (e.g. just intrinsic controls)?
A user control is a container for other controls. Having hundreds of them probably means you have multiple hundreds of windows in your project. A window is a very expensive operating system object. They start to noticeably drag down painting perf when you have more than 50 or so.
The comparison to Outlook is apt. That's a good sized chunk of a program. It has less than 50 windows. Easy to see with Spy++.
The difference is OnPaint. Microsoft wrote a lot of code, they didn't drop a lot of controls on a form.
I've been in User Control hell and it's not fun. A few things I've noticed:
If you have too many user controls and move your form around or scroll, you can wind up with a lot of white flickering as the drawing operations of deeply nested window handles fight for rendering time. This is particularly noticeable when you first open up the form.
Beware of nested user controls in the designer. If you open a user control in the designer, the constructor won't be called (it actually generates the designer surface by parsing the compiler-generated code.) However, user controls used by that user control will have their constructors called. This is usually not a problem, but it's worth knowing about if you see odd things happening.
If you have a large solution with lots of user controls, VS 2008 will take a long time to enumerate all of your projects to find all possible controls the first time you open the designer pane. This is a relatively minor annoyance, but it can consume time.
That said, User Controls are definitely handy and worth using in moderation. The main thing I try to avoid is overly deep nesting. I've found that WPF is much better in this respect. It has full control over the rendering pipeline, so you don't get the repainting issues associated with deep composition of controls.
So I would consider myself a .Net and ASP.NET pro but I am a bit new to Windows Mobile (I am targeting .net 3.5 CF and Windows Mobile 6).
I am creating a data driven application that will have 3-4 tables. I have created a form for each table that allows the user to search through the table.
Each form inheretes from the Main form so that they each have the same Menu.
My question is how do I make sure that only one Window is open. I want to allow the user to go to the menu and choose a table which will open a new form. What I don't want is for the user to open say each form and then when they are done to have to close 3 or 4 windows. Is this possible? If so how do I do it? On a side note is there a better way to do this. I don't want all my logic on one form. So I don't just want to hide and show and panels.
I keep something I call an application hub that everything goes though.
So each menu click will call the applciation hub, and each form will reference it.
Then, when switching form, the application hub needs to keep track of the current form, close it, then load the requested form.
This isn't much code to write, and performs well.
Or...performance wise, keep the application hub idea, and keep the dialogs open. It will perform better that way, rather than having to reload the forms all the time.
Then on shut down, the application hub can check which forms are open (it should have a reference to each running form) and close them for the user.
Instead of having multiple Forms (inherited form mainForm) you could put the table stuff on UserControls and have total control about their Creation/Destruction/Visibility much easier.
Use an Interface or a BaseUserControl to implement common functionality.
This article, while not exactly what you are asking, was very helpful when I was redesigning a .NET CF application: Creating a Multiple Form Application Framework for the .NET Compact Framework
My application required a bit of both worlds - I wanted to have a single form open, but also sometimes wanted to stack a secondary form on top of the first (eg. if they go to a Prefs page or some other type of form where they should only ever dismiss it after a moment).
(Pseudo-coding after this)
I created a ViewManager and implemented it as a singleton. When the app first launches, I call ViewManager.GotoForm(frm). This sets the current form to be whatever form I need.
Then I immediately call ViewManager.CurrentForm.ShowDialog() - I'm sure there's a better way, but I found I had to call ShowDialog() at SOME point just to get a form to appear.
Subsequent calls to ViewManager can take the form .ReplaceForm or .StackForm. The differences should be fairly intuitive.
What you can also do in a view manager like this is cache forms that aren't being displayed, but probably will be again and have expensive setup costs (for instance, in a data-driven app you might have to query the database to determine the fields or tables to display on a form, and this won't change at runtime).
The trick here is that you never call .Show() or .ShowDialog() anywhere in your application - you route all form navigation through the view manager which handles loading the next instance of your form, disposing of old forms (if not being cached), and dispatching any sort of populate logic if you want to pass new data to a form's UI before it loads.