Hi,

Dean, I remember that some time ago the desktop size was inverted on Mac. I don't know why, but now it doesn't seam to be inverted anymore (was it you? or how did it get fixed?). Maybe the new fpc fixes it.

But now something else is inverted:

procedure QCursor_pos(retval: PPoint); cdecl; external QtIntf name
'QCursor_pos';

This function will return a point, but it's inverted. X is in the place of Y and vice-versa

thanks,

I added a work-around on the lcl-qt interface (local copy, didn't and won't commit), but that's not enougth. There are more problems. I think that we have this kind of problem on all functions that use TPoint. So we really need a fix on either the bindings or fpc itself.

Felipe Monteiro de Carvalho wrote

I added a work-around on the lcl-qt interface (local copy, didn't and won't commit), but that's not enougth. There are more problems. I think that we have this kind of problem on all functions that use TPoint. So we really need a fix on either the bindings or fpc itself.

hm...I think that TPoint is not lonely problem, even on Linux some functions from bindings returns wrong results , I've tested pure C++ Qt app on Linux and it works ok, but via bindings not.
My example is qwidgets -> procedure TQtCalendar.SignalCurrentPageChanged(p1, p2: Integer); cdecl;
Try to catch those parameters p1=year, p2=month, it returns unbeleiveable result (under pure C++ it returns normal result). Don't know for other platforms, but I'll try this test under winXp this afternoon.

Maybe some compiler option (gcc) is missing when compiling bindings for Mac.It looks like a Little-Big endian problem.

zeljko wrote

Maybe some compiler option (gcc) is missing when compiling bindings for Mac.It looks like a Little-Big endian problem.

That is what I initially thougth when Phil told about this months ago, but that's not it.

My Mac is Intel x86

Felipe,

I doubt if that's been fixed. It's probably unique to PowerPC Macs.

Also, I notice that with the most recent changes to the Qt widgetset, none of the Orpheus controls work anymore. Previously the rotated label and URL controls worked fined.

Thanks.

-Phil

Philip J wrote

Also, I notice that with the most recent changes to the Qt widgetset, none of the Orpheus controls work anymore. Previously the rotated label and URL controls worked fined.

Could you define most recent? If you can isolate the revision that breaks it, it get's easier to fix.

If it crashes a backtrace would be good too.

Just on Mac or others too ?

tnx,
zeljko

I only tested Mac.

This is the first time I've tested the Qt widgetset with Orpheus in a while. I assume it's something in the flurry of changes during the last couple weeks.

Thanks.

-Phil

Hi, Den, please read this thread about interted cursor positions on Mac. If you can't see the old e-mails, I can repost them to you.

thanks,

am Felipe Monteiro de Carvalho wrote

Hi, Den, please read this thread about interted cursor positions on Mac. If you can't see the old e-mails, I can repost them to you.

which thread on which mailing list (mailing list archive url ??)

Den Jean wrote

which thread on which mailing list (mailing list archive url ??)

Exactly this one that we are in. I just thougth that you would see it because on Gmail when someone answers to a thread, the entire thread moves up.

There is the archives URL for the thread in question:

http://www.lazarus.freepascal.org/pipermail/qt/2007-June/000382.html

thanks,

btw. PWideStrings works ok now (v1.38) just tested on Linux.

zeljko

pm Felipe Monteiro de Carvalho wrote

There is the archives URL for the thread in question:

I remembered we discussed this, but did not know where anymore. I just didn't see the above mails, sorry.

http://lists.freepascal.org/lists/fpc-devel/2006-April/007515.html

regards,

Den Jean

Den Jean wrote

I remembered we discussed this, but did not know where anymore. I just didn't see the above mails, sorry.

But now it's with TPoint.

What are you doing with the Qt data structures? Are you just casting them to pascal structures?

Maybe we should instead copy each field separately. This should always work. We can't guarantee that the Qt data structures will be equal to the pascal data structures. The pascal TRect is AFAIK a windows API structure, and on Carbon we just use another rect type. Maybe Qt tryed to use those ifdefs to use only one type across platforms.

thanks,

pm Felipe Monteiro de Carvalho wrote

What are you doing with the Qt data structures? Are you just casting them to pascal structures?

typedef void *PRect;
inline void copyQRectToPRect(const QRect &qr, PRect pr)
{
  *(QRect *)pr = qr;
  ((QRect *)pr)->setRight(((QRect *)pr)->right()+1);
  ((QRect *)pr)->setBottom(((QRect *)pr)->bottom()+1);

}

inline void copyPRectToQRect(PRect pr, QRect &qr)
{
  qr = *(QRect *)pr;
  qr.setRight(qr.right()-1);
  qr.setBottom(qr.bottom()-1);
}

I can fix it here. Should I leave the VCL/CLX alike growing with one ?

regards,

Den Jean

Den Jean wrote

I can fix it here. Should I leave the VCL/CLX alike growing with one ?

could you elaborate some more? what does "growing with one" mean?

pm Den Jean wrote

I can fix it here. Should I leave the VCL/CLX alike growing with one ?

look for "historical reasons"

http://doc.trolltech.com/4.3/qrect.html#bottom

regards,

Den Jean

Den Jean wrote

look for "historical reasons" http://doc.trolltech.com/4.3/qrect.html#bottom

arrrgg .... horrible. Look's like compatibility with some kind of old bug.

About your question, please keep the fix that you currently use. Adding this everywhere we use structures on LCL isn't nice.

thanks,

Here you can fix this by declaring a correct type for pr. Create a pascal TRect type on the c++ source and use that. No need to type-cast things.

similar here.

pm Felipe Monteiro de Carvalho wrote

Here you can fix this by declaring a correct type for pr. Create a

too late, copy/paste did it

typedef void *PRect;
inline void copyQRectToPRect(const QRect &qr, PRect pr)
{
#if defined DARWIN
  ((QRect *)pr)->setLeft(qr.top());
  ((QRect *)pr)->setTop(qr.left());
  ((QRect *)pr)->setRight(qr.bottom()+1);
  ((QRect *)pr)->setBottom(qr.right()+1);
#else
  ((QRect *)pr)->setLeft(qr.left());
  ((QRect *)pr)->setTop(qr.top());
  ((QRect *)pr)->setRight(qr.right()+1);
  ((QRect *)pr)->setBottom(qr.bottom()+1);
#endif
}
inline void copyPRectToQRect(PRect pr, QRect &qr)
{
#if defined DARWIN
  qr.setLeft(((QRect *)pr)->top());
  qr.setTop(((QRect *)pr)->left());
  qr.setRight(((QRect *)pr)->bottom()-1);
  qr.setBottom(((QRect *)pr)->right()-1);
#else
  qr.setLeft(((QRect *)pr)->left());
  qr.setTop(((QRect *)pr)->top());
  qr.setRight(((QRect *)pr)->right()-1);
  qr.setBottom(((QRect *)pr)->bottom()-1);
#endif
}

Thanks, anxious here for 1.39 =)

And I hope that TRect and TPoint are the only problematic structures.

By the way, please add a Qt 4.2 version to 1.39

This will be the default Qt version that Lazarus supports.