When I try to compile some of my Sources for MorphOS or Amiga I always stumble over the problem that this two platforms does not have the VarArgs version of all the function I use (mostly happen for SetAttr or CallHook). Besides the array of const Version we use now in AROS has some problems, especially with Shortstrings which gets copied to a string then conversed to PChar, but after the call already destroyed, can have bad behaviour.
Especially at MUI I noticed the most functions expect the strings to stay after call, so I long time decided already to change the calling to an array of NativeUInt which should be much better, because you are forced to think about strings/PChar casting and it should be easier to transfer things to Amiga/MorphOS.
I wrote a little helper routine for tag and parameter handling and tried to get rid of the units tagarray and longarray which are basically just broken. I decided to use the Advanced Record approach and it looked really good, in some test programs I did with operator overloading its really easy to use.
But in LCL it did not work at all. Very strange and bad problems everywhere, crashes always at different points. For one test the crash point was easy to identify by the callstack in a very short routine, so I started to debug there. But strange everything was right, IT SHOULD WORK! But it doesn’t I took out some of the commands just let Tagsarray empty… and it still crashes, all Pointers are correct but if you try to investigate the Tagsarray it crashes, really strange. Just for fun I changed the type of my tagsarray from a advanced record to an old school pascal object (not class) and voila it is working :-O seems the advanced records are barely broken on extensive use. I hope the object are working better.
Some tiny improvements on the SimpleIPC Server for Amiga-style systems, ServerRunning was not implemented and UniqueInstance use the Message type to transfer the number of Parameter, so I had to implement this also.
Now its possible to use UniqueInstance functions in AROS also, without special ifdefs. (only a tiny change in the original unique instance code is needed an additional define ifdef Unix -> if defined(unix) or defined(HASAMIGA))
The code is available at GitHub
Working on the fcl-process package, first started with the easier part, the SimpleIPC class which is rather straight forward possible with MsgPort and of course this is the same for all three platforms (Amiga, AROS, MorphOS). A little bit more difficult is the TProcess thing because its rather tightly bound to pipes which not really working well in AROS, sometimes even not available.
The easiest way to make such a pipe is of course just a file in T: a common way at Amiga style systems.
Its a very basic implementation only for the Output but its already enough for let Lazarus find the right compiler, and does not complain anymore that the compiler does not support i386-aros. 🙂
I started a bigger evolution task for the LCL implementation. The cleaning of the codebasis and maybe also a litte preparation for the other platforms. I started with some hint removal and an easier implementation of EventHook connecting. I hope that way I can rid of some very old code from the MUI-LCL implementation start in 2011. I think later I will implement an own Tag Handling system for LCL which then can work for all three Platforms together. So tagarray and longarray units can be removed from the uses sections.
And with it some more debugging of course. In Lazarus the dependency views now working as expected.
hmm seems I opened Pandoras Box with compiling Lazarus. Of course its very unstable and buggy, so many bugs that its hard to decide where to start. So I started with the crashes on start and some redrawing issues I noticed.
Not sure whats wrong but the non-buffered drawing does not work well. For example the SynEdit looks nice with buffered drawing… when non buffered Drawing happen the upper quarter of the picture is empty. So it would be nice to always used buffered drawing (as long it does flicker less and is faster) But sadly with native MUI Widgets I can not use Buffered drawing. The reason is that the MUI drawing of the children only draws directly to the window and not to the buffer. So when the buffer is drawn to the window the MUI Objects are overpainted. So I first clip the buffer to window and then call the Childs to do a redraw, works nicely so now I alsways can use buffered drawing. I think LAter I should ckeck if some more optimizations can be done here (turn off the background drawing of MUI for example).
An other big part of the was the file handling and Text sizing. There this bad behaviour of lazarus showed up again, they implemented all the RTL functions for file handling again. For example found again a System: -> System:/ conversation, instead of using IncludeTrailingPathDelimiter(). I guess I have to recheck all the file utils again.
The Text Width/Height function is often called, even there is no RastPort available (outside paint event or even before the window is open). The height one can get directly from the Font, which solved the issue. The Width is a little bit more difficult, especially for not fixed width fonts. But even so I get some problem with the Toolbar buttons, the complete Window does not redraw anymore :-O if the Textwidth is bigger than 0 very strange, but I guess this I can also debug outside Lazarus with a little test application.
The Treeviews are working in principle, just the scrollbars are not in place, The position of them is set too early, before they are created. Besides this the Trees work rather nicely also the shelltreeview. But the Edit has the same problem as in the stringgrid or valueedit. It draws not right, I didn’t find out whats wrong there the edit is completely with text on white background, only at the cursor/selection you can read the char. I still have no idea why MUI paint this in the wrong way, especially because the scrollbars are painted in the right way… very strange.
Worked on the Font Dialog and ToolBar, the toolbar needed some addition work on the theming engine… I’m not completely sure how this theming engine work. Needs some more linux debugging I guess.
The fontdialog is just directly assigned to the ASL works very nicely.
The SynFacialHighlighter seems not to work on AROS, because no WideStringmanager is available, one way would be to write a Widestring manager (maybe would be good idea to do so also for the basic Freepascal implementation) or search for a different customizable highlighter. I found already one (included in Lazarus) SynUniSyn. The main problem is that this is just a very basic port from the delphi SynUniSyn and the original SynUniSyn is very hard to find (at least the original Pages are down, and sourceforge and so on are empty), so no Highlighter example files available. But I found a very old source of an editor wich have in an older repository version the sources and 311 (!!) Highlighters included.
So it works, also on AROS, maybe some tiny changes must be done, for example the C++ highlighter turns everything into uppercase. But this could be done I think, I will play a little bit with it.
Source at Github
Binary AROS i386
Implemented Screenshot possiblity for AROS, works very nice. Also found a source, how to make a screenshot
without the windows, the application.Minimize and Restore was long time implemented already but I never tried.
so here the source to create a screenshot:
procedure TForm1.Button1Click(Sender: TObject);
var
MyBitmap: TBitmap;
ScreenDC: HDC;
WrkJpg: TJpegImage;
begin
Application.Minimize;
Application.ProcessMessages;
Sleep(32);
MyBitmap := TBitmap.Create;
ScreenDC := GetDC(0);
MyBitmap.LoadFromDevice(ScreenDC);
Application.Restore;
Application.BringToFront;
WrkJpg := TJpegImage.Create;
try
WrkJpg.CompressionQuality := 80;
WrkJpg.Assign(MyBitmap);
WrkJpg.SaveToFile('test.jpg');
finally
FreeAndNil(WrkJpg);
end;
ReleaseDC(0, ScreenDC);
FreeAndNil(MyBitmap);
end;
and the resulting Image:
Finally go LazPaint somewhat working, yesterday was just with many dummy functions in the bgrabitmap package. Today I wrote some implementations of this. It works, but it is VERY slow, because the drawing functions like WritePixelArray are very slow when drawing to a ARGB Screen. Maybe a clever conversation before will improve it. the other thing: it crashes very often, mostly List exceptions, I’m wonderring if thats the same as I got for EdiSyn, some fonts are too small to read.
