I worked a little bit more on this mouse movement problem and I think now I got it and voila also the displacement bug of Menu disappeared. so now menu and combobox looks ok to me.
The maximus editor didn’t start at my machine anymore.. a little threading bug was the reason.. I didn’t know they use threading… in a EDITOR! how useless.. seems its meant to check for filesystem changes. But… to be honest.. a Timer would do it in this case.
I wanted to try maximus because I remember there was a strange font bug inside: The position of cursor does not fit to the char position. I tried a little bit, but in the end I have to say.. the maximus ist just poorly written. It just takes a width of a char to calculate the cursor position. By default a fixed width font is set, of course with fixes font it works. But this font seems not available by default in AROS so it uses the default font which is NOT fixed width. If no ini file is there for maximus it uses „#Edit2“ as the default font which is „Courier New“.. I changed the default to „ttcourier“ which is available by default in AROS. The #Edit1 I changed to „fixed“ which looks nicer for me. but also other fonts like sans mono or so work nicely.
The uidesigner is working.. but the movement of items is hard.. because it always jumps around. I noticed a hack in the GDI (Windows) implementation of FPGUI which captures the mouse when the editor is there. I also implemented this behaviour and now it moves smoothly.. In fact I did implement before already.. but the initial call to activate this function was missing.
As last I tried every single example in fpgui (
Initially I thought the reason is that there comes so seldom messages from aros.. but then I measured the time between messages and it is really short.. 0 to 20 ms, so no or one task switch. so thats not the reason it fires so seldom. In the timertest there is a Timer should fire every 50 ms but it looks more like 500ms-1s. Finally I found the reason, the time when the Timer should fire is determined by a Now() call. My Millisecond count in the result was just wrong, alawys an order to small. Type mismatch in the converter routine.
So now the animtest also works rather fast.. hmm I always thought my image drawing routine is so slow that I should improve it, seems it is not THAT slow 😉 OK in the colorwheel example you can see that it is VERY slow ;).
I think this changing are very important, it really improves the fpgui functionality a lot. So I created a release today for public again.
Available at the FPC DownloadPage