We Keep Coding

Keeping UserControl in memory

My application is a window with a main grid which will contain my pages (the User Controls).
I want to be able to navigate in the history of the previous user controls displayed.
That's why I'm storing in the memory the last 30 user control displayed. My code looks like this when displaying a new UC :
MyHistoryPage page = new MyHistoryPage();
page.AssociatedUC = (UserControl)this.mainGrid.Children[0];
this.mainGrid.Children.Clear();
this.mainGrid.Children.Add(new MyCustomUC());
All my "MyHistoryPage" are stored in a static list.
This works great, I'm able to get the previous Ucs in the same state (same sort, same checkboxes checked, same scroll, same tab selected etc.) and give the user a good experience.
However it seems to cause memory leaks or at least it seems to slow down my application. The mouse over effects are becoming slower and slower.
Dot Memory obviously tells me that the memory used has become bigger.
Is it good to store a lot of UI components in the memory to use them later ? What would be a better solution to manage history and have my UCs in the same state ?

What about trying to migrate your application to a MVVM pattern?
The ViewModels are not recreated everytime you access to a previous userControl, so the state could be the same and you will not have memory issues.
If you are not used to work with this pattern you can use many of the available toolkits to start like MVVM Light, Caliburn.Micro, ...

Adding controls conditionally

I am currently working on this big project (a GUI to control hardware) that was written in C# with .NET 3.5. Now the next revision of hardware will be coming, and some of the changes are such that some of the controls that we had before are not needed, and some new controls need to be added too. Since the changes are huge, it would require almost a month to go through every control and put a condition to make it visible or not.
I was wondering if there is any other way to tackle this problem easily other than manually conditioning the whole project. Thanks in advance.

If you can make the decision to make visible or invisible based on some attribute of the control, such as its name, or tag, you could write a method that could walk a window's controls, and programmatically hide the ones you wanted hidden. For controls like a label you might key on the text of the label.
Written correctly the method could be written so that it is re-entrant so that for controls that contain other controls, the method would call itself for each of the current controls children.
The hardest part about this would be to determine how to decide programmatically make the on or off decision.
If that's not possible, another solution might be to write a small app that would read the code and list the controls you want to examine, allowing you to make a decision based on your knowledge of the application. The app then could make the changes necessary to set an attribute on the control in code so that its hidden when the code is compiled.

You usually have to design for these kinds of things, and by the sounds of it, it isn't designed for this.
but quite often, this kind changes appears quite large, but often isn't THAT big of a deal.

Cut,Copy and Paste Any UserDefined UserControl from/on the MDIForm

I am creating many usercontrols in an windows application in C# 3.5. I want to copy any usercontrol and paste it on another location of the MDIForm. Similarly in case of Cut option. I am using these three options in a contextmenustrip. And theses options are visible when I right click on the usercontrol. Can anyone tell me how It will be done at run time?

That requires giving the controls a new Parent. Explicitly supported by Winforms, they can even have no parent, quite a trick. You can do it directly by assigning the Parent property. Or by adding the control to another Controls collection, it will be automatically removed from the one it was in before.
Be careful, this flexibility comes with a price. It is also a source of a nasty leak that can crash your program after a while. That's caused by the no-parent trick, otherwise triggered by a Cut without a subsequent Paste. If you use Controls.Remove() or Controls.Clear() then the control is moved to the 'parking window', an invisible window created by the Winforms plumbing that acts as a temporary host. If you then don't either move the control to another parent or forget to call its Dispose() method then the control will live forever. Until your program runs out of resources or the user terminates the program.
The out of resources bomb ("cannot create window") typically happens after a few hours so is easily missed when debugging. You can see it in TaskMgr.exe, Processes tab. View + Select Columns and tick USER objects. Also tick GDI Objects and Handles to feel good about your program not leaking.
If you put the controls on a Panel then you can move them all together with just a single line of code by moving the panel.

You could remove the control from the ControlCollection in case of cut and cache it to add that control to some other form when pasted like you could do
panel1.Controls.Add(newPanelButton);// To add, you might have to change the control `Location` as per your need
panel1.Controls.Remove(newPanelButton);//To remove
In case of having cut/copy effect on the same form you could just change the Location of the control to the new location where you want to paste that control.

Prevent controls from being redrawn in C#?

I have a form that contains a lot of runtime generated controls (image, button, panel,...), about 100 controls (I'm making a card matching game so there is a lot of controls in the form).
I place the generating code into the constructor and each time the app starts, it took about 3-5s to load all the controls completely.
If I bring another window on top and then back to my app, the controls will be redrawn again.
How can I prevent the controls from being redrawn? If you don't mind, please give me a simple example in C#.
Any help is appreciated!

I found this article that explains how to do this in .NET by calling the WIN API SET_MESSAGE function to set the WM_SETREDRAW flag for the control you do not want updated. Although you can stop certain controls from updating, are you sure you can't approach this issue by reducing the number of controls on the page? 100 Controls seems like a lot and may be an indication that you need to have multiple views.
Enjoy!

My suggestion is to use the form as a drawing surface and draw your card bitmaps directly onto the form. Its not hard to do.
You can add a handler to the form Paint event which will give you parameters with a Graphics object. Use graphics.DrawImageUnscaled to draw each card at the location you want.
This will make the app much much faster.

Preventing a control from redrawing is fairly pointless. You'll get a hole where a control was supposed to appear, your user won't have any use for that hole.
It redraws slowly simply because you have too many controls. You can only get it to redraw faster by using less controls. Or by using controls that can display multiple items in one window, like ListBox, ListView, TreeView, DataGridView.
Note that your specific issue is fixed in Vista and Windows 7. The Aero theme uses off-screen buffering for windows. Which means that windows don't need to repaint themselves anymore when they are obscured by another window. You will however still get slow redraws when the user minimizes the window and restores it.

You might want to consider using a single data table control. A ListView (or something like ObjectListView) may be a good option.
If your data isn't really a list/table, you should split the controls into separate tab pages, which would improve both performance and usability.

GDI handles with icons . l

i have a winforms application. i have a user control with a lot of icons. the user can load this control on a form many times (in a tabbed layout). right now i am loading the icons each time the control is created (could be up to 50 times in teh app). is there any way to cache these icons in the application. if i did this, would that decrease the number of gdi handles that i am using as this is becoming an issue.

You can make a singleton class for each icon. The first reference it creates the handle. Subsequent calls uses the existing handle.
Without knowing more about your user control my next suggestion can be only be very general. But you could have a single bitmap layer on which you draw all your icons. The remaining elements of your user control would exists above and around this bitmap.
Unfortunately this idea may be problematic performance wise. Require you to refactor the code you all ready use for arranging icons. Finally it is non-institutive from how frameworks with a control-form structure ideally works.
We ran into a resource problem with entry forms for the parameteric shape we ship with our CAM software. Too many text entries caused various forms of strangeness and leaks. So we instead created labels with borders that looked like text entries and had ONE text entry (and a combo box entry too). When the user tabs, enters, or clicked the single text entry moved to the new entry and the label was setup for the previous entry.
This is totally a non-intuitive setup than how you would normally code this but it was the only way to deal with our resource problem.
In my experience it seems that GUI Frameworks have issues when you have to deal with dozens or hundreds of entries and that you have to approach the problem using a different design.

If the issue is the number of "icons" (not sure what you mean here) you can use Image-Lists. For example, a Listview control can reference icons in an image-list, instead of keeping a full copy for each item (not sure if this applies to your case though).