Hello, Items specific to the Qt widget set

I have a problem with adding new fields into TQtWidget class. I dont know why. Maybe some dependency somewhere on TQtWidget memory layout?

If I add 2 fields (tryed with 2 Boolean fields into public section) for example

  public
    AVariant: QVariantH;
    Widget: QWidgetH;
    LCLObject: TWinControl;
    HasCaret: Boolean; <--- this
    InPaint: Boolean; <--- and this

then I have problems with starting qt ide (AV in TQtMenu destructor). If I am tring to debug ide with gdb then I have no AV. Without adding that 2 fields I have no AV also. Even adding one fields cause AV.

So please, if you know about some dependency on TQtWidget layout in memory then let me know. Ofcource this can be memory corruptions caused by other code. If you know how to catch mem leaks and corruptions under lazarus-qt please let me know too.

Best regards,
Paul Ishenin.

I've installed FC7 this afternoon and lazarus svn rpm from 20070711 + fpc rpms 20070711, and there are still problems:
1.Modal windows are not modal.(it worked ok)
2.TStatusBar is not visible (it worked ok until last few days). 3.Mem leaks and AV's eg. in TQtWSCustomStaticText->GetText() I have to insert if csDestroyingHandle in AWinControl.ControlState then exit; before call to QLabel_text().
(there wasn't any leaks few days ago).

4.This is for Den:
I cannot work without my bindings patch (QWidgetHack) , even on FC7. When I click X button it closes the window, doesn't matter about assigned OnCloseQuery(). Your test binary works ok, but same source compiled on my shiny new FC7 not. ?!?

This problems are really strange and shows that something is definitelly broken, but don't know where , could be fpc , LCL, Qt-4.3 or maybe bindings.

pm zeljko wrote

This problems are really strange and shows that something is definitelly broken, but don't know where , could be fpc , LCL, Qt-4.3 or maybe bindings.

I always use fpc 2.0.5

[jan at den fpc20X]$ svn info
URL: http://svn.freepascal.org/svn/fpc/branches/fixes_2_0 Revision: 8017

Den Jean wrote

I always use fpc 2.0.5

You think that it could be because of fpc ? I would like it ;) what are the rpm packages on Lazarus site (Daily snapshots) ? is it same fpc-2.0.4 , just packaged with different date or what ? I'll install some older rpms of fpc tomorrow and see what's up.

tnx.

pm zeljko wrote

;)what are the rpm packages on Lazarus site (Daily snapshots) ?

FPC:
===
please use
svn co http://svn.freepascal.org/svn/fpc/branches/fixes_2_0 fpc20X and compile this one with downloaded fpc 2.0.4*.rpm

make PREFIX=/usr clean all
make PREFIX=/usr install

Qt:
==
I configure Qt with :
./configure -prefix /usr -opengl -xrender -xcursor -xrandr verofy output so that there are not too many (important) no's with the features
install the necessary devel packages to enable features

time gmake -j2

lazarus:
make PREFIX=/usr clean all LCL_PLATFORM=gtk2

????? ?????? wrote

then I have problems with starting qt ide (AV in TQtMenu destructor). If I am tring to debug ide with gdb then I have no AV. Without adding that 2 fields I have no AV also. Even adding one fields cause AV.

On the first days of the Qt widgetset I had this kind of problem and my solution was just to leave the destructors empty .... of course this is no solution, but I had no idea what caused this.

So please, if you know about some dependency on TQtWidget layout in memory then let me know.

There should be none. I don't even image how this could be possible with our qt interface code.

Ofcource this can be memory corruptions caused by other code.

That's more plausible, unfortunately I can't help much about how to detect this.

pm zeljko wrote

? I cannot work without my bindings patch (QWidgetHack) , even on FC7. ? When I click X button it closes the window, doesn't matter about assigned ? OnCloseQuery(). Your test binary works ok, but same source compiled on my shiny new FC7 not. ?!?

We should find problems and not circumvent it. Reading the posts I see problems in LCL. But I also suspect problems in binding. I just discovered on older distro, that Mainwindow demo (FontDialog) does not work with Qt 4.3.0,
but it does work with Qt 4.2.3.

Even if I compile the binding code of 4.2.3 against 4.3.0, it still doesn't work with the same c++ code.

I checked the pascal resulting code (compile w/o removing assemblers, both are the same,but with Qt 4.3.0 the FontDialog causes AV on Mandriva 2006). On Mandriva 2007.1 everything is fine.

I searched alot but still did not find anything. If you have problems, revert to Qt 4.2.3 (Felipe will like this :-), ahum smells like circum...) I uploaded latest stuff for both Qts. (Added QtPpoint function for demo)

Felipe can you check Darwin and Points, it really should not be wrong anymore. The demo code of mainwindow was wrong. The poly was array of TPoint instead of TQtPoint. Please check again.

