Working hard on the Event stuff for the MUI IDE. Hardest Part to find out how the Eventhandler parameter are via RTTI. In the end just some pointer calculation inside the RTTI structures.
The program already does some basic Source export. So it is somewhat usable! But I’m not sure if that is the final version or I will go the LCL way of some kind of hidden properties (for now the properties are written directly to the Source).
Some impression:
For sure is not finished, it has not saving/loading feature source name and editor name for editing the eventhandler are hard coded, and so on. But for now thats already very cool, at least I think so 😛
My MUIClass implementation is already rather advanced, the basic items are implemented, most of them are even tested and documentation. With this tools you can already write rather easily MUI GUIs but it would be even nicer to use a GUI to create it (especially because on some fields I’m not completely sure how this influence the final result). Already long time before I had some concepts for that in my Head but with the plain MUI classes and my little MUI knowledge thats just too difficult. Now with the MUIClasses and my increased knowledge when writing them 😉 it is possible. The Basic functionality of adding Stuff and changing properties are already there, all completely abstract (via FreePascal RTTI), so I do not need to implement every field for it by hand.
A little demonstration:
For now I only added some basics (Button, String, Text, Group) But the rest is rather the same. There is still much thinking to do with the advanced classes like ListView and so on (how to connect the List to ListView) and EventHandlers but this should be solvable. Also the Source export is not implemented until now, because I’m not completely sure which way I choose.
Basically there are two ways. The first one is more or less like Lazarus does it: The properties you set in the IDE are written to a resource file and without seeing them in the final sourcecode they are streamed to the objects on creation. If I choose that way I would not use resources (because Amiga68k still have no support for it) but maybe an include with a xml/json text which describes the GUI. This way has also the advantage that it is easier to read it back later (if you reopen the file in the IDE again).
The second way would be like fpGUI does, the IDE produces the complete Source to set the properties in the Source code. (with some helper comments to find them back when you reopen it). Advantage much easier to implement on the Saving Side, Disadvantage the Loading part can be very tricky if the User changed the Sources somehow. Still to decide, but so many other problems before that appear so no worry. 😛
Working on the documentation for the MUIClass objects and also implementing Dialogs (File, Font, ScreenMode). Found some stuff to improve in the MUIClass objects when writing the documentation, missed some fields, forget some return values.
The documentation can be found on this server.
Working on the DrawPanel, thats an MUI Area object which exports the usual Events you know from LCL objects, like OnPaint (here OnDrawObject), OnMouse____, OnKey____, such stuff. With this it is very easy to create a simple painting application:
(Notice my awesome drawing skills 😉 )
With it, I developed a TDrawBuffer, which saves you the work of Allocating a Bitmap, create a layer and RastPort. I noticed I have this kind of code in many of my MUI applications, therefore it make sense to make a little handy class out of it. I could have some more functions. I tested the whole stuff on Amiga, AROS and MorphOS and it works fine on all of them, very nice.
Currently I’m working on the idea I had long time before. A pascal interface to MUI classes. MUI uses Amiga boopsi interface to access the GUI elements. But thats not very convenient, especially for pascal users. I started already two time an approach to create such classes. The main problems are the fields which can only set in the moment when the object is created and the TagLists which does not tell you the type of a field you have to cast everything to integer. In LCL I supply the properties as Create parameter TagList, so it’s just the same as using the plain MUI functions.
In this MUIClass implementation the pascal classes will only collect the field values and create the MUI objects on the actual application run and window open. You have more chance to interact with the objects before the MUI objects get created.
It makes the MUI programming much easier, I like it. I’m thinking to change some of my programs to that system, the code looks much easier to read. The code is on GitHub under a public domain license.
