Making PN a Good Windows Citizen

22 Aug 2007

By default Programmer’s Notepad is a fairly well behaved Windows application. It stores almost all user settings using either the current user registry key or in the User Settings directory. This means that it should work fine for non-admin users.

There are a few cases where PN is not so well behaved.

Firstly if your version of Programmer’s Notepad comes with pre-shipped tools (mostly WinAVR users) then editing those tools causes changes to the tools files stored in Programmer’s Notepad\tools. This is most definitely bad.

Secondly if you switch to storing your user settings in a file relative to the PN location then you are likely to be storing files under the install directory. This is ok, as it is user choice.

Finally any options that relate to changing associations or shell extension registration require administrator privileges.

Rule: Don’t change files stored in Program Files

Files under program files should be sacrosanct, they are by default not writeable by non-admin users and software should not require them to be. This is causing some delays to the next build of Programmer’s Notepad as I have to re-think some of the code for Text Clips. Currently text clips are not editable inside the UI. I want to allow users to edit clips in the new keyword clips functionality, and therefore I need to allow PN to save changes to text clips files. Where are these files stored? Under the install directory of course.

The current plan is to one-off combine all pre-shipped clips into a file in the user settings directory. From that point on PN will only read from/write to that file.

The other change then is to make the same thing happen with pre-shipped tools. These will be combined on first run into another file in the user settings directory. This is a change to existing behaviour, but shouldn’t be noticeable to users.

Fixing Associations

Before Vista, most users used Administrator accounts. I won’t debate the merits of this, but as of Vista shipping life is no longer quite so simple. UAC in Vista means that by default the user doesn’t have access to system settings. This causes registering file associations or shell extensions to fail in a non-elevated session. Don’t get me wrong, this is a good thing(tm) but it is going to take some code changes…

Programmer’s Notepad needs modifying to allow the process of updating associations to occur in a launched elevated process. This would be signaled using the standard shield icon. For this to work it means hoisting some of the current associations behaviour to allow it to be triggered from a command-line parameter. When the user clicks the OK button in the options dialog Programmer’s Notepad will spawn another elevated instance of itself to create the associations.

Alternatively, on Vista we leave associations to the OS and allow the user to pop up the system-wide associations dialog (above).

Anything Else?

If there’s something else about Programmer’s Notepad that you’ve noticed that is bad behaviour then please let me know!