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:

Layer := WhichLayer(@(Screen^.LayerInfo), Screen^.MouseX, Screen^.MouseY);
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.

3 comments to "Fixing Bugs #1"

  1. Anonyme sagt:

    Perhaps a little help, at least you might free some typing time…

    //Good luck

  2. marcus sagt:

    Thank you very much.
    Did you still use Freepascal on AROS? How its going, seldom see you Aros-exec this days.

  3. Anonyme sagt:

    Do I still use AFPC ?

    I head a big harddisk crash on my PC, I think the HD motor did terminate… Itself. Everything was lost.

    I am trying to set up a new system… I have installed AROS once more. Still not installed FPC or anything else, I have downloade it though (the latest).

    AROS-Exec presence:
    From time to time, I follow the overall progress… I still like to see a fullky working Amiga system – With some other various OS additions to it. I also redownloaded a new password as well, so I could login again if I need to write something.

    How its going?
    Pretty well… Got my but full with work and family and are getting older. But other then that, everything goes well.

    If we stop talk about me, I see you have changed FPC a bit, turned to fpcGUI? Nice…


    Here is an idea as well… I know, it has been up before. And I will not bother you with it again. Nor will I discuss it either, I just leave it here for you to meditate on.

    OWB… lets assume the graphical document object behind the app OWB is the OS GUI.

    Lets assume the FPC TFORM is the OWB document object?

    What if this graphical document objects, that seems behave well together with javascript – in the OWB document object model, was „moved“ to and attached to a TForm document object model… Either directly to a TForm or indirectly to a special owner of these objects – like a custome TPanel or something…

    IF this is possible, then what you win, is more visual objects that could be used to a visual designer editor.

    With that you could get an easy to understand tool, even if it is not fully compatible between Amiga Flavours other OS’es.

    This leads to more users that would like to do something with the GUI instead of coding a gui. This leads to more customers so to speak, they bring the development of AROS further with newer smarter, nicer, better tools, utilities and apps.

    ups… Sorry. I am not as evil as I might sound like, I mean well… And please do not reply to this last junk.

    What I meant was an idea to see other ways to get to the same result…

    Anyway, I have not yet checked out your sources completely – But I know I did some fixes (for me) on some AMIGA units

    (some tested back then, some not – all did compile though)

    you could find links at:


    //over and out, read you later.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert