Hi all,

i'm trying to make an app for WinCE, but having problems.

I installed fpc-2.2.2.arm-wince.exe, fpc-2.2.2.i386-win32.exe and unzip the fpc-2.2.2.source.zip. Then i get Lazarus sources from svn trunk.

Lazarus compiled with :

make distclean make all make lcl LCL_PLATFORM=wince PP=ppcrossarm.exe CPU_TARGET=arm

OS_TARGET=wince.

I then run Lazarus and configure the enviroment path for the compiler to be the ppcrossarm.exe, the fpc source path and finally in the debugger options i selected the arm-wince-gdb.exe as the debugger.

I went and create a new project, and in the Project->Compiler options->Paths i select for the "LCL widget type (varius)" option the "wince(beta)". In Project->Compiler options->Code i selected for the "Target OS(-T)" option the "WinCE" and for the "Target CPU family(-P)" option the "arm".

Pressed F9, and all is ok ... Project compiles, the debugger connects to the connected ( via ActiveSync ) device, creates the \gdb dir, copy the wince_stub.exe file first, then it copies the project1.exe and last it runs it. I can see the calls in debug output window. Stop running and reseting debugger.

Then i drop a TMainMenu component on the main form, added a TMenuItem and pressed the F9 again. Now the debugger stops the execution with 'Project DPIfaistos raised exception class 'External: SIGSEGV'. Pressing F9 the execution continues. When i press the menu item ( which don't have any event handler assigned ) execution stop normally. Even if the menu item have an event handler assigned still when i click the execution stops normally.

I went to the Project->Compiler options->Linking and checked the "Generate Debugging Info For GDB (Slows Compiling)(-g)" and here is the info from the Call Stack window

#0 TCUSTOMFORM__SHOWMODAL((TCUSTOMFORM) 0x75a14806) at customform.inc:2020 #1 TLISTITEMS__DESTROY((POINTER) 0x0, (TLISTITEMS) 0x0) at listitems.inc:252 #2 TWINCEWIDGETSET__APPWAITMESSAGE((TWINCEWIDGETSET) 0x97ab20) at winceobject.inc:399
#3 TAPPLICATION__IDLE(true, (TAPPLICATION) 0x972310) at application.inc:315 #4 TAPPLICATION__HANDLEMESSAGE((TAPPLICATION) 0x972310) at application.inc:985
#5 TAPPLICATION__RUNLOOP((TAPPLICATION) 0x972310) at application.inc:1095 #6 TWIDGETSET__APPRUN((TAPPLICATIONMAINLOOP) 0x30ad8 <TAPPLICATION__RUNLOOP>, (TWIDGETSET) 0x97ab20) at interfacebase.inc:49 #7 TAPPLICATION__RUN((TAPPLICATION) 0x972310) at application.inc:1082 #8 :17

I traced it a little more and the exception is raised in a call to RedrawMenus procedure from winceobject.inc, line 399.

RedrawMenus procedure is in winceproc.pp.

Any hints ?

PS: Currently i can't copy anything from the debug output window, cause there isn't any copy option in the right click popup menu for copying ( only one option clear exists ) and Ctrl-C doesn't work.

regards,

Hello,

What happens if you execute the application without the debugger? Just build the binary, copy the binary to the device and run it. Does it still crash?

Are you using the emulator or a real device? Which WinCE version?

Felipe hi,

What happens if you execute the application without the debugger? Just build the binary, copy the binary to the device and run it. Does it still crash?

The app doesn't throw exception ( never had a crash ) cause the call to RedrawMenus is handled inside a try finally block :

#0 TCUSTOMFORM__SHOWMODAL((TCUSTOMFORM) 0x15a68ac6) at customform.inc:2018 "
...
2016: ModalResult := 0;
2017:
2018: try
2019: Show;
...
"
#1 TLISTITEMS__DEFINEPROPERTIES((^TFILER) 0x0, (TLISTITEMS) 0x0) at listitems.inc:359
#2 TWINCEWIDGETSET__APPWAITMESSAGE((TWINCEWIDGETSET) 0x96ab20) at winceobject.inc:399
#3 TAPPLICATION__IDLE(true, (TAPPLICATION) 0x962310) at application.inc:315 #4 TAPPLICATION__HANDLEMESSAGE((TAPPLICATION) 0x962310) at application.inc:985
#5 TAPPLICATION__RUNLOOP((TAPPLICATION) 0x962310) at application.inc:1095 #6 TWIDGETSET__APPRUN((TAPPLICATIONMAINLOOP) 0x30af8 <TAPPLICATION__RUNLOOP>, (TWIDGETSET) 0x96ab20) at interfacebase.inc:49 #7 TAPPLICATION__RUN((TAPPLICATION) 0x962310) at application.inc:1082 #8 :18

