For the step of EdiSyn I will need a working color requester, the ASL does not supply one so I have to create one for myself. Not a big thing actually, just create a new local MUIApplication (I was not sure this is even possible to create two of them in the same process, but seems no problem until now) a Window with two buttons and the Palette object.
Again meet this strange MUI color needs 32 bit value for each color, but the requester only counts from 0..255. So its working nicely. The presets colors I cannot use currently, maybe later someone has fun to add another little panel with this colors and events to set them to the palette event. Currently its not that important I would say.
On the left side much space is wasted, it seems to be meant to change some pens at once, not only one as I need, but its working.
I also did a little bit research about the redraw problem if an ASL requester (or this one) is open, and hey the creators of MUI also thought to this problem, and there is a solution for it AROS MUIM_Application_CheckRefresh….. sadly its is not implemented in AROS, it does simply nothing.
Last days I didn’t have much time to work on EdiSyn, much other things to do. And played little bit too much with the contents of the About box which should be introduced *shame on me*.
I added a smooth text scroller, seems magorium had the same idea and made crossfader. hmm both is nice, so I included both for the new release.
Besides this I got an idea hoe to slove some of the loop Notify problems. I also got a crash report, seems also related to the loop notify thing. Two things to reduce the notify loops: 1. Check if the value is changed, and only send to MUI if it has changed. 2. Block the Event if the Value is set by the interface. This should reduce the loop notifies and maybe the crash as well.
An other thing I noticed, seems I had a BIG memory hole in the code when drawing transparent Images to Canvas. The Canvas did no destroy the rastport/bitmap which was created if this Canvas is a free floating canvas, so not connected to a window/widget.
So here is a new release with some bugfixes and little improvements
EdiSyn 0.33
News:
- FIX: Beep also when searching backwards (Shift F3)
- ADD: Warn if a file is already open in the editor, jump to this tab
- ADD: Show full path in Window title.
- FIX: crash for un/checking TRadiobox
- ADD: About Box
Download at the EdiSyn Page
Some tiny improvements for EdiSyn:
- ADD: Bookmarks (Ctrl + Shift + 0..9 for set, Ctrl + 0..9 for jump to bookmark) in the picture Bookmark 5 is set.
- ADD: Bookmark bar can be switched on/off
- FIX: Crash when close a Tab via key removed (Focus issue)
- FIX: Better/faster creation of new Editor pages
- CHG: Show only every 5th line number, looks not so crowded
- FIX: TabStop setting for Replace Dialog (use tab from search to Replace edit field)
- CHG: Use MUI Requesters instead of EasyRequest -> looks nicer and the Window behind gets redraw events.
Download: EdiSyn 0.31
Woah, this winapi things in LCL is really crap sometimes… especially when it comes to doubled functionality. Exactly this is what I hit when I use Scrollbars. A single Scrollbar was easy to implement just some position conversation needed. I thought now all scrollbars would work… meeep … wrong, of course, the two fixed scrollbars for other wincontrol you have to implement separately. 🙂
Need me some hours to figure out how this work. and make it possible, now it pays that I made the Objects for the MUI classes so open, easy to reuse of „other“ purposes, for example this scrollbars. Works rather nice already, the biggest problems are always the loop notify calls, or what MUI think is a loop. If I move the scrollbar very fast.. its not a loop notify.. but just again changed in the time the event fired… so position gets a new value.
The caret problem was much easier than I thought. The caret is directly drawn to the Canvas, outside an Paint event. I noticed there is a variable to fire an invalidate instead of paint it. And voila, some other (QT, GTK) seems also need this event because not allowed to draw outside paint event.
Synedit with Working scrollbars
Finally there is something to see in the Synedit control.
Last week I managed to get the lcl so far that it does not crash anymore when there is a synedit inside the window. But there was no drawing at all. Now I traces some deeper into the paint routine of it and manage to let it draw. Many of the WinAPI calls needed were just not implemented in the AROS LCL. A Big step towards a Lazarus at AROS.
It’s not completely working, but you can move the cursor (visible when you hit a begin/end -> Highlight of both) and you can fold/unfold pats of the source by clicking on the boxes on the left side.
The Caret is now shown, I guess due to XOR things missing and typing does not work, which is a little bit strange, the events are there and fired, in the games they are working nicely and the cursor keys work.
SynEdit Control in AROS
I worked a little bit more on the ImageViewer „APict“ included Zooming and Move with Mouse/Scrollbar, fixed a lot of bugs in my LCL code. Especially the scrollbars was hard to understand, because the MUI scrollbar and the LCL Scrollbars work a little bit different -> need to convert the Positions/Pagesize/Min/Max.
The Result works very nice now, this could really a very helpful tool for me, (even at Windows/Linux) to sort my files. My Plan is to insert some file functions also (delete or copy/move the currently viewed File to an other Folder, this is what I miss in most other image viewers)
At the moment the image loader is rather slow, but I remember I found faster routines in the web maybe later I give it a shot, or make some clever „preload“ of next image.
Download:
APict 1.1 for i386-aros
Source again available at GitHub
Some years before I played around with raytracing a little bit. I was amazed that this old source just compiles at AROS and work 😀
As long I’m working very much with images at the moment and the internal tools of AROS seems to have some problems with some special BMPs I wrote a little own Image Viewer for me (a little bit with IrfanView in mind)
At the moment I only opens BMP, ICO, JPG, PNM, PNG maybe later will add some more, I remember I had a very nice image library which compiles out of the box on AROS, could be used then for TIFF/TGA and so on as well (maybe even IFF?)
Until now it is no AROS specific things inside, but maybe would be a nice thing to make an example Datatype loader in pascal language. But atm for my needs this is more than enough to fast browse through my images saved in one debugging session
APict 1.0 for i386-aros
Source again available at GitHub
Still fighting with LCL drawing and Event calling, especially the Pen setting and loops in Event makes me headache. There are still some problems inside but I cannot figure out what.
For tests I wrote again a little Testgame, this time a Minesweeper clone.
The Source is again available at GitHub.
FPC Mines on AROS
Same as for the last game, I wrote it in Lazarus Linux and tested in AROS, both looks rather the same. From time to time I must recheck at windows also.
Download for AROS
Some time before I created a own MUI/Zune class with freepascal to check how this is done and if it opens the possibility for ownerdrawn things in LCL with MUI. It worked but then I put it aside and didn’t care much about, but now as I restarted the MUI Interface for LCL I got it out again and tried to implement.
It’s called LCLGroupClass and created with (MUI-)Group as Basis. In principle its just one difference, The MUIM_DRAW is handled by installing a clipping range and call the OnPaint Event of the connected Pascal object, which then send the paint message to the LCL-Component.
But this was only the half way to go, the paint message also must do something or I can not check if it work. So I traced back the Panel drawing routines to the basic platform dependant function to draw and implemented them to the LCL MUI interface: DrawText and Frame3D. First it looked very easy, espeically the text drawing… but it became tricky again because the GetClientRect routine also have to work properly. The Documentation is very thin about this things, mostly non-existing. But when trace back it become obvious that LCL is still a one-to-one conversation of VCL and hence of Win32 API. So the MSDN help, which is really good was very helpful to find the right way to implement the drawing functions.
Thats the status now:
LCL MUI Panel in comparison with Linux LCL
As you can see the normal Panel border look already very like the original (atm there is not color support so I just use black and white for the shadow/highlight color, Maybe later would be interresting to find out the MUI settings for shadow and highlight) and the Text is more or like in the middle of the panels.
The Panels are still completely transparent, I guess because I still didn’t implement the FillRect routine which is used for initial cleaning.
If this is done, I think I do not need to call the original MUI drawing routine anymore, just use the LCL drawing.
