Hello, first Great Work!, if I try to compile qt lcl svn (rev 11443) in lazarus I get:

lazarus/lcl/interfaces/qt/qtwidgets.pas(1052,49) Error: Wrong number of
parameters specified for call to "QMouseEvent_pos"
lazarus/lcl/interfaces/qt/qtwidgets.pas(1137,49) Error: Wrong number of
parameters specified for call to "QMouseEvent_pos"
lazarus/lcl/interfaces/qt/qtwidgets.pas(1166,49) Error: Wrong number of
parameters specified for call to "QWheelEvent_pos"
lazarus/lcl/interfaces/qt/qtwidgets.pas(4081,34) Error: Incompatible type
for arg no. 2: Got "PPoint", expected "PQtPoint"

My System is Kubuntu festy amd64 fpc v 2.1.5 qt binding 1.41 (Qt 4.2.3)

Thanks a lots

Best
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/qt/attachments/20070708/89f96632/attachment.html>

Also reported: http://www.freepascal.org/mantis/view.php?id=9220

Paul fixed this.

pm Vincent Snijders wrote

Also reported: http://www.freepascal.org/mantis/view.php?id=9220

Felipe, can you check on Darwin if the Points are correct now ? Can you close this bug?

I still would prefer that Types.Rect would have been adapted.

regards,

Den Jean

Den Jean wrote

Felipe, can you check on Darwin if the Points are correct now ?

I just tested, and they are again incorrect.

Can you close this bug?

Closed.

I still would prefer that Types.Rect would have been adapted.

This can't be done because we have dozens of libraries, each with a sligtly different Rect definition. The Pascal RTL is yet another library, and there is no particular reason for making it's rect compatible with Qt instead of compatible with whatever rect type is used on Gtk, or Carbon, or on OpenStep, or on SDL, etc, etc.

I did not ask a Qt compatible Rect, but a Mac compatible one. For win32 it is already done by FPC, see below, why not for Mac. Qt nor any other lib are the point, but Mac API,Win32 API, ...

./rtl/objpas/types.pp :

{$ifdef Windows}
  TRect = Windows.TRect;
{$else}
  TRect =
{$ifndef FPC_REQUIRES_PROPER_ALIGNMENT}
  packed
{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
  record
    case Integer of
      0: (Left,Top,Right,Bottom : Longint);
      1: (TopLeft,BottomRight : TPoint);
    end;
{$endif Windows}
  PRect = ^TRect;

Den Jean wrote

I did not ask a Qt compatible Rect, but a Mac compatible one. For win32 it is already done by FPC, see below, why not for Mac. Qt nor any other lib are the point, but Mac API,Win32 API, ...

indeed ... I just checked and the rectangle type utilized by Carbon is equal to the one used by Qt.

indeed ... I just checked and the rectangle type utilized by Carbon is equal to the one used by Qt.

Sorry, I didn't follow all discussion and I'm very short on time in this period to research on my own,
so I might be saying something stupid :P

Note that in Carbon two kinds of rectangles do exist (see FPCMacOSAll): Rect and CGRect.
The former is similar to the win32 (and lcl) one, while the second is made up of float values, and has
coordinates flipped upside down (that is, 0,0 is at bottom-left instead of top-left).
The former type is generally used for controls, while the second is used when drawing with Quartz.
In compositing mode there are the so called "views", now I don't remember if with view apis the default
coordinate system is the Quartz one, but maybe that your problem is somehow related to this fact?

Maybe these links can be useful:
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/chapter_2_section_6.html http://developer.apple.com/documentation/Carbon/Conceptual/HIViewDoc/HIView_concept/chapter_2_section_5.html

bye,
Giulio

pm Giulio Bernardi wrote

The former is similar to the win32 (and lcl) one, while the second is made up of float values, and has coordinates flipped upside down (that is, 0,0 is at bottom-left instead of top-left).

It is not the coordinate system, but the physical layout of the storage of the variable TRect.

win32, Qt, VCL also have views, worlds, ....

pm Felipe Monteiro de Carvalho wrote

I just tested, and they are again incorrect.

Hum, I forgot this.
Can you make a small program to test this in detail

use e.g.
function QWidget_x(handle: QWidgetH): Integer; cdecl; external QtIntf
name 'QWidget_x';
function QWidget_y(handle: QWidgetH): Integer; cdecl; external QtIntf
name 'QWidget_y';
procedure QWidget_pos(handle: QWidgetH; retval: PQtPoint); cdecl; external
QtIntf name 'QWidget_pos';

and look on the screen, when moving the pos of a widget.