Traveling is nice, but also nice to be back. As wrote in he travel blog entry I worked on the MUIIDE, especially on the Menu creating stuff, which is quiet difficult things, but prepares other stuff to come (like listview and lists). You can create now very easily Menus with Submenus with the IDE.
There seems to be a little bug, sometimes when I change a combobox active entry, the GUI does not follow it. I debugged it a little bit, and it seems like and updating problem, because after resizing the window everything seems to be normal. Needs some more investigation.
I’m currently on travel in Hong Kong, China and South Korea. I bought a PowerBook to take with me as my only Computer (+ mobile phone of course). The plan was to work a little bit on the free time on the MUIIDE and try MorphOS on the daily use.
Now some time is passed and it worked rather nicely. I had some problems in China to connect to the WLAN access point (it somehow worked but very slow). I switched to mobile phone 3G/4G WLAN sharing (iPhone) to MorphOS which works nicely. In South Korea and Hong Kong the WLAN in Hotel works flawlessly. Now it’s common that every Hotel room has it’s own WLAN access point in the room. If you often switch the Network it’s a little bit trouble, because sometimes the Network will go down when then WLAN disappears but will not come up again if it appears again (or an other known one). Even go to Network settings and force to the new WLAN does not help, but after a Restart of the Computer everything is fine.
Basically that’s the only problem I noticed, everything else works nicely. listing music with Digital Audio Player, Check emails via OWB or SimpleMail, Check my servers via SSH, Watch movies with MPlayer (via from USB Stick) writing code with Scribble, compile with FPC 😉 handle git with MoGit and git, surf Web with OWB (shows nicely chinese characters) and of course write this Article with image upload ;-). Overall not bad certainly daily use compatible for my usecases.
Finally I got it working saving and loading also works now for events, as I described before I had to relocate the complete Eventhandler routine to make that possible (in an abstract way).
Now it’s also possible to add multiple Windows. (But only the first one is open by default), I have to think about how to solve it, but of course you can open the other Windows in the OnShow Event of the MainWindow. Or as I show in the Video on Button Press.
A little demonstration (featuring “awesome drawing skills” icon 😉 ):
Notice to me, stop Delitracker before recording, or the mouse pointer whips with the Music 😉
After that is finished I guess the next one will be properties which are other classes, like Menu or List at the ListView.
I also have some ideas how to deal with special Values (like the Window inital position, MUIV_Window_LeftEdge_Centered and so on) but this will need a little bit more thinking and of course much work 😛 .
Back to topic, after this little Vampire excursion, I continued working on MUIIDE especially the loading and saving, atm. I just save/load a project file which is a simple XML very easy for Trees to handle in XML and also can save nearly every content. But of course with this it will be not possible to export the source code and reload it to add an additional item… especially if you changed the source. It will be very difficult to make that happen, of course Lazarus does this… but Lazarus is a code monster difficult to dig out how this is done and maybe thats even not transferable to my code. I’m not sure what to do here.
Loading and saving for the properties is already finished and working well, but at this position I noticed that I did the eventhandler keeping wrong this way I can not save them to the project file, seems need some more thinking.
After that is finished I will try to add class properties, like Menu (Window), List (on a ListView) and so on Also thinking about to make the project multi window compatible, so that it really can hold the complete application not just a window, then the root of my Tree should be application and not Window.
I created a repository for MoGit on Github today. It was also the first time to really use MoGit in a real world situation and my first push using the MorphOS git client. Sadly there are some problems with the local certificates so I had to deactivate the certificate checking but besides this it worked nicely, MoGit and git. I was able to push to Github :-D.
Wrote a little Makefile and added the MUIClass compilation to the Jenkins build server. On every change in the repository it will recompile MUIClass for all available platforms. At the occasion I noticed that I did some errors for 64 bit (Integer – PtrInt) also corrected this. The Jenkins compilation create a little archive with the compiled units, IDE and examples. If you download them together with FPC release archive for your platform it should be directly usable. It also creates the documentation directly and as archive on the build server.
The exception handling I mentioned yesterday is improved. To satisfy MUI/Zune I put a try, except into every hook function before calling the Eventhandler, it makes sure the program returns from the hook to MUI/Zune. Of course the basic function is still the same, if the User decide to break the program, it will be terminated or if you connect the OnException event is assigned it gets triggered.
When an exception appears which is not covered by any try/except the program will just end (and print the exception to Debugout) which is not very nice. Again take some idea from LCL and catch all exceptions in the Event handler and show to user as nice MessageBox. But MUI certainly does not like it if you leave the Eventhandler in such a rude way 😉 (at least Zune on AROS) so after it the Eventhandler is dead because Zune thinks this is a circular calling. It’s not true but it’s prevents you to call that event again. Best thing here is to end the application an restart. Therefore I ask the user what to do, ignore the exception, knowing that this will have strange effects, or leave the program directly.
The ignore could be interesting if you have the chance to save your data before closing the program. Of course the writer of program can also override the Exception handling (via OnException Event in MuiApp, as used to from Delphi/LCL.
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).
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.