Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

An Uncommon Solution to a Common Compact Framework Problem

Use these flexible UncommonDialog dialog classes to lift the restrictions built into the CommonDialog classes delivered with the .NET Compact Framework.


advertisement


he Common Dialog API has been a solid staple in Windows development for more than a decade. In fact, not only is it a useful source of reusable code, it is a fundamental piece of the Windows look-and-feel, providing a familiar interface for users to navigate and interact with the system. As with anything so venerable, it's not surprising that the API has evolved. But it is surprising that it has adapted so readily. In the beginning, the Common Dialog API was unlike the classes and controls familiar to many developers today, mostly because the Windows SDK was originally geared for a C compiler. Developers could—and routinely did—import and alter resource files or hook the dialog's window proc and intercept Windows messages to add a new control. Things got even easier when the MFC (Microsoft Foundation Classes) introduced an object-oriented approach.

Building on that familiarity, it was entirely expected that the System.Windows.Forms namespace of the .NET Framework would include a CommonDialog class and its progeny (ColorDialog, OpenFileDialog and so on)—and it does. While the .NET classes do not provide the same degree of fine turning that the older APIs do, there are still some extensibility features built in. Alas, even these more limited extensibility features do not appear in the first version of the Compact Framework on the Pocket PC. Worse, the designers of the Compact Framework made a few other choices for the Pocket PC implementation that—while perhaps sensible on their face—do not allow for the rich flexibility developers enjoy on the desktop. Most notable is that the OpenFileDialog and the SaveFileDialog classes on the Pocket PC are restricted to the device's My Documents directory. Although there are well intentioned reasons behind this restriction, it can sometimes become more of a hindrance than a help during development. Many applications need to browse the entire file system of the device, most commonly for files located on storage cards. But regardless of the reason for viewing other directories, if you need to tailor the user interface, you have no recourse.

While you can find a few homebrew solutions using various Web search engines, they are typically limited application solutions with no thought toward extensibility. This article covers a set of classes that not only offers an alternative for the lacking Pocket PC classes but an API specifically intended to allow you to extend the interface. Why Reinvent the Wheel?
You could ask, "Why not just use the existing common dialog DLL and just make the appropriate P/Invoke calls?"



That's a valid question. The answer is, "Yes, you can absolutely do that." In fact, cursorily plumbing the System.Windows.Forms with tools such as SharpDevelop and Lutz Roeder's Reflector provides a fair indication that Microsoft is leaning on some native calls for at least some functionality beyond normal form handling (moreso since the base CommonDialog class does not inherit from Form but instead from Component). Creating P/Invoke wrappers does let you create dialogs that can cruise the entire file system and already have all the expected standard functionality; however, that doesn't let you extend those dialogs through managed code. For example, if you wanted to add a new button you would need to make a number of additional unmanaged calls. Although that's not terribly difficult, it is hardly a managed solution. Unfortunately, the problem is muddied further because OpenFileDialog and SaveFileDialog are sealed classes. So, even if you went through the trouble of writing all the unmanaged calls and wanted to package it up you would need to create a wholly new control that provided the same interface as the CommonDialog subclass you were extending. That seems like an unreasonable amount of work just to make a "simple" addition to the interface.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap