Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Persistent Form Class

0.00/5 (No votes)
3 Apr 2013 1  
This article presents a replacement for System.Windows.Forms.Form that provides persistence of position, size, state, and splitcontainer splitterdistance

Introduction

Full credit goes to Joel Mattias for providing the code that this is based on.  It's an older article, so maybe I missed another way that people are solving this these days.  It seemed like one of the better solutions I found while searching, so I ran with it and added my own touch of usability.

The class presented in this article inherits from System.Windows.Forms.Form and thus is a drop-in replacement with the added benefit that the form will be shown in the same position, size, and state every time it is loaded by your application. 

I was very surprised not to find such functionality built into the framework.  If I missed it in my search, it needs to somehow be made more obvious!

Background   

The original article and code this is based on may be found at the following link:  

Using the code   

Using this class is as simple as adding AppForm.cs to your project, adding a reference to the namespace, then inheriting from it.  This will not cause problems with forms generated by Visual Studio.  

using RestoreFormState;

public partial class myForm : PersistentForm /* Form */
{
    public myForm()
    {
    }
} 

The namespace could perhaps be made a bit more relevant, but it remains from the existing code.

The persistent data backing this class is stored in the system registry under "HKEY_CURRENT_USER\Software\[Application.ProductName]\WindowState".  Keys are automatically named using the form name, property name (and control name in the case of SplitContainer).

Testing has been minimal at the time of posting this article, but so far it seems very stable and reliable.

Points of Interest 

Since starting out with Windows 7 a while back, My "standard setup" is to put the taskbar at the top of the desktop.  Why in such a strange place, you ask?  Well, virtually every other program's menus are up there too!  Try it out and you might just find that your mouse gains weight due to less exercise.

Why is this relevant?  Since adopting this setup, I've found MANY programs that assume they can stick windows right at the top of the desktop, behind my taskbar.  I can either move the window using shortcut keys, or auto-hide the taskbar, move the window, and un-auto-hide it.  Not very fun, let me tell you.

I bring this up because I would love for someone to take this code and extend it so that it much more intelligently handles window positioning.  Multiple monitors, off-screen windows, and other annoyances could be handled by such a class thus improving the user experience considerably.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here