Does the 9.30 fpc 2.4.2 wince arm cross compile from win32 work?

[picstart]

I have wince lazarus code that compiled and worked with 9.26 for winCe 5.0 and wince 4.2net now if it is recompiled with 9.30 fpc 2.4.2  it doesn't work. ( 9.28 was avoided because of debugging bugs). I can always go back to the rock solid 9.26. The wince compiled 9.30 exe  appears to launch without error on the arm device but no form appears. I have I believe all the options in project options correct but maybe there is some hidden dependency introduced in 9.30 that I'm not aware of. The same code will compile for win7 pro 32bit ( with of course the appropriate project option changes). I'd be interested if anyone got a simple 'Hello world'  to work on an arm winCe device.

[marcov]

There have been more complaints. But most seemed to stem from people that also migrated to newer CE devices at the same time. 

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

[felipemdc]

Could you try 0.9.28 and tell us if it works?

[picstart]

I would try putting 9.28 on my PC however the thought terrifies me given I have 9.30 actually working on Win7 pro 32bit. I feel I have no control or knowledge of where lazaraus puts files it certainly doesn't stay contained within the lazarus directory I specify. This results in an imperfect system for me almost every time. I have had nothing but frustration when either updating lazarus or trying to run two versions. They unpleasantly interplay with each other unless an earlier version is completely erased ( lazarus directory files that leak into user\xxx\xxx\xxx etc and possibly other areas I have no idea of). I'd love to have a way of containing a lazarus IDE  install to a single directory of my choosing. I'd have 9.30 in its self contained directory and 28.0 in its separate directory and " nether the the twain shall meet".  I understand there are reasons like... several lazarus users sharing a single PC... or networked shared versions in a corporate scenario... even spreading lazarus IDE dependencies into the cloud might have some value but the downside is this wizardry makes simple use frustrating to the point I avoid it or except  for  the (every 2 years or so) install of a new lazarus version and only then after a full system backup. I have accepted the issues with dependencies outside of unit files form descriptors and project files. The publish project feature has helped with this but these dependencies are a bit like having a 42 inch screen chained to my leg and someone gives me a remote control to make things easier.
It may be naive but I like to move ( cut and paste)  the source files (units forms project) to a folder of my choosing and them run there. I can't make it work without the wizardry in project>publish to do this.

[picstart]

I probably need to get back to a trusted lazarus version(9.26) though I almost trust 9.30 on the win7 PC platform ( 9.28 was a misadventure). In August I will build on  a separate PC a  win7 system and try installing 9.26 . If it runs then I hope to get full reliability back . I may be wrong but Lazarus combines a compiler and an IDE .. a utility for coding.  It should be robust and obvious at every point especially with the files it uses. The coder accepts that beyond the syntax of code there will be compiled representations needed for linking and final execution. The coder sees these representations as derivatives of the original code files such that if the originals were moved anywhere and presented to the lazarus utility a similar compiled result would occur. These original files are units ( all disclosed in the uses sections of the coders code) add in the forms and a project description and that should be it. Anymore is black magic and if defective creates a distrust by coders that files not of their making are despoiling code that should at face value work. Versioning should not be a burn the bridges behind you endeavor old and update should be able to run side by side on the same PC so coders can toggle between them to create trust. If major effort is required for this then versioning becomes unpleasant. I'm frustrated right now.... Lazarus is like a fine bottle of wine maybe if I stay away for awhile it will mature instead of sour.

[picstart]

Code was developed on the PC and the placement of the form on the PC is somewhat arbitrary since it will run on an arm small screen device only the height width were of concern.
The older arm_wince 9.26 compiler I'm guessing had some smarts for this and didn't allow the x y position of the screen to get out of screen range vis a vis the small device even if it was originally in the center of the PC screen.. The new 9.30 doesn't appear to do this so the screen is placed out of view in the arm device and thus appears not to be running correctly. If the screen is placed in the top right corner of the PC  before compiling then it is within visible range on the arm device and does work. It's fair that the screen on the arm be referenced x y wise to the target device so there is no issue to resolve.

[felipemdc]

But it should still do that if you use the correct settings. Maybe you are using unusual borderstyle or something like that?

Please read here how it should work:

http://wiki.lazarus.freepascal.org/Windows_CE_Development_Notes#Positioning_and_size_of_Dialogs_and_Forms

[picstart]

felipemdc
 Thankyou for the assistance. I was using the incorrect bordersytle all along but the error didn't have a WinCe consequence until I installed 9.30 and WIn7 and a bigger PC display screen.  I will in future use bsdialog. It was frustrating discovering my error since in the WinCe device no screen showed since its x y position was out of bounds. Running a task manager in the WinCe device showed the application to be running leading to a guess that the screen was just out of view. I develop my wince app exclusively on the desk top win7 PC. Then using project>> publish my code to a separate folder then adjust project>> options for the cross compile then I move my wince exe to the winCE device's SD card then I  remove the SD card and insert it in the wince device and see if it works. Maybe this approach is more likely to cause issues.