Difference between revisions of "Windows CE Development Notes"
Sekelsenmat (talk | contribs) |
Sekelsenmat (talk | contribs) |
||
Line 60: | Line 60: | ||
The colors of the TCheckListBox items under Windows CE are: | The colors of the TCheckListBox items under Windows CE are: | ||
− | + | {| BORDER="1" CELLSPACING="0" | |
− | + | !COLSPAN="1" STYLE="background:#ffdead;"|'''Description''' | |
− | + | !COLSPAN="1" STYLE="background:#ffdead;"|'''Code''' | |
− | + | !COLSPAN="1" STYLE="background:#ffdead;"|'''Value before fix''' | |
− | + | !COLSPAN="1" STYLE="background:#ffdead;"|'''Correct value''' | |
− | + | !COLSPAN="1" STYLE="background:#ffdead;"|'''Correct?''' | |
− | + | |---- | |
+ | |background of the entire item||GetSysColor(COLOR_WINDOW)||black||white||No | ||
+ | |---- | ||
+ | |background of unselected text||default background color||white||white||Yes | ||
+ | |---- | ||
+ | |background of selected text||SetBkColor(COLOR_HIGHLIGHT)||black||blue||No | ||
+ | |---- | ||
+ | |background of selected item||GetSysColor(COLOR_HIGHLIGHT)||black||blue||No | ||
+ | |---- | ||
+ | |color of selected text||SetTextColor(GetSysColor(COLOR_HIGHLIGHTTEXT))||black||white||No | ||
+ | |---- | ||
+ | |color of disabled text||SetTextColor(GetSysColor(COLOR_GRAYTEXT))||?||?||No | ||
+ | |---- | ||
+ | |color of normal text||default text color||black||black||Yes | ||
+ | |} | ||
Acording to the MSDN docs a result of 0 for GetSysColor under Windows CE should identify that it isn't available. Now, 0 is also an RGB value (black), so maybe the WinCE docs are wrong and the Win32 docs should be used. | Acording to the MSDN docs a result of 0 for GetSysColor under Windows CE should identify that it isn't available. Now, 0 is also an RGB value (black), so maybe the WinCE docs are wrong and the Win32 docs should be used. |
Revision as of 17:53, 8 February 2008
This article applies to WinCE only.
See also: Multiplatform Programming Guide
│
English (en) │
中文(台灣) (zh_TW) │
Debugging your applications
General info is here Windows_CE_Interface#Debbuging Windows CE software on the Lazarus IDE
- Sometimes GDB will crash, just reset debugger and start again.
- If you have an open call stack window it will take lots of time each time you trace or debug your program and it sometimes crashes the debugger, so use it only when needed.
- Always put breakpoints where needed; you can not-or hardly can- pause your program or even stop/reset it.
- You can strip your program with --only-keep-debug which save you around 1 mg.There are some issues with strip utility, sometimes it makes your program not executable, So I generally don't recommend using it.
- Sometimes stepping takes lots of time, just be patient ,I've experienced once a simple assignment took 1 min for debugger to execute that code.
Alignment problems
Using ARM processors, some times you may get a EBusError exception with a message about misaligned data access. The following section explains what this is and how to fix it.
What is misaligned data access?
Suppose a CPU has a 8bit data bus to memory and you want to read a byte. Since you have a 8bit bus, you are able to address all individual bytes, so reading is not a problem. Now imagine a CPU with a 32bit data bus and reading a byte. Data is read in chunks of 32bits (=4 bytes) and it is addressed by multiples of 4. For getting the exact byte, the CPU "shifts" the right byte.
Now we do the same for reading a 32bits integer. On an 8 bit CPU, you have to read 4 times one byte and then you have the integer. On a 32bits CPU it can be read in one go if the address is aligned to 4 bytes. If not, it has to be read in 2 halves and then combined to one integer. The x86 supports reading like this, although it is inefficient. The SPARC and some implementations of the ARM (*) don't support this and raise a bus error if you read data like this.
(*) there are extensions to the ARM core which can handle it, but this
Depends on what functionality the manufacturer of a specific core has
Implemented.
How to solve this?
Use typecasts of pointers very carefully. 16-bit and 32-bit values need to be 4-byte aligned in memory. Otherwise bus error will occur. Or use newly added "unaligned" keyword before using them. You can use unaligned keyword both in left or right side of your assignments.
Examples:
var p1:^Longint; l:longint; begin p1^:=20; //might cause error if p points to an unaligned memory, i.e. not 4-byte aligned. unaligned(p1^):=20; //it is ok l:=pl^; //this can also generate error l:=unaligned(pl^); //it is ok end.
When using Pack records, compiler automatically generates all access to the record members as unaligned access. Currently there are some small issues which sometimes with nested pack records compiler does not generate the required code. You just have to use unaligned keyword. But note that using packed records will influence speed a lot as all of its members are treated as unaligned. So use them only if needed.
Implementation details
TCheckListBox
See also: Win32/64_Interface#TCheckListBox
TCheckListBox presents some color problems under Windows CE which need to be fixed.
The colors of the TCheckListBox items under Windows CE are:
Description | Code | Value before fix | Correct value | Correct? |
---|---|---|---|---|
background of the entire item | GetSysColor(COLOR_WINDOW) | black | white | No |
background of unselected text | default background color | white | white | Yes |
background of selected text | SetBkColor(COLOR_HIGHLIGHT) | black | blue | No |
background of selected item | GetSysColor(COLOR_HIGHLIGHT) | black | blue | No |
color of selected text | SetTextColor(GetSysColor(COLOR_HIGHLIGHTTEXT)) | black | white | No |
color of disabled text | SetTextColor(GetSysColor(COLOR_GRAYTEXT)) | ? | ? | No |
color of normal text | default text color | black | black | Yes |
Acording to the MSDN docs a result of 0 for GetSysColor under Windows CE should identify that it isn't available. Now, 0 is also an RGB value (black), so maybe the WinCE docs are wrong and the Win32 docs should be used.
TChecklistbox before fixes
TChecklistbox after fixes
Not yet fixed =)
MSDN Docs
- GetSysColor for WinCE: http://msdn2.microsoft.com/en-us/library/ms929466.aspx
- GetSysColor for Win32: http://msdn2.microsoft.com/en-us/library/ms724371(VS.85).aspx
- SetTextColor for WinCE: http://msdn2.microsoft.com/en-us/library/ms961529.aspx
- SetBkColor for WinCE: http://msdn2.microsoft.com/en-us/library/ms961456.aspx
Bug track items
Tab Controls (TPageControl)
While most controls work just "as-is" from normal Win32 code, Tab Controls present a big amount of "gotchas" which make development of a tab control harder then in Win32.
A small list:
- Vertical text is not supported, so tab buttons located on the left and right won't show text
- For whatever reason (a bug in WinCE?) tab controls with tab buttons located on the top won't display text on the tab
Also, Microsoft recomends using tabs with bottom style under Windows CE, so that the user won't cover the touch screen with his hand when changing tabs. Combining all those together made me decide to hard-code page controls into always using bottom style under Windows CE, regardless of the control properties.
The default stype is a bit old. But I found the new style too minimalistic. You can barely see it's a tab control at all. The call to set new style (flat stype) is on the code (TWinCEWSCustomNotebook.CreateHandle), just commented, so it will be easy to change in the future
Some docs are located here:
http://msdn2.microsoft.com/en-us/library/aa921319.aspx
Background and sheet position problems
The background of each page seams not to be painted by default, and because the border around the control is very thin and incomplete (not all edges have borders), you can barely see what is the client area of the sheet
I used a magick change on the sheet position given by WinCE as described here:
http://www.pocketpcdn.com/forum/viewtopic.php?t=499
Here is a TPageControl before the sheet position adjust:
And after:
Note that you can only clearly see the client area on the bottom page control because I put a TPanel aligned to alClient inside it.
I couldn't decide if fixing a background color was a good idea, or which color would I use for it, so I'm leaving this problem be for now.
Bug track items
DataAware controls
For some unknown reason, data-aware controls crash the application.
Bug track items
http://bugs.freepascal.org/view.php?id=10442
Menus
Menus aren't yet implemented for Smartphones.
Bug track items
http://bugs.freepascal.org/view.php?id=10440
Known Issues and bugs
SetProp - GetProp - RemoveProp APIs
Windows CE does not have SetProp and GetProp API's which is used a lot. So I have created/emulated them. The current implementation is not exactly as win32 API. In win32 you can set multiple properties with different names to each window but here I ignore names so we can only have one kind of property assigned to each control. (It is easy to implement that, but I find it currently of no use). Also removeprop is not called yet! So a memory leak happens each time you exist the program. (I don't know if wince also frees memory itself or not when window handles are destroyed).Should be implemented soon.
LCLControlSizeNeedsUpdate LCLBoundsToWin32Bounds LCLFormSizeToWin32Size GetLCLClientBoundsOffset GetLCLClientBoundsOffset
I haven't even bothered myself to know are these working or not. I also don't think we need them as they exist in win32.So might require some redesigning. For example in TWinCEWSWinControl.SetBounds I had to remove movewindow because it moved it to nowhere.
Brushes
We don't have them as they are in win32; i've mapped CreateBrushIndirect to CreateSolidBrush and CreateDIBPatternBrushPt. other flags if used in LCL(not seems so far) will fail.
Other Stuff
Some other useful info.
External signal(?) Error
From time to time you might see this from debugger. It is a misaligned datatype error, which in normal cases you shouldn't see. You can solve this problem by adding unaligned keyword to the code that generates this error. This error can happen everywhere that memory access is likely to be done.
Menus
They require some extensive work. Need a little more background knowledge on how LCL handle menus and maybe some modifications to that too!
For Future
- Make sure to state descriptions of WINAPI from wince, currently it is same as win32, but sometimes they differ.
- Currently programs compiled with Lazarus and WinCE Interface is optimized and expects to work only on PocketPC Devices.
Links
Here are some links that might be useful for creating Windows CE interfaces.
How to Port Your Win32 Code to Windows CE
Old but useful article show flags required for creating wince controls
Page with nice descriptions of lots of flags
Adapting Application Menus to the CE User Interface
Differences between normal Win32-API and Windows CE (old wince)
Resource-Definition Statements
Developing Orientation and dpi Aware Applications
Developing Screen Orientation-Aware Applications
Introduction to User Interface Controls in a Windows Mobile-based Smartphone