regards,

Den Jean

Den Jean wrote

Felipe can you check Darwin and Points, it really should not be wrong anymore. The demo code of mainwindow was wrong. The poly was array of TPoint instead of TQtPoint. Please check again.

I am investigating. All I can say for now is that Mouse.CursorPos is completely wrong ... I need to check only if it's not a problem on the lcl-qt interface

Felipe Monteiro de Carvalho wrote

I am investigating. All I can say for now is that Mouse.CursorPos is completely wrong ... I need to check only if it's not a problem on the lcl-qt interface

Yes .... LCL was wrong, it was passing a Types.TPoint instead of a TQtPoint to the function

I am correcting

Felipe Monteiro de Carvalho wrote

I am correcting

commited. Nice, the magnifier runs well with Qt on my Mac =) The only problem is that painting performance is horrible.

I would like to use Carbon, but it doesn't yet have support for screenshot taking, and implementing it isn't that easy

Quoting Den Jean :

Qt is so clear lib, so there's no reason to suspect Qt-4.3 for such things, but you're right it could be problem - at least until 4.3.1 ;) Most problems (which I don't understand really) comes from LCL, with same code, heaptrc says that I have mem leaks (at home), but not at my devel isn't visible on any of those machines (XOrg-6.8.2), but on my laptop (XOrg-7.0), but it's also not visible in clean install of FC7 (XOrg-7.2) (inside vmware) ?!?

I'm just wondering why your demo binary works as expected on my machines , but after
recompiling your source I get totally different results.

Quoting Felipe Monteiro de Carvalho :

may I ask why ?

> commited. Nice, the magnifier runs well with Qt on my Mac =) The only > problem is that painting performance is horrible. may I ask why ?

The glass follows the mouse movement. With Windows and Gtk interfaces this movement is instantaneous. On Qt it takes some time to occor, enougth so one can see it is slow.

I don' t know the depth reason, which is probably something in the lcl-qt code.

thanks,

Seem that's the same problem with caret & synedit (under linux), mouse movements makes problems. If I don't move mouse caret looks and blinks ok, but after mouse move timer becomes mad, there's no more consistent clocking, it fires 3-4 times in a second, or no clocking for 5-6 seconds.

zeljko wrote

Seem that's the same problem with caret & synedit (under linux), mouse movements makes problems. If I don't move mouse caret looks and blinks ok, but after mouse move timer becomes mad, there's no more consistent clocking, it fires 3-4 times in a second, or no clocking for 5-6 seconds.

I don't know if this is related. The problem on the magnifier is a performance problem, that also happens if I use the keyboard to move the glass.

The timer problem is something else. I have no idea where this problem is. I already checked the Qt-lcl code and it's so simple I can't image where we made something wrong. Could be either a problem on the bindings or on Qt itself.

I've already written some apps with Qt (C++) and there's no such problems, so definitelly qt is not a problem, but our implementation could be. Maybe we should rethink gcc switches while compiling bindings (as first step), and then search for bottleneck.

Felipe Monteiro de Carvalho wrote

The timer problem is something else. I have no idea where this problem is. I already checked the Qt-lcl code and it's so simple I can't image where we made something wrong. Could be either a problem on the bindings or on Qt itself.

I've reimplemented QtTimer (per Qt documentation old implementation was wrong), now it clocks ok under SynEdit, so you can test it.

pm zeljko wrote

? When I click X button it closes the window, doesn't matter about assigned ? OnCloseQuery(). Your test binary works ok, but same source compiled on m

My patch is not even applied. Just try again.
Note that both the eventfilter of TQtMainWidget an TQtWidget must be changed, to cover both cases.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: r11506_CloseQuery.diff
Type: text/x-diff
Size: 1889 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/qt/attachments/20070714/58b5bfc4/attachment.bin>

Applied, but I didn't see your patch anywhere before ... sorry.

Note that both the eventfilter of TQtMainWidget an TQtWidget must be changed, to cover both cases.

yep, it fixes problems :)

zeljko

pm Felipe Monteiro de Carvalho wrote

Yes .... LCL was wrong, it was passing a Types.TPoint instead of a TQtPoint to the function

in qtwinapi.inc, the implementation of polygon and alike are wrong for Mac:

function TQtWidgetSet.Polygon(DC: HDC; Points: PPoint; NumPts: Integer;

  Winding: Boolean): boolean;

....
QPainter_drawPolygon(TQtDeviceContext(DC).Widget, PQtPoint(Points), NumPts, QtWindingFill)

the typecast is a problem ...

Quoting Den Jean :

oops, I don't know how it should look like (don't have an Mac yet). Do you know what need to be done / what is the proper way to get it work on Mac instead of such typecast ?

zeljko

Quoting Den Jean :

ah, now I see TQtPoint is reversed for mac ....