Are you using the emulator or a real device? Which WinCE version?

Currently i'm doing the tests to a device with Windows Mobile 2003 Second Edition - Version 4.21.1088 (Build 14235). It's a Qtek 2020i PocketPC. Didn't test it in Emulator.

regards,

PS: Fpc 2.2.2, Lazarus v0.9.25 r16538 i386-win32-win32/win64

That code is copyed from the win32 widgetset. Maybe the call to RedrawMenu is unnecessary under Windows CE.

Try commenting the call to RedrawMenu, rebuilding lcl and testing again.

Also, please attach a minimal test project which reproduces the issue in your bug report:

http://bugs.freepascal.org/view.php?id=12105

O/H Felipe Monteiro de Carvalho ??????:

That code is copyed from the win32 widgetset. Maybe the call to RedrawMenu is unnecessary under Windows CE. Try commenting the call to RedrawMenu, rebuilding lcl and testing again.

The exception is gone. I comment out

Index: lcl/interfaces/wince/winceobject.inc
===================================================================
--- lcl/interfaces/wince/winceobject.inc	(revision 16547)
+++ lcl/interfaces/wince/winceobject.inc	(working copy)
@@ -396,7 +396,7 @@
    timeout, retVal: DWord;
    pHandles: Windows.LPHANDLE;
  begin
-  RedrawMenus;
+//  RedrawMenus;
    Assert(False, 'Trace:TWinCEWidgetSet.WaitMessage - Start');
    if FWaitPipeHandlers  nil then
      timeout := 100

Also, please attach a minimal test project which reproduces the issue in your bug report: http://bugs.freepascal.org/view.php?id=12105

Actual a simple, plain app running in the debugger will raise the exception. But i 'll do that.

regards,

PS: What about the ability to copy to clipboard the contets of the debug output window ? It will be very handy to be able to copy debuggers information. Should i add a new ticket in the tracker ?

Dimitrios Chr. Ioannidis wrote

The exception is gone. I comment out

No drawbacks? Does the app keep working as expected?

There are possible drawbacks, the first being a memory leak because now the dirty menu list is never cleared.

I am tempted to simply remove this repaint menu code, but I am afraid it may have unpredictable effects near the release.

PS: What about the ability to copy to clipboard the contets of the debug output window ? It will be very handy to be able to copy debuggers information. Should i add a new ticket in the tracker ?

I added it. Take a look at what I did:

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=16548

And test it.

O/H Felipe Monteiro de Carvalho ??????:

Well, i don't know LCL internals to agree or disagree but i could not test it. A small project with a TMainMenu isn't a test :) And of course i would like to know how to test for memory leaks using remote debugger.

It works. Thx ... Now i can help you more providing you with debug output info's like this, where i'm trying to see why ApplicationType isn't set correctly in my device :

<-file-exec-and-symbols "E:/Programming/Projects/testLazWince/project1.exe"> ^done
<-gdb-set language pascal>
^done
<-environment-cd .>
^done
<-environment-cd "E:/Programming/Projects/testLazWince/"> ^done
<-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC> &"No symbol \"FPC_THREADVAR_RELOCATE_PROC\" in current context.\n" ^error,msg="No symbol \"FPC_THREADVAR_RELOCATE_PROC\" in current context."

< stripped a lot info >

&"info file\n"
~"Symbols from \"E:/Programming/Projects/testLazWince/project1.exe\".\n" ~"Local exec file:\n"
~"\t`E:/Programming/Projects/testLazWince/project1.exe', \n" ~" file type pei-arm-little.\n"

< stripped a lot info >

