Porting the magnifier to Windows CE

[felipemdc]

Hello,

I am porting the Virtual Magnifying Glass ( http://magnifier.sourceforge.net/ ) to Windows CE - LCL, and I thought posting what I learn doing it here might help others porting LCL software to WinCE-LCL.

To start with, the free pascal version that really worked for me was the snapshot from CCRDude. It can be downloaded here:

http://www.see-cure.de/files/lazarus-arm-wince-20060707.7z

I am using it together with the Emulator from Microsoft before I acctually try on a real device.

The first thing to do was rework all my conditional defines, and change them from IFDEF Win32 to the more platform-independent IFDEF Windows

Some code remained with IFDEF Win32 because either I don´t need it on Pocket PC, or because it uses ShellAPI, which is not available on WinCE.

I created my own batch files to do tasks like, compile the software and copy it to the emulator shared folder. Or call GDB via active sync.

A big problem at the moment is that $R resource directive doesn´t work on Windows CE, so I think I will need to put my pictures on the same directory as my executable on WinCE.

I alse needed to search on MSDN for all Windows API functions I use directly to make sure my app will run on many Windows CE version. A good way to search msdn for WinCE api is by googling this:

site:msdn.microsoft.com "Windows CE" <FunctionName>

So far everything is great. Keyboard events work completely across all target platforms with LCL, I can create TBitmap images and manipulate them, detect the Windows CE version, detect the Screen Size.

In about 3 hours I made an application completely unprepared for windows ce to run. It´s not fully working, but the port is going well.

Later I will post more info.

[CCRDude]

Hmmm there's a define "Windows"? That's good to know

But: $R works! The background, the icon and the image on my mini demo are all loaded from the resource file, as is the menu of some of the other apps I'm writing:
(http://img148.imageshack.us/img148/483/miniguidemoju8.th.png)
What exactly was your problem with $R?

For help on the API functions, I've downloaded the Pocket PC 2003 SDK (as well as the Smartphone 2003 SDK, which is needed to have cabwizsp.exe, since the cabwiz.exe from the Pocket PC SDK only creates cab installers for Pocket PCs). Searching in the CHM file on the local machine is a bit faster than doing online lookups on MSDN

(btw: just spent a few hours tracking a very silly thing: when using the API directly (not sure about the LCL), which uses wide strings, there needs to be special care about TStringList - the compiler creates code that creates EBusErrors when assigning a WideString from a control to a TStringList.Text, even when typecasting with AnsiString - but not the other way round, which works).

[felipemdc]

> What exactly was your problem with $R?

I was getting this error: magnifier.dpr(92) Error: resource compiler not found, switching to external mode

I am using my own arm-binutils instead of the ones your package provides, and arm-wince-windres wasn´t together with the binutils.

Just copying it to the folder where my binutils are and it worked!

thanks

[felipemdc]

Hmmm there's a define "Windows"? That's good to know

Yes, but be careful that Windows define isn´t defined on FPC 2.0.2 which you normally use to compile Win32 applications. It´s now defined on FPC 2.0.4 for Win32.

To solve this, and keep compatibility with FPC 2.0.2 I add this statement to my main program file:

{$IFDEF Win32}
  {$DEFINE Windows}
{$ENDIF}

[CCRDude]

Oh, then I'll stick to my own defines for now, since they already work

Btw: I tried to reproduce a situation where resource files didn't work for me as well (since I remembered I had problems with them at first as well). WinCE doesn't seem to like menu items that are disabled, as soon as I disable one in the resource file, it breaks the app.

[felipemdc]

I just spent hours debuging the most bizarre bug. Apparently TCustomControl descendents that are put on a form only work if there are no fields on their declaration. So the following class will be able to paint itself correctly:

  TPainter = class(TCustomControl)
  public
    procedure Paint; override;
  end;

But this one will fail. It can be created, but the Paint method is never called:

  TPainter = class(TCustomControl)
  public
    AVariable: Integer;
    procedure Paint; override;
  end;

This was a pain to figure =/

The bug is so specific I really have no idea what could cause it.

[_Bernd]

(btw: just spent a few hours tracking a very silly thing: when using the API directly (not sure about the LCL), which uses wide strings, there needs to be special care about TStringList - the compiler creates code that creates EBusErrors when assigning a WideString from a control to a TStringList.Text, even when typecasting with AnsiString - but not the other way round, which works).

I have the same problems with EBusErrors, when I am assigning strings to a LCL-Edit.Text property. Unfortunately this does not happen always.

Regards, Bernd.

[CCRDude]

Are you strings just "string"? In that case you should define them as "WideString"; doing it that way works quite fine in everything I tried.

I debugged this a bit today, and though I'm not sure how this fits with the working/non-working cases I found earlier, but there's this:

The LCL reserves one byte too much in GetControlText (it uses SysAllocStringLen, which automatically allocates the additional byte for #0,  which is already usedcorrect in CreatePWideCharFromString).

I'm not sure if this is the reason, but in my own code, once I read that SysAllocStringLen automatically reserves the trailing zero and I fixed this, my stuff works without EBusErrors now

I probably should submit a patch? I've been planning on providing patches for adding stuff I found out anyway (like additional aygshell functions and some other stuff that's missing), but I'm still using that old build as well and can't find the time to test the newest one with ARM-WinCE compilations, so I don't even know if it already has been fixed by now

[_Bernd]

Are you strings just "string"? In that case you should define them as "WideString"; doing it that way works quite fine in everything I tried.

My strings are declared as "pure" strings with {$H+}, so they should be Ansistrings. My 2.1.1 snapshot is even older than yours, so I could try yours. But I don't like this kind of work.

I probably should submit a patch? I've been planning on providing patches for adding stuff I found out anyway (like additional aygshell functions and some other stuff that's missing), but I'm still using that old build as well and can't find the time to test the newest one with ARM-WinCE compilations, so I don't even know if it already has been fixed by now

I am not sure, but it seems, as if the upcoming "stable" 2.0.4 has ARM support. This would be a basis to make bug reports and patches.

Regards, Bernd.

[Vincent Snijders]

Fpc 2.0.4 supports only arm-linux, not arm-wince.