I got my two 128 MB EDO RAM pieces for my Blizzard 1260 (with SCSI Kit), therefore I have now 256 MB RAM. Why I need so much RAM, easy, even a very simple LCL Program need more than 150 MB RAM to compile, of course I can compile in UAE but thats not the same 😉 Ok it needs 5 minutes to compile, but who cares, it works.
Compile a LCL program on a native Amiga
I created a archive of my complete LCL for m68k AmigaOS 3.x. Much things already working (all PaintEvent things does not work, so Labels, Panels and so on does not appear, but should also not crash).
So if anyone want to try Lazarus LCL on a real Amiga or UAE here is the archive, be careful its 55Mb and you will need at least 16 Mb to compile the examples, for bigger programs you might need even more.
Download Amiga LCL 0.1 alpha
for more informations read the „ReadMe“ inside the archive.
I found out why some elements at Amiga/MorphOS are not shown (like the scrollbars and comboboxes) it seems that MUI has very tight size constraints usually MinHeight = MaxHeight. And MUI is rather picky, if you give a bigger place at layout hook, it does not paint anything. I do not understand why a Button needs this tight size constraints, maybe I want bigger buttons.. but ok, not a big thing.. I will try to implement that also in the AROS LCL and maybe should check how to use the LCL constraints.
Amiga LCL with working size constraints
The second good thing is that the crash at close is disappeared at Amiga OS, but at MorphOS its still there, so I guess the issue is not solved. I will write an other test program to test the dynamically creation and destroying of MUI elements. But in principle one could think about a lcl AmigaOS release (its already much more than the first AROS lcl release 😉 )
I played again a little bit with Lazarus/LCL and I was able to get the thing compile on a real AmigaOS 3.9 with MUI 3.8. The result looks rather the same as my previous tries in MorphOS.
But different from the one from m68k AROS it makes the double strange that all windows in the m68k AROS are fullscreen. A bug in Zune? Who knows. The size calculation seems to be different as in i386-aros LCL, the windows are smaller.
Worked a little bit more on the sqlite3.library for AROS to use in freepascal. Its more or less only diligent working, and take care not to mix up anything. I didn’t include all the functions only the most important until now (at least what I think is most important) until now its already 106 functions inside the library.
Now I tried some test codes… the one from fpc directly are rather boring, even less impressive than my own examplecode.
But I found a german Tutorial how to use databases in Lazarus, with some tiny changes in in Lazarus component it compiles really nicely and works as expected.
SQLite3 freepascal example program
Left side Linux, Right side AROS.
I took a very old laptop and installed a new ubuntu (its really bad with only 1GB RAM) and tried to install freepascal with AROS crosscompiler and also crosscompile to AROS. Just to see which steps are needed. Then I also installed lazarus from source (my source from github) hmm seems I destroyed some things for other platforms and again chose a bad point for my branch. It can not create any lfm files, so no new projects/forms possible, I got this message at AROS but I thought its some problem there. So bad seems I have to update my lazarus branch again, always so much trouble. But besides this I got the lazarus GUI to crosscompile AROS lcl programs, and even run them inside AROS, should be much easier coding (for edisyn for example ;-))
Playing around with the LCL for MorphOS, seems to work nicely, but (as described last time already) it crashes on Exit. I tried to find the reason for it. It seems that that the MUI Objects are kind of destroyed already, even still visible on the screen. Due to the special way to work in LCL I do not like the automatic destroy function of MUI. If you build up a mui application with application, window, items in there you usually only need to destroy the application and every thing else will just be automatically destroyed. Of course thats not what we want to use for LCL (or it would be impossible to destroy single button/Windows and so on). Long time before at AROS I played around with it and the best solution is to just unlink the item from its parent and destroy it by hand (MUI_DisposeObject) because then it is always in my full control when an object gets destroyed or alive.
Seems thats exactly my problem now. When I begin to destroy my objects at some point it seems that the MUI Objects are already destroyed, so it crashes, but this object (window) is still visible on the screen. I removed all MUI_DisposeObject from my code and still the Window gets destroyed somehow :-O and the mui objects are invalid. Here happens something I do not understand. Really strange thing, maybe its some special „new MUI Version“-thing? I don’t know and not really an idea how to continue here. Maybe I need to write a simple non-LCL program where I do the same and try to find out this strange behaviour.
MorphOS use ELF for its binaries so the resources can be linked directly into the executeable. But Amiga uses Hunk format for executable and fpc is not prepared to link them into the executable so Charlie configurated them as external resources. I was curious if this is working. So I had to compile a new fpcres and bring lcl to compile for Amiga. After preparing some things for MorphOS this was not a big thing.
And on the first try it works already, but it looks wierd, the Window is full screen without any window decorations or button, even I limit the size. I deactivated the layout hook and it looks exactly the same. I have no idea whats wrong there. Same as MorphOS its crashing on Exit, I guess with the same reason.
Besides this its working nicely, even rather fast, at least faster than I expected.
As written yesterday the it seemed that the Hooks just do not work. This was right because I deactivated them. After reactivation the Button clicks and close windows works very nicely. But the Layout Hook still does not work. The routine for setting the min/max and layout is called. I added some debugoutput and noticed that the size of the window seemed to be negative. No wonder it won’t open it. But why its negative it should not be, the LCL window gets a valid size. In the end my very first idea was right… the structure is wrong which is used to get the Min/Max/Def sizes.. all Values there are set as ShortInt so -127…128 wich is rather unusual for Width/height of windows and really when look into AROS units this are Words so 0..65535 so no wonder MUI refuses to open the windows it just didn’t get the real size.
S I fixed the structure (locally) and voila its working. So I compiled some of my test programs from the fpc-tests repositiory to see where we are… because some are animated I made a little video out of it:
Link to the video
What we see:
Upper Line from the left:
Lower Line from the left
from this things I slowly get an idea what happen and this would be REALLY bad! All combined items does not work! Maybe because I added an LayoutHook??? But this would mean you can never put a combined Element like the Scrollbar into a Group wich has an own Layouthook. I would call this a bug.
In the Video is also easy to see that the size calculations are not right… especially at the Button test, the Memo is alBottom, but draws alreay over the windowborders. I took me very long to make this right on AROS… seems at MorphOS its again different.
Besides this all programs crash on exit at the moment. I try to debug it but its really hard because you have to dissassemble the program then use the offsets from the crash log to find the position where it gave the problem. It seems that the problem appears that the LCL access some property short BEFORE the item gets destroyed but this crash already. The item is not destroyed because its still visible on the screen. No idea whats wrong there maybe with debugtexts will be better.
Charlie did an awesome job to add some more festures to the MorphOS (and Amiga) Freepascal compiler so FINALLY i was able to compile the LCL for MorphOS. I had to deactivate a lot of stuff for now, but all not very important. Some are expected to be a problem like the cybergraphics things… other more surprising for me like diskfont library which does not exists (the freepascal wrapper unit for it only, I guess)
But also other stuff I have to think about, especially, GetAttr, SetAttr, CallHook, maybe I make some wrapper functions to make it easier to handle them at all three platforms. It kept crashing all the time… of course bcause I forget AGAIN that you need to to Open the libraries for the needed units, there is the most interesting point, when to init because some initializations will need it. Finally I found the best position for now.
So it does not crash anymore but also does not open a window… seems my Hooks for MorphOS does not work well because the Layouthook is never called, and the Window open attribute does nothing. After deactivating the LayoutHook it at least start it does not care about the size, thats the reason the Button is full window size. I have the Hooks working in an separate MUI testprogram so I guess I just did something wrong in the LCL. So because the Hooks does not work even the close button does nothing in MorphOS.
So much work, so little time.
