I try to find the displacement bug. I do not believe that it is some kind of fpgui bug.. and my debug output seems to tell me exactly the same.. it seems that my widget really try to send the right coordinates for a scroll bar (scrollbar is the most common problem) but the AROS Window does not move to there, but move some pixels more/less (depends on movement directions).
At this point I asked myself, how AROS knows where to paint the window?, because the window is REALLY there.. it reacts to clicks and so on, but the window coordinates tell its at a completely different position. Than I found a strange thing for the displaced case… the WindowLayer (PWindow^.WLayer) is at the wrong position. I can directly investigate after the movement for example the window^.top moved by 15 but the Window^.WLayer^.Bounds.MinY moved by 22 pixel. The difference is 17.. hmm suspicious this is width of the border decoration.. but this window has no border… but of course the top window has one. Solution unknown, I have to think about.
The second thing I investigated was the wrong mouse position in Menus/Combobox. In principle the solution was very easy.. even, again, very strange.
First things first. I have a Zero Zero window as top window usually. ZeroZero because then I don’t need to care about paint over the edge when drawing and do now need to calculate. The mouse position in this window work perfect. Also for borderless window, where I switched off the Zero Zero because do not need it (and it troubles the access, seems AROS still try to remove the borders, so I get negative values in side the Window).
So far it work.. but my Widgets are also borderless windows inside this top window (Parent-Children) and the mouse position in this windows seems to depend in what kind of Window they reside, if the parentwindow is a zerozero window with borders this borders also have influence to the mouseposition in this children. After some forward-backward calculations I think I got it right now. there I also found some bugs for Leave/Enter Events.. and Events to not Active Widgets (Mouse Move).
The result is that the Combobox now work much more smooth, always get the right entry when point to it, you can even close it by clicking outside the Combobox window. Also the Menudemo works much better, get the right selection as expected. If you click outside the menu the menu does not close (ESC close it) but this seems by purpose, but it also does not anylonger click to the nearest entry as before. The only Thing what seems to be a little bit strange: the menu opens directly above the MenuName. I thought its some kind of move displacement or WindowToScreen coordiate miscalculation. BUT for the ComboBox it works perfectly. So If I change it to the right position for menu its completly wrong for the combobox. Also something I have to compare, maybe compare in the FPGUI source code to see why it is different.