Pocket Scribble – Part II

This is the second part of the Pocket Scribble tutorial. If you haven’t looked at the
first part of this series yet, I will strongly recommend that you take a look.

In part one, I showed you how to install and configure Microsoft Embedded Visual C++ and porting the Scribble MFC tutorial to Pocket Windows. We ended up with an application that worked, but with several flaws. The source code was pretty standard MFC code using the document/view architecture, and did not really exercise any Pocket Windows specifics.

In this part I will fix the problems, and discuss some of the Pocket Windows specific classes and API’s that you should use.

Last time I pointed out these problems with Pocket Scribble:

  • Why is everything I have drawn gone when the main window has been covered?
  • How can I save the files with the ‘.scb’ extension so I can open existing files?
  • Is the file format compatible with the PC version of Scribble?
  • How do I save my work? There is no OK button in the corner of the window. I can only choose ‘Save As’

So fire up your Embedded Visual C++ IDE, and go get a cup of coffee while it loads.


Before we begin

During the steps in this article you will often recompile the Pocket Scribble to try out new versions. You may experience that you cannot upload new versions of Pocket Scribble to the device, because the file is in use. This is because the application is open and there is no way to close it. Later in this article I will look at adding functionality to the application so it is possible to shut it down gracefully. Until then, just close the application the hard way using either the Memory applet in the Settings folder – or if you’re working in the emulator, you can close PocketScribble by using the task manager.

In some circumstances you may experience that the emulator hangs. You cannot restart it by closing it normally, and there is no way out but using the task manager. When doing that, you should kill the process named shell32.exe. You may need to restart Embedded Visual C++ too.

If you want to use the ClassWizard for adding event handlers to the document (scribdoc.*) and the view (scribvw.*) you may need to rebuild the ClassWizard file. In Embedded Visual C++ this file has a .VCC extension. To recreate the ClassWizard information delete the file PocketScribble.vcc and then open the ClassWizard. When asked if you want to build a new one from your source files answer yes, and click the “Add All” in the following dialog before clicking OK.

Redrawing the view

When I got the first build of Scribble running in the Pocket Windows environment it seemed like it actually worked “out of the box”. But after playing around with it for a while the problems began to appear.

One problem is, that when you do something that obscures the Pocket Scribble main window, everything you have drawn disappears – or to be correct: it is not redrawn -the data is still there!

When something is not redrawn after being obscured, it is typically something that can be found in the OnDraw() override of the view class.

Before the actually drawing takes place, the device context is prepared with some calls to the API function LPtoDP(). If you take a look at the documentation for this function in MSDN, you will se that they state that this API-function is not available on Pocket Windows, and that it actually does nothing with the data transferred to it.

This is a problem because the Scribble application assumes that the drawing coordinates are prepared with the call and not just left untouched.

Therefore I will remove all references to LPtoDP() from the OnDraw() handler. Doing this will have the unfortunate side effect, that the drawing optimisation done in the original application is lost, and the result is slower screen updates. I will not go into optimising the drawing behaviour here, because it is beyond the scope of this article.

Below is shown how the code for the revised OnDraw() handler.

void CScribbleView::OnDraw(CDC* pDC)
 CScribbleDoc* pDoc = GetDocument();

 // Get the invalidated rectangle of the view, or in the case
 // of printing, the clipping region of the printer dc.
 CRect rectClip;
 CRect rectStroke;

 //rectClip.InflateRect(1, 1); // avoid rounding to nothing

 // Note: CScrollView::OnPaint() will have already adjusted the
 // viewport origin before calling OnDraw(), to reflect the
 // currently scrolled position.

 // The view delegates the drawing of individual strokes to
 // CStroke::DrawStroke().
 CTypedPtrList<CObList,CStroke*>&strokeList =

 POSITION pos = strokeList.GetHeadPosition();
 while (pos != NULL)
  CStroke* pStroke = strokeList.GetNext(pos);
  rectStroke = pStroke->GetBoundingRect();

  //rectStroke.InflateRect(1, 1); //avoid rounding to nothing
  //if (!rectStroke.IntersectRect(&rectStroke, &rectClip))
  //	continue;


The lines shown in bold are the lines modified to make the drawing behaviour work.

Now try to compile the application and try it out in the emulator. Make sure that the build settings are correct – that is the ‘Win32 (WCE x86em) Debug’ target and ‘Pocket PC Emulation’ are chosen.

To test that it works choose Tools -> About Pocket Scribble to show the about box and obscure the main window. When the aboutbox has been closed your artwork should still be visible.

How do I save files with the right extension?

If you have played around with Pocket Scribble you may have noticed that it is possible to save your work in a disk file, but the file type is not listed in the Save As dialog. Instead you are presented with the option of saving your work with the type “All Files (*.*)”. This is not very intuitive.

It would be desirable, if a file name with the right extension was suggested, and the file type was listed as Scribble document.

The reason that there is not provided a file extension to the filename and a file type, is that the resource identifier IDR_MAINFRAME is not complete. In the application wizard for Visual C++ for PC/Windows, you are presented with the option of customizing you data file properties. This option is missing from Embedded Visual C++, which I consider a serious bug.

The only thing we need to do is to change the string resource entry IDR_MAINFRAME. Go to the string table in your resource file and change the string


PocketScribble\ndefault.scb\nPocketScribble\nScribble Files (*.scb)\n*.scb\nPocketScribble.Document\nPocketScribble Document

Now try to compile everything, load the application into the emulation environment, create a new file and choose Tools->Save As. Now the dialog behaves as expected.

Is the file format compatible with the PC/Windows version of Scribble?

The short answer is yes!

The file formats are compatible because it is the same code that is used for serializing the document. Scribble document files does not need to be converted before they are used in a PC/Windows environment.

How do I close Pocket Scribble?

It is rather inconvenient exiting Pocket Scribble. If you want to close the program you will have to do it from the Memory applet in the Settings folder. The official Pocket Windows way to do it is to add an OK button in the upper right corner of the main window.

The behaviour is not added in the source files that we copied from the original Scribble project in the last article. If you choose to create a project from the scratch by using the project wizard, this behaviour is enabled by default. We will add it manually.

Using the ClassWizard add a WM_CREATE handler to you CScribbleView class. In the implemented function OnCreate() you should add the following code:


That’s all. Compile and run the program to verify that everything went OK.

Your Pocket Scribble should now look something like this. Notice that the clicking the OK button will not save your work. I’m not sure I think this is very smart default behaviour.


These two articles should be enough to get you started porting your existing application to Pocket Windows. I have focused on Pocket Windows development using MFC, knowing that MFC does inflict a certain overhead that might not be desirable.

However the speed and memory penalty from using MFC is not really significant on a device with tens of megabytes of memory and 100 to 200 MHz CPU’s.

It is a lot simpler creating and porting software to Pocket Windows that one might expect, and I think the future is bright for these small and cool devices running full blown 32 bit operating systems.

If you have comments to the article, please don’t hesitate to contact me at [email protected] Take a look at another article about Pocket Windows development I’ve written at http://codeguru.earthweb.com/ce/PocketWine.shtml.


Download demo project – 78 Kb

More by Author

Must Read