Archives for FPGUI

Buggy Bugs and difficult keys

Posted by ALB42 on 15. Januar 2013No Comments

Sometimes when a Button or so is destroyed in runtime the software crashed because in the messageport still some messages for this particular object and I have no chance to see if it is still alive.

First Idea was to poll all messages before destroy this windowthis was implemented when writing the Message for 07.01.2013 in this blog the first error report. But now I noticed sometimes a stack overflow appear when large windows are closed.

When searching for CloseWindowSafely Amiga  you find a lot of source snips which all do the same, remove all messages for this window from the messageport.
for example this
So the StripIntuiMessage is exactly what I need, conversation to Pascal is simple, the problem was it didn’t change the problem. I changed the routine that it counts how many messages are there and how many are removed. So at least it does something. Then I let the routine run twice one after the other so the second should not find a message and the overall should be smaller (because removed messages). I was surprised that the messages are not be removed.. so both runs are identical, I’m not sure whats wrong with my routine it does exactly the same as this C routine. So in the end I wrote a complete new routine, which gets all messages with GetMsg and then put them back with PutMsg when they not belong the removed window. Task done, now its working.

Another task I set for myself was the keybinding for fp-editor, and this is really crap, finally I think it would be easier to make a very big table for all cases, so all keys combinations with shift, alt, ctrl, sounds crazy but this keycodes have no real systematics. The most keys are working already… so menu keys, copy paste and so on, are working also mark text with keys is working, but still need some testing.

Fixing Bugs #1

Posted by ALB42 on 7. Januar 20133 Comments

As long I wrote down so much bugs I should also begin to fix them. I will collect some more before I make a release.

The first one:

– sometimes a dialog window freezes complete AROS, when closed via OK button  -> workaround: use X of window to close

is a very hard one… there are some problems come together, first a little bit about the problem:

I have very much windows (because every button, memo, edit usw. all are windows) so I decided to have one Global message port where all my messages arrive together. The messages have a IDCMPWindow field  where I can read which Window recieved the message. Now when someone press the button to close the window it can be that there are some more messages for this Window. So the Window is destroyed but some more messages for them appear. Solution sounds rather simple but was not because of structure of fpgui: When I destroy a window, then I check if there are some more messages for this window and remove them.

 – displacements of menus and comboboxes

party solved, so at least the mouse position is right when selecting entries… but its still a little bit too high.. and for comboboxes its too low

– wrong key binding

magorium from Aros-Exec forum reminded me that AROS send press and release message… But my implementation does not… I got one message only. I noticed that the message is not sent if IDCMP_VANILLAKEY is set… which is practical becasue you get directly the pressed char… IDCMP_RAWKEY gives only the keycode. But there is a very nice function in kemap.library to map the keycode to the char: MapRawkey. So I wrote a unit for keymap.library. The result is that I now have the exact key down and key up messages as I need them. I noticed that some crashes disappear (in UIDesigner when delete an item).

– change of focus with Tab does not change focus

This was rather easy to solve, I just looked into Windows implementation.  So before send the key message to the item get the focussed item with FindKeyboardFocus.

– Missing concept of modal windows

Modal windows work now, its already well prepared in the fpgui interface, there is a field TopModalForm where one can get if a modal window is open at the moment. So I also implemented a function that the modal window is (re-)activated if an other window is clicked.

– Mouse over, MouseEnter MouseLeave still no way to implement

not really a implementation for it but I have an idea just as reminder want write down here. There is a function WhichLayer in layers.library seems exactly what I need.

all together should be something like this:

LockLayerInfo(@(Screen^.LayerInfo));
Layer := WhichLayer(@(Screen^.LayerInfo), Screen^.MouseX, Screen^.MouseY);
UnlockLayerInfo(@(Screen^.LayerInfo));
if Assigned(Layer) then

Result := Layer^.Window;

With this should be possible, just need to write the layers unit and check how this leave and enter messages work.

Feeling like in school

Posted by ALB42 on 6. Januar 2013No Comments

