Tag: windows mobile

Tech in the 603, The Granite State Hacker

Compromise & Capitulation

Jim Wilcox (The Granite State Hacker)

There’s three different flavors of Windows Mobile in the 6.x line. Standard, Classic, and Professional.

Standard = Smart Phone, no touchscreen
Classic = PDA w/touchscreen
Professional = PDA / Phone with Touchscreen

One of the other interesting little gotchas is that the .Net Compact Framework 2.0 compiles the same for all three editions. Unfortunately, once in a while, you get a “NotSupportedException” out of the Standard edition.

A few days ago, in order to get my sudoku program published, I decided to simply avoid a problem I had with the Standard edition’s lack of a SaveFileDialog and OpenFileDialog. My avoidance manifested in a “not supported” message of my own, if the user tried to save / load a file in that environment.

Today, I capitulated… I implemented an alternative file save/load functionality which kicks in automatically when the program gets a “NotSupportedException” on the common dialogs.

It’s in 3.0.3, which I’ve re-published on PocketGear.

Tech in the 603, The Granite State Hacker

Jimmy SuDoku 3.0 Released

Jim Wilcox (The Granite State Hacker)

Those of you who have worked with me on a project in the past few years probably know of my hobby project. It’s an implementation of SuDoku. It’s made for Windows Mobile devices (cell phones, etc.), but it also runs on Windows XP (et al).

The old version, 2.5, had been published on PocketGear. This last update was published in January, 2007, just before I started with Edgewater.

I’ve been hacking at it here & there since then, but the project suffered from lots of maladies… most significantly lack of time.

So after more than a year and a half, I’m happy to finally announce Jimmy SuDoku 3.0!

3.0 has a whole new game state model, based on CLR classes rather than an XML DOM. This means the puzzle generator’s fast enough on hand-held devices that it doesn’t need a web service to do the work for it. Another side-effect of this change is a smaller run-time memory footprint, though I’m not sure by exactly how much.

I also figured out how to leverage the hardware controls on WM6.0 & 6.1 devices so that non-touchscreen devices can play, too.