Before using EventLog.WriteEntry for adding events to event log you should consider calling EventLog.CreateEventSource to make your application a valid source of events. Keep in mind though that you need administrative privileges for it succeed, therefore it is best to call it at installation time. So, if you want to write to the application event log by calling:

EventLog.WriteEntry("MyApplicationName", "My event text");

don’t forget doing this first:

if (!EventLog.SourceExists("MyApplicationName"))
   EventLog.CreateEventSource("MyApplicationName", "Application");

If you want to view EPS images with IrfanView you need to have AFPL Ghostscript installed. I spent quite some time investigating why it worked on one machine and not on the other before I checked the IrfanView plug-ins web page where I found this useful bit of information.

Essentially everything you need to implement plug-ins in your application is some way to dynamically instantiate classes at runtime. As long as they all implement the same interface, you just use it to access its properties and methods.

In COM world this was achieved by calling the CreateObject function. In the managed world you should use AppDomain.CreateInstanceAndUnwrap as demonstrated by the following example:

IBind pluginInstance = (IBind)AppDomain.CurrentDomain.CreateInstanceAndUnwrap("MCPP", "DamirsCorner.Samples.LateBinding.MCPP");

Everything you need to know at runtime is the full class name (including the namespace) and the containing assembly. To get those you can either require their previous registration within the application or you can dynamically discover them by loading assemblies from a predefined location (Assembly.Load or Assembly.LoadFrom) and enumerating their classes (Assembly.GetTypes) whichever suits you situation best.

Either as a user or as a developer you have certainly noticed that sometimes the application just flashes in the taskbar instead of actually coming to the foreground when the SetForegroundWindow function is called. What you might not know is why and when this happens.

As far as the why goes the Application Compatibility Toolkit’s Compatibility Administrator puts it very nicely in the GiveupForeground compatibility fix description: In Windows XP the foreground semantics have been changed to stop foreground focus stealing by one application if another application is active.

Further investigation reveals that this is related to the ForegroundLockTimeout value. It defines how much time must pass since the last user input to allow another process to force its window into the foreground. Before that time such a window only flashes in the task bar. The default value is 200000 milliseconds. The setting is stored in the registry:

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

The value can be programmatically changed by calling the SystemParametersInfo function as follows:

SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);

The downside is that the call only succeeds when the calling thread has permission to change the foreground window which usually isn’t the case.

To make the long story short: you should never depend on being able to bring your application window to the foreground and this will certainly only get more restrictive in the future. If the flashing in the taskbar is not enough, you should consider using tray balloon pop-ups as the alternative way of notifying the user.

By default the Windows XP Welcome screen shows the users created through the control panel applet. Administrator is shown only if it is the only account with administrative privileges. You can change all that by setting up the correct values in the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

To change the default behavior for a user create a DWORD value with its name identical to the account name and set its value to 1 to show it or to 0 to hide it.