Forum > PDAs and Smartphones
Porting the magnifier to Windows CE
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:
--- Quote from: "CCRDude" ---
(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).
--- End quote ---
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:
--- Quote from: "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.
--- End quote ---
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.
--- Quote from: "CCRDude" ---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 ;)
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page