<-exec-run>
^running
~"Connectig to remote device...\n"
~"Starting on device: \"\\gdb\\wince-stub.exe \"\n" ~"Accepting connection...\n"
~"Uploading file to device: \\gdb\\project1.exe\n" ~"7fea1000:tshres.96.dll\n"
~"27b1000:shutil.dll\n"
~"7feb1000:shellres.dll.0408.mui\n"
~"7fee1000:shellres.dll\n"
~"7ff41000:tshres.dll.0408.mui\n"
~"7ff61000:tshres.dll\n"
~"2841000:commctrl.dll\n"
~"27e1000:aygshell.dll\n"
~"2361000:oleaut32.dll\n"
~"22f1000:ossvcs.dll\n"
~"2391000:ole32.dll\n"
~"7fff1000:coredll.dll.0408.mui\n"
~"1f61000:coredll.dll\n"
*stopped,thread-id="1",frame={addr="0x00011bdc",func="main",args=[],file="project1.lpr",fullname="E:\\Programming\\Projects\\testLazWince/project1.lpr",line="13"} <info program>
&"info program\n"
~"\tUsing the running image of child process 361384062.\n" ~"Program stopped at 0x11bdc.\n"
~"It stopped at a breakpoint that has since been deleted.\n" ~"Type \"info stack\" or \"info registers\" for more information.\n" ^done
<-break-insert winceobject.inc:129>
^done,bkpt={number="13",type="breakpoint",disp="keep",enabled="y",addr="0x0013fa58",func="TWINCEWIDGETSET__APPINIT",file="winceobject.inc",line="129",times="0"} <-break-enable 13>
^done
<-break-insert winceproc.pp:1456>
^done,bkpt={number="14",type="breakpoint",disp="keep",enabled="y",addr="0x001485e8",func="GETWINCEPLATFORM",file="winceproc.pp",line="1456",times="0"} <-break-enable 14>
^done
<-break-insert winapi.inc:850>
^done,bkpt={number="15",type="breakpoint",disp="keep",enabled="y",addr="0x00074504",func="SYSTEMPARAMETERSINFO",file="winapi.inc",line="850",times="0"} <-break-enable 15>
^done
<-break-insert intfbasewinapi.inc:1493>
^done,bkpt={number="16",type="breakpoint",disp="keep",enabled="y",addr="0x00038868",func="TWIDGETSET__SYSTEMPARAMETERSINFO",file="intfbasewinapi.inc",line="1493",times="0"} <-break-enable 16>
^done
<-exec-continue>
^running
*stopped,reason="breakpoint-hit",bkptno="13",thread-id="1",frame={addr="0x0013fa58",func="TWINCEWIDGETSET__APPINIT",args=[{name="SCREENINFO",value="{PIXELSPERINCHX = 72, PIXELSPERINCHY = 72, COLORDEPTH = 24, INITIALIZED = false}"},{name="this",value="0x96aaa0"}],file="winceobject.inc",line="129"} <-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x0013fa58",func="TWINCEWIDGETSET__APPINIT",file="winceobject.inc",line="129"}]

< stripped a lot info >

regards,

Dimitrios Chr. Ioannidis wrote

It works. Thx ... Now i can help you more providing you with debug output info's like this, where i'm trying to see why ApplicationType isn't set correctly in my device :

Why do you think it isn't set correctly? What is it set to? What were you expecting?

If you are just developing to 1 kind of device simply override the ApplicationType to a fixed type, but be aware the atPDA the most tested mode.

Well, i was expecting that the ApplicationType variable to be set to atPDA or to atHandheld regarding the device that is running. At least this was my assuption reading the code below :

( winceobject.inc )
...
128: { Initializes the application type }
129: if Application.ApplicationType = atDefault then 130: Application.ApplicationType := GetWinCEPlatform; ...

but then when i trace the GetWinCEPlatform call i find that it ends in ( intfbasewinapi.inc )

function TWidgetSet.SystemParametersInfo(uiAction: DWord; uiParam:
DWord; pvParam: Pointer; fWinIni: DWord): LongBool;
begin
  case uiAction of
    SPI_GETWHEELSCROLLLINES: PDword(pvPAram)^ := 3; // default value
  else
    Result := False;
  end
end;

which does nothing. If i'm not mistaken the implementation code to auto determine the device type and set the applicationtype variable accordingly is missing.

Maybe i'm wrong, i'm just started to learn LCL.

regards,

function TWidgetSet.SystemParametersInfo

This is the wrong routine. I changed the code to explicity call Windows.SystemParametersInfo (which means: from the windows unit). Looks like an ambiguity problem.

Please retest after upgrading to latest svn.