serk118uk in aros-exec Forum reminded me of the „good old days“ where „it was just little bluescreen with ide and (F5) to compile..“ turbopascal, freepascal has a very similar surface with a turbo vision like surface. I remember that the ide for morphos is already prepared and working, so it should be not so difficult to bring it to aros. So here it is…. I’m feeling younger than ever.

Freepascal ide

besides this I worked on the key press problem it seems now its completely working (except § and some special chars but i dont‘ know why I also need an other keyboard for my computer… this one has no right amiga key so I can’t test it (and no copy paste).

The menu shift problem is partly solved but still needs some testing.

I’m also aware that finally it will be important to write a sort of installation manual and readme for fpc@aro. Also the release archive must be reorganized before it can be a real release of fpc with fpgui. I hope soon I have time for it.

Show Windows Program

Posted by ALB42 on 2. Januar 2013No Comments

There is a Window inspection tool in AROS called WiMP sadly it does not show Parent relations for the windows, which i use now intensively.

So i wrote an own program to inspect the windows also bring them to front an paint a red border on it (see screenshot) and show properties (especially the IDCMP flags and flags as Text not only as number).

ShowWindows in action

It was a good way to find bugs. Some small I fixed already. A big one hindered me to write the program directly in maximus compiled on AROS. Some keys seems to send a double key to the GUI mostly when Shift is pressed (for example Shift-L seems sends also the key-up to the gui so the cursor goes one up then write a big „L“), need to debug. but besides this problem it worked rather nice. Also the UIDesigner worked rather nicely to place buttons, edit properties, even movement of items is very slow and atm. its not possible to delete items placed (have to check why).

The Source is included of course.

Some more informations about „new“ fpgui aros version

Posted by ALB42 on 30. Dezember 2012No Comments

I want to supply some more informations about the current FPGUI implementation for AROS and about the lcl problems.

First about known Problems (starting from worst):

– sometimes a dialog window freezes complete AROS, when closed via OK button  -> workaround: use X of window to close

– crashes in HandleAlignments there are some problems with alignment resulting in circular calling of size function -> there are some code to prevent this but it seems its not always working, big windows with much items and much alignments still produce crashes in „HandleAlignments“

– There are 2 types of windows in AROS, „normal“ windows and GimmeZeroZero(GZZ) windows, the only difference is that the 0,0 postion on a normal window is on top left edge of window decoration and for GZZ 0,0 is top left edge of user area. Atm I use GZZ for windows without a parent -> so real windows with decoration and so on. and normal windows for all items inside the window(Buttons, Labels and so on). So far ok, now we approach the problem, I guess. Popupwindows like Menus or combobox windows have no parent either but they are borderless. Now open a menu by clicking on the entry, the menu opens some pixels to high but the mouse position is at the real position so some pixels under the drawn position. Now guess how many pixels… right, the displacement is exactly the width of window decoration. I changed this behaviour already some times… but always i get the problem: I get this displacement of menus or the click on Buttons and so on does not work anymore because of displacement. Needs a little bit more thinking about „window“ types I guess.

– File requester does not work when starting on drive level, When choose for example „SYS:“ an empty list is shown, sometimes a list of SYS: is shown but when click an entry it says can’t open it. -> Path converting routines still not working for aros well. (maybe change the filerequester to native AROS but it would need a big impact to the „core“ fpgui)

– Mouse over, MouseEnter MouseLeave still no way to implement the mouse enter and mouse leave routine and send the mouse move event to the item under the mouse, instead of the one which have the focus (except the capture mouse routine is called). -> This needs some thinking I guess and again the problem -> which item is under my mouse pointer… which I skipped by changing all items to windows, but now it catches me again, I just hope to find the window under cursor is easier, still had no time to check.

– change of focus with Tab does not change focus in AROS, create 2 edits typesomething in the first, press TAB type some more, cursor is drawn the the 2nd edit but new chars in the first edit. -> needs debugging

– Drag and Drop does not work -> no idea how to implement currently because I dont know how this is working in AROS/Amiga

– Splitter does not work well -> needs some debugging to see why you can’t grab the splitter to drag it.

– Mouse Pointer, The change of mouse pointer is not that easy on AROS (except busy pointer)

– Missing concept of modal windows (The „modal“ windows are just normal windows atm. so all other windows are fully functional)

– Missing Clipboard, I just never cared about up to now (at AROS or Amiga i never used up to now)

– Timers does not work well atm, I’m bound to INTUITICKS recieved by window around one per 50-100 ms, no extra event for timer events -> thinking about writing an Interrupt routine for Timer and send a IntuiMessage to the window.

– Hiding of windows is not possible in AROS atm. There is a function for it in intuition.library but it has some strange effects if the hidden window is a child window (has a parent) complete aros desktop get strange effects (see also Thread in AROS Forum from 2009! the bug is still there)  -> Workaround: I change the size of hidden windows to 0,0, which will make strange effects from time to time. An other thing I could do is to change the parent to an hidden window but I’m not sure hpw to change a parent of a window, must first try out in a seperate program, I guess.

canvas drawing problems:

* Line thickness: seems the standard draw routines only support single pixel lines, there is an option for line thickness but it simply does nothing.

* Arc: I did not find a function to draw a part of a circle or even a filled circle, Area functions could be the answer but I had no time to care about because its not a serious problem at all.

* Fonts: Aros/Amiga fonts are a little bit different from other systems. Normaly on Aros font files only contents a single font style normal or bold sometimes italic. Some fonts have the possibility to be changed to Italic, but changed to bold I never found such font, its always saved as a separate font file.-> Could be solved by including possibility to load TrueType fonts.

* I included buffered painting to the Canvas routines, thats the reason it becomes much faster than before, but its still rather slow (compare examples/sprites on Aros and linux or so). The reason is still the difficult way to use colors in aros, with obtaining pens and so on. Sadly it seems there are no new functions directly support chunky modes and 24 bit…. When first copy everything into a non visible RastPort and then justBlit it to the final RastPort, the colors are just not there.. everything is black except 4 first colors. An other thing is masking which is also not easy in Aros with standard procedures.

A Sidemark, the Source Editor Maximus working rather nicely now (of course not completely). The UI Designer works even better but the source created can not be compiled due of wrong(old) uses, but this is also a Linux not working.

Lazarus/LCL:

Lazarus changed a lot this days, I think to get to the 1.0 release. Sadly this makes for me very difficult to compile LCL for AROS (MUI or FPGUI) because now there are much function special for Linux/Windows. As I begun to check the problems I noticed the ,ost of their new things are related to 64Bit and WideStrings,UTF8 and such things…. and no fallbacks to the original functions of Freepascal. At the Lazarus project they have a very bad behaviour to define „not Windows“ = „Unix“ and „not Unix“ = „Windows“which is for sure not true for AROS. So much work for me to change all this statements. but finally I was able to compile lcl and some demoprojects

This compiled lcl is not included in the current release (28.12.2012).

My findings:
– fpgui interface for LCL still very unfinished, TLabel for example still not working, OnPaint events not fired

– perhaps useful for debugging my fpgui things, because Radiobutton does not work but the LCL gives me an error message I could follow to see the reason, perhaps here also a check in Linux could be helpful

– A new „customdrawn“ interface beside fpgui this time directly in lcl, which could be interresting as alternative to fpgui (but changing again…? I’m rather happy that fpgui is working somewhat). The point at fpgui I like is, that the corelib abstraction layer is really simple to understand, so I can concentrate on the AROS problems of the implementation. At LCL this custom drawn interfaces looks much more complicated to understand even the functions should be comparable

FPGUI rewrite

Posted by ALB42 on 29. Dezember 2012One Comment

The last month I was working on a complete rewrite of the FPGUI native AROS interface.

I found out that AROS allows to make windows as a parent to a window (in contrast to AmigaOS) so now every item on the screen is created as a window. This makes it much easier to handle events especially paint with overlapping layers and so on. Its far from perfect but I think thats the better way.

Sadly I found again a drawback there exist functions to show/hide windows in Aros, but they DO NOT work, especially the HideWindow function. Seems its already known in Aros forum long time and still not changed, so I made a workaround and change the size to 0,0 when a item is Hidden, not a nice way but at I have no other idea.

I’m rather satisfied with the result as it is now, so i put it on to the links for download (together with the source of aros fpgui).