December 2005 - Posts

Windows Mobile 5.0 SystemState on a background thread

In Windows Mobile 5.0 we have been given the SystemState class, which allows us to easially pick up on common System events, such as a new SMS or low battery power.

However, trying to use this class without a a Form seems to be not possible! For some reason the code needs a Window to work, yet i want it to work on a background process.

The best compromise I could think of was to use this technic from David Wrighton, in which you instantiate a Form, and hide it. It seems this has the extra benefit that it will appear in the 'Memory'->'Running Programs' control panel :)
posted Monday, December 19, 2005 11:38 AM by andrewwhitten

VMWare 5.5 upgrade.. USB Issues

There are many reasons to use VMWare and not Virtual PC. As a mobile developer, one of them is its USB support, which is a requirement when developing on a physical device.

Well, the VMWare 5.5 upgrade has just been released... and it has an issue.

I run my virtual machine under a limited user account, which is good practice for any developer. (Annoying? Maybe.. Safe? Certainly)

To use a USB device, VMWare sometimes requests to install a particular driver, which requires Administrator rights, and a 'run as..' dialog box appears to let me install it with my admin credentials.

VMWare 5.5 no longer offers this dialog box, so the only way to run USB devices is to run the virtual machine under an administrator account. This is a key advantage which VMWare has lost, and I'll certainly be interested to see if this gets fixed before the new Virtual PC comes out :)
posted Sunday, December 11, 2005 5:28 PM by andrewwhitten

Keeping an object alive in a Console application

It seemed pretty simple task... have a console application run as a service in the background, and do so on both .Net 2.0 and Compact Framework 2.0 ...

Well, I couldn't seem to find a good way apart from having an infinite while loop after my object, keeping it alive forever..

Tim Gerken (No link, but I'm pretty sure this guy) helped me out by suggesting I use the System.Threading.AutoResetEvent synchronization object, which will hold the current thread for me until which time I choose to release it.

posted Sunday, December 11, 2005 5:19 PM by andrewwhitten