Windows CE provides two different implementations for most of these dialog boxes: one designed to fit on a display that's 480 by 240 pixels or larger, the other designed to fit on a 240- by 320- or Palm-size display. If neither of these fits the display you're working on, you will have to implement them yourself. The Windows CE Platform Builder 2.12 provides the source code for the Control Panel applets (\Wince212\ Public\Wceshell\Ctlpnl). You should be able to resize and change the dialogs and rebuild the applets. These are built into .DLLs renamed to .CPL.
But overwriting GetOpenFileName() and GetSaveFileName() is much more complicated. Basically, you will have to implement your own custom shell. For more information on how to implement a custom shell on CE, see www.msdn.microsoft.com/library/techart/customshell.htm.
The RAM on a Windows CE device is divided into two sections—one for storage memory, and one for program memory. The program memory is the memory that's used to execute programs, and the storage memory is for saving files very much like the hard drive on a PC. The amount of memory allocated for storage and programs can be adjusted by using the System Properties Control Panel Applet, or programmatically via Get/SetSystemMemoryDivision API methods. Because the memory available on CE devices generally is a lot less than on PCs, it's important to make your programs both smaller in size, and more efficient in memory usage.
Reduce Library Overhead
Application libraries, like MFC or ATL, are a very popular way to write programs for desktop PCs. While both are available on CE, they greatly increase the size of your program. For example, the MFC libraries are about half a megabyte in size. Unless you know that the platforms you are targeting have these libraries in ROM, you may want to think twice about writing your program using these libraries. If you do expect those libraries to be in ROM, and you link your application to them dynamically, the overhead will be significantly reduced.
Several interpreted languages, like Visual Basic and Java, are very popular for writing applications on desktop PCs. They also are available for use with Windows CE. Make sure that the interpreters for these languages are in ROM, because they are normally very large. Also, be careful about performance. As you might expect, these smart devices have less program memory available than desktop computers. Therefore, you want to be certain that the limited memory available to these languages doesn't slow things down too much.
There are many ways to save program memory in your applications. One way is to allocate memory only when you need it, then delete it as soon as you no longer need it. A few objects that require a lot of memory are bitmap images and icons. Another way to save memory is to load these objects only when they are displayed. The ListView control is often used to display icons. Make sure you use a virtual ListView in Windows CE. The advantage is that only the icons currently displayed will be loaded. You can find more information on how to use a virtual ListView at www.msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/vcspvlistvw.htm.
You Have To Make The Adjustment
One challenge facing Windows developers is the adjustment to Windows CE versions of the tools they are accustomed to using for desktop Windows applications. MFC is available on Windows CE, as was mentioned earlier. In addition, IE4, COM, ATL, and VB are available. Support for more tools is being added all the time. But these tools often feature less functionality than their desktop counterparts. Compared to the desktop Windows version of MFC, for instance, some MFC classes aren't supported.
Further, the CE COM library doesn't include support for out-of-proc servers, etc., as does the desktop version. Ultimately, if you expect to rely heavily on one of these tools, or if you are porting a desktop Windows application that does so, it's best to investigate the available level of support on Windows CE early on in order to avoid any unfulfilled expectations down the road.
Developers of system software for desktop Windows sometimes need to debug their software remotely. But for Windows CE developers, remote debugging is the rule, not the exception. Fortunately, Microsoft's Windows CE development tools, like the Windows CE Toolkit for Visual C++ 6.0, include a variety of debugging options. These make debugging a CE application almost as easy as debugging a desktop application. With the Windows CE Toolkit, you can debug over a serial connection using the TCP/IP transport. Or for much faster debugging, you can do so over an Ethernet connection.
For debugging H-PC and Pocket PC applications, Microsoft's H-PC and Pocket PC emulation environments provide an alternative to remote debugging. Build your application against the emulation libraries, and then it can be run and debugged on your Windows desktop computer.
Developing software for Windows CE is similar to developing software for other Windows operating systems. The basic programming model is identical, and the tools are very similar. The much wider range of CE platforms, though, can introduce a desktop developer to the more diverse environments of embedded devices, even as his or her prior experience in programming for Windows constitutes excellent preparation for the nuts and bolts of Windows CE application programming. Conversely, the well supported Windows development model and tools make it easy for anyone wishing to write an embedded application to do so for Windows CE. Developers interested in receiving Windows CE training can find information at www.microsoft.com/windowsce/Embedded/news/training.asp or www.bsquare.com.