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.
Related
This might just be a small quirk. But I've built a small windows form application with multiple tabs.
I have a feature that allows users to "load" the entries in each of the tabs by opening a json file. This lets them avoid manually inserting the data. At the same time, I have a "check" to make sure that all required fields have been populated.
What I've found is that even if the load process is successfully populating all the right fields, the user still needs to select each tab (even though they are already filled), in order to avoid hitting the flag.
Hopefully, this makes sense. Right now, my work around is to have the program flip through each tab automatically upon "load", but it seems strange that winforms can't detect a text box has been filled unless the tab is viewed.
Any advice?
Some events only fire when the control is visible. This sounds like what you should do is decouple the text entries from the control and store them in another object which fires off the filled events then do data binding to those entries.
This has the nice benefit of decoupling the UI from the data storage (always a nice thing) as well as freeing you from the vagaries of the .net UI system (both winforms and wpf have 'interesting' quirks like the above which assume specific behavior preferences).
I just inherited a C# windows application codebase. It's a relatively large application with lots and lots of UI "elements" that I believe may have been added by the previous developer with little to no interaction with the actual clients. This application is a robotics control system, it runs at a manufacturing facility, and it has some of the most complex UIs I have ever seen (forms inside of forms inside of tabbed elements inside of etc...)
One of the first things I want to do, is learn about how the actual plant floor associates interact with this application. I have already sent out a survey to the different supervisors, but I would like some empirical data as well.
What I would like to do:
I would like to somehow, capture every time a user presses a button, control, etc... and record it to a file. Something simple like:
timestamp,name of control,any other cool data I can capture (program run state, for example.)
The difficulty is that I'm not really a C# expert at this point, and I can't figure out the appropriate way to add some sort of global behavior to my application which does this, and doesn't impact existing functionality. Any advice would be greatly appreciated.
Global keyboard and mouse hooks would be the way to go. Unless someone knows the design thoroughly and can comment how to extend existing functionality. it is going to be bit difficult.
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 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.
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.