Posted by ALB42 on 22. Dezember 2015No Comments

There are still many strange things inside the LCL for MorphOS, especially the size (Window vs Contents) seems different as in AROS, it looks like the window size in Zune AROS is given by the inner size, but in MUI MorphOS its the outer size (with decorations). Hence the LCL calculations are wrong. I included some quirks to overcome this but not really a solution. The main problem is that I need the size of the window decoration before the window is open (so I can not read it from the window self). And then it depend on the window decoration (set by the user) and type of window (set by the application) how big the borders are. At this Point the AROS way is much more convenient for me.
The biggest headache I got with the texteditor, charlie told me I should not call MethodA() by using CallHookPkt() as I’m used to in AROS (MethodA is only a wrapper to CallHookPkt on AROS, as I read from the source). At MorphOS I should use the MethodA from AmigaLib unit, which is an assembler function. I changed all the calls but now the Texteditor.mcc crash, ok I should say not directly the Editor but something around. Looks like some Stack problems, If I switch back to my CallHookPkt() approach it works perfectly :-O. I tracked it down to the MUIM_TextEditor_ExportText which I use to read the contents of the TextEditor control, all other calls seems to work as expected. I have two ideas from it 1. It could be the problem that this Method Call returns something (a pointer the text, PChar) so maybe there is the problem. 2. I’m not completely sure but it could be that the Texteditor.mcc is a 68k element and all the other elements are PPC native. hmm the first sounds more like a reason.
An other odd thing I noticed yesterday already, when the LCL program starts the mouse pointer stutters some seconds (when the MUI objects are created?) usually such stuttering of mouse is not good ;-). I guess with both issues only Charlie can help me but he is still very busy.


Besides I improved a lot of things and tested many example codes to get an idea where we are, looks not that bad, image are not shown at all, some elements crash as expected, some not so expected, still much work but maybe worth to make a first pre-alpha-i-destroy-your-computer-release maybe someone want to try it 😉


You know there must be a screenshot… so here it comes 😛


FPCMines on MorphOS

FPCMines on MorphOS


There is something special on this screenshot, because its made with an LCL screenshot taker (for the source see Smile Screen) which work the same way on Windows, Linux, AROS 😉 and now MorphOS as well.
And the second special is of course the shown program FPCMines (like AROS Version)

Download: FPCMines MorphOS



P.S. I got some questions (ok one) if I dropped AROS support and switched to Amiga and/or MorphOS? No, I didn’t “switched” or something like, the original plan was to bring it to all platforms. The idea was to bring it to work on the other platforms and maybe some bugs appear which make the AROS port also better/more stable over the time. And it really is working this way, because MUI is much more sensitive and picky about wrong parameter and settings as Zune. The AROS port is already rather mature for my things the most things are working and to be honest I’m the only one really using it. The complete lack of interest is therefore also a reason to extent it to MorphOS (and Amiga68k).
I try to stay away from all this discussions between all the Amiga-like OS (classic, MorphOS, AmigaOS4, AROS) the only reason I do not make freepascal for AOS4 is that the computers for it are way too expensive for my understanding. With MorphOS was the same as I started with FPC on AROS in 2010. But now with MacMinis usable a very nice and cheap machine is available. I don’t see myself as an AROS user (mostly I get this title), but more as a “Amiga-family”-User.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.