Click here to Skip to main content
12,698,476 members (23,130 online)
Click here to Skip to main content
Add your own
alternative version


2 bookmarked

Persistent Form Class

, 3 Apr 2013 Public Domain
Rate this:
Please Sign up or sign in to vote.
This article presents a replacement for System.Windows.Forms.Form that provides persistence of position, size, state, and splitcontainer splitterdistance


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!


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.


This article, along with any associated source code and files, is licensed under A Public Domain dedication


About the Author

Canada Canada
No Biography provided

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170118.1 | Last Updated 3 Apr 2013
Article Copyright 2013 by sparky961
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid