-Separated the ToolBar? drop-down menus from the toolbar itself - I didn't want to use the same renderer because the renderer will have to implement menu item rendering too which is what UxThemeMenuRenderer? does. But that only works on Vista+
-Fixed all the overloads for menus in UpdateControlTheme?. Menus/toolbars all use the same interface now.

-Recoded the Toolbar class to work like a standard MenuBar?. This allow for accelerators to work on the menus.
-The UxThemeAPI UpdateControlTheme? function also sets the themes on registered context menus and menu bars. This reduces the number of explicit calls.

-No need to call the base class functions since we handle the function calls
-For drawing the menu text always use DT_SINGLELINE (TextFormatFlags?.SingleLine?) because the menu textshould beon one line - this allow the vertical alignment flags to be used too.
-Destroy the hTheme once we're done with the drawing

Added the UxThemeAPI and UxThemeMenuRenderer? classes. They allow forms to use the new Vista-styled controls (most notably ListView?) and switches menu rendering to the UxTheme? rendering when it detects Vista or later.

Missed out these in the previous commit - the fact that the LogSessions? list was actually more accurately described a Dictionary and that there is no need to assign default values to variables (In the case of FL16KB the assignment is atomic - exceptions come from the function it is calling thus if an exception is caught the variable is not assigned)

-Task.GetPathADSes now no lnoger takes a List reference, but a list instead (lists are passed by reference)
-Task.GetPathADSes now takes an out long for the size of files instead of a ref (out is more appropriate)
-Fixed the ErasureTargetsCollection? class's IsReadOnly? property, Remove and Clear functions

-Remove and clear now removes the target's reference to the task when removed (detaching)

Rewritten the Executor API to factor out all task-list management functions to the ExecutorTasksCollection? class which will be inherited and implemented with each Executor class. Fixes warning CA1002.

-When using ToString? pass the current culture, and when using string.Format specify the current culture.
-When using MessageBox?.Show, tell it to display the dialog RTL when the parent control is in RTL mode.

-Do not initialise class members to default values (runtime will handle that)
-Deserialisation constructors should be marked protected for unsealed classes
-Classes implementing ICollection should end with Collection (Mainly fixed here is ErasureTargetsCollection?)
-ISerializable.GetObjectData? should be marked virtual
-Use proper camel casing (Prng, Guid, FileName? etc)
-Enumeration values should be Camel casing
-Bitfields should be marked with the [Flags] attribute
-Implement the proper IDisposable pattern - one Dispose() and one Dispose(bool) - the latter doing the clean ups for both Dispose and finalisers
-public variables should instead be properties
-Abstract classes should have protected constructors
-Renamed Schedule.Type to Schedule.ScheduleType? to prevent ambiguity with GetType?()
-There shouldn't be a need to pass reference variables by reference

Ran Static code analysis on the Eraser project and implemented a few recommendations.

-Use more specific exceptions to allow code to determine the type of exception.
-Made GUIProgram implement IDisposable since the global mutex must be freed.
-Mde AboutForm? implement IDisposable, clearing the caching bitmaps on dispose.
-Made a few CommandLineProgram? functions static since they don't reference this.
-Name parameters/local with more unique, descriptive names for clarity.
-Use EventHandler?<EventArg?> instead of declaring our own delegate and event types as the type of the evenr handler

Implemented a more generic message when the dialog containing the progress of the erase is shown, so that the user will know that he has to wait for progress information to come from the executor. Fix for #173.

Using FileInfo?.OpenRead? will cause a file to be locked. In our case, the file doesn't need to be locked so open a file handle, allowing other applications to share access. This handles locked files better in tasks.

-Handle files which are currently locked by another process - currently the behaviour is to log the file as unerased and flag the task as an error having occurred
-Handle sparse/compressed/encrypted files without throwing an exception because that will cause the rest of the files to remain unerased