Hi,

it's fully unclear to me what was meant from whoever wrote this portion of code in customdrawnwsforms_x11.inc (starting from line 97) :

   if AWinControl.Parent = nil then
   begin
     {$Note This doesn't work yet. I want to position a new window relative to
       another window. Used for popup windows, like the TComboBox dropdown. }
     {$IFDEF DEBUG} writeln('SetPosition with no Parent'); {$ENDIF}
     lx := APosition.x;
     ly := APosition.y;
     XTranslateCoordinates(CDWidgetSet.FDisplay, lWindow,
         XDefaultRootWindow(CDWidgetSet.FDisplay),
         lx, ly, @dx, @dy, @cw);
     lx := dx;
     ly := dy;
   end

This portion is execute to position whatever control is a root window, as opposed to controls inside a windows. The effect is that XTranslate returns garbage in dx and dy, and any attempt to position a window fails.

By commenting out the XTranslate and the following assignments, window positioning is correct (poDesigned, poScreenCenter, etc. or simply Top:=Something or Left:=SomethingElse.

I assume that the idea is that a TComboBox dropdown may be higher than the widow containing the widget, and therefore a new window is required, but IMHO, the simplest way to position a new window relative to an existing one is that whoever creates the new window decides its position on the screen relative to the existing one, and gives the Top and Left values accordingly, without attempting to use a function which isn't intended for that purpose.

Am I missing something?

Giuliano

Giuliano Colla wrote

Am I missing something?

It is code copied from http://sourceforge.net/projects/fpgfx/ so no wonder that you found something which makes no sense for the LCL =)

Il 22/03/2012 16:12, Felipe Monteiro de Carvalho ha scritto:

Also the code (which I haven't yet located, maybe because I didn't yet search for it..) to update the actual position of the window on the screen comes from the same source?

Because apparently it takes into account the window decoration in the wrong sense. If you position a form back and forth, the position is offset each time of an amount equal to the title bar height. In the long run the form goes to the bottom of the screen...

There's another interesting problem with anchors: anchor right/bottom doesn't appear to work correctly.
What's anchored right disappears, and what's anchored bottom raises an error (or the other way around, I just made a quick test).

Debugging a new widget family is a lot of fun! ;-)

BTW, in order to check if paint messages dispatching through X gave some penalty in time, I logged the time from the moment when the message is sent to the moment it's received. Except at startup, where around 50ms are required, in all other cases the delay is from 0 to 3 ms. No worries on that side.

Giuliano

Giuliano Colla wrote

Also the code (which I haven't yet located, maybe because I didn't yet search for it..) to update the actual position of the window on the screen comes from the same source?

The entire X11 backend comes from there except the main loop and parts of the drawing mechanism which I created some time ago.

Just send in the patches =)

Il 22/03/2012 19:13, Felipe Monteiro de Carvalho ha scritto:

Fine. I was very cautious in making changes, afraid of breaking things that you had carefully crafted. Now that I know, I'll not take anything for granted.

Giuliano

Giuliano Colla wrote

Fine. I was very cautious in making changes, afraid of breaking things that you had carefully crafted. Now that I know, I'll not take anything for granted.

One thing to watch out, however, is compilation in other backends. Every uncommented winapi routine implemented in a backend needs at least a skeleton in all other backends, see
http://bugs.freepascal.org/view.php?id=21534

Il 23/03/2012 09:16, Felipe Monteiro de Carvalho ha scritto:

Thanks, that's something I was aware of.
Needless to say that from time to time I'll forget and break Android or Cocoa or whatever, but that's where the fun comes. To find out which fix for X11 has broken everything else... ;-)

Giuliano