Qt-interest Archive, July 2006
from 4.0.1 to 4.1.4
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Some month ago I released a Qt application using QT 4.0.1. Last week I
installed QT 4.1.4. Today I rebuild my old application and it is very
unstable. Any idea?
Thank you. Christian
--
[ signature omitted ]
Message 2 in thread
On 7/5/06, Christian Malagoli <christian.malagoli@xxxxxxxxxxxx> wrote:
> Some month ago I released a Qt application using QT 4.0.1. Last week I
> installed QT 4.1.4. Today I rebuild my old application and it is very
> unstable. Any idea?
You must have an idea where the application is unstable? Any
compilation or runtime warnings?
--
[ signature omitted ]
Message 3 in thread
Christian Malagoli wrote:
> Some month ago I released a Qt application using QT 4.0.1. Last week I
> installed QT 4.1.4. Today I rebuild my old application and it is very
> unstable. Any idea?
In general, you may experience behavioral difference in minor releases
of Qt (4.0 -> 4.1). From 4.0 to 4.1, you may be seeing more than one
such change. If you are seeing crashes in your new code, and post the
details, we can perhaps help you find what is wrong.
Andreas
--
[ signature omitted ]
Message 4 in thread
I have also left off porting my app from 4.0.1 to 4.1.4 because my GUI
application looks and behaves completely different when built under
4.1.x (see details below). One difference I found was here:
http://doc.trolltech.com/4.1/qwidget.html#autoFillBackground-prop
This property was introduced in 4.1, and when using widgets (or
dialogs), it seems like I have to call :
setAutoFillBackground ( true )
in all widget classes. Since I have over hundred widget classes, this
can be a pain.
Does anyone know a workaround for this? If I don't call this function,
all my widgets (which were working fine before on 4.0.1), become
transparent (or atleast the background part of it) when built under
4.1.x. Is there a way that I can call this function for the entire
application and have all my widgets inherit this property?
Manish
Andreas Aardal Hanssen wrote:
> Christian Malagoli wrote:
>
>> Some month ago I released a Qt application using QT 4.0.1. Last week I
>> installed QT 4.1.4. Today I rebuild my old application and it is very
>> unstable. Any idea?
>>
>
> In general, you may experience behavioral difference in minor releases
> of Qt (4.0 -> 4.1). From 4.0 to 4.1, you may be seeing more than one
> such change. If you are seeing crashes in your new code, and post the
> details, we can perhaps help you find what is wrong.
>
> Andreas
>
>
Message 5 in thread
On 7/5/06, Manish Motwani <mmotwani@xxxxxxxxxxxxxx> wrote:
> http://doc.trolltech.com/4.1/qwidget.html#autoFillBackground-prop
>
> This property was introduced in 4.1, and when using widgets (or dialogs),
> it seems like I have to call :
> setAutoFillBackground ( true )
> in all widget classes. Since I have over hundred widget classes, this can
> be a pain.
That is a one time change, and it's for the better of your application :)
--
[ signature omitted ]
Message 6 in thread
I also see some difference in dialog layout, but moreover when the app close
some of the dialogs it crash.
The destructor for the dialogs return the follow error: Unhandled exceptio
at xxx Access violation reading location yyy
Christian
-----------------------------------------------
"Manish Motwani" <mmotwani@xxxxxxxxxxxxxx> ha scritto nel messaggio
news:44AB88F8.1050208@xxxxxxxxxxxxxxxxx
I have also left off porting my app from 4.0.1 to 4.1.4 because my GUI
application looks and behaves completely different when built under 4.1.x
(see details below). One difference I found was here:
http://doc.trolltech.com/4.1/qwidget.html#autoFillBackground-prop
This property was introduced in 4.1, and when using widgets (or dialogs), it
seems like I have to call :
setAutoFillBackground ( true )
in all widget classes. Since I have over hundred widget classes, this can be
a pain.
Does anyone know a workaround for this? If I don't call this function, all
my widgets (which were working fine before on 4.0.1), become transparent (or
atleast the background part of it) when built under 4.1.x. Is there a way
that I can call this function for the entire application and have all my
widgets inherit this property?
Manish
Andreas Aardal Hanssen wrote:
Christian Malagoli wrote:
Some month ago I released a Qt application using QT 4.0.1. Last week I
installed QT 4.1.4. Today I rebuild my old application and it is very
unstable. Any idea?
In general, you may experience behavioral difference in minor releases
of Qt (4.0 -> 4.1). From 4.0 to 4.1, you may be seeing more than one
such change. If you are seeing crashes in your new code, and post the
details, we can perhaps help you find what is wrong.
Andreas
--
[ signature omitted ]
Message 7 in thread
Manish Motwani wrote:
> Does anyone know a workaround for this? If I don't call this function,
> all my widgets (which were working fine before on 4.0.1), become
> transparent (or atleast the background part of it) when built under
> 4.1.x. Is there a way that I can call this function for the entire
> application and have all my widgets inherit this property?
If you want to, you can climb the tree of widgets using
QObject::findChildren() and QObject::isWidgetType() for all your windows
and set this property true. Otherwise, you can paint the widgets'
backgrounds from inside paintEvent() where necessary. This
behavioral change in 4.1 affects widgets that rely on their
background being painted opaque by default.
Andreas
--
[ signature omitted ]
Message 8 in thread
> If you want to, you can climb the tree of widgets using
> QObject::findChildren() and QObject::isWidgetType() for all your windows
> and set this property true. Otherwise, you can paint the widgets'
> backgrounds from inside paintEvent() where necessary. This
> behavioral change in 4.1 affects widgets that rely on their
> background being painted opaque by default.
>
> Andreas
>
>
Thanks! This should help.
Also, is there a way I can check the version of Qt being used and only
call this piece of code if the version is > 4.1? I would like my code to
compile in 4.0 as well, because it may turn out to be an open source
application.
Manish
--
[ signature omitted ]
Message 9 in thread
> Also, is there a way I can check the version of Qt being used and only
> call this piece of code if the version is > 4.1? I would like my code to
> compile in 4.0 as well, because it may turn out to be an open source
> application.
No one use Qt 4.0 Today.
As you see in this website : http://www.blogistan.co.uk/qt , most popular
Linux distros uses Qt 4.1.x
--
[ signature omitted ]
Message 10 in thread
> No one use Qt 4.0 Today.
>
> As you see in this website : http://www.blogistan.co.uk/qt , most popular
> Linux distros uses Qt 4.1.x
>
Thanks but this doesn't answer my question.
Manish
--
[ signature omitted ]
Message 11 in thread
On 05.07.06 13:02:01, Manish Motwani wrote:
>
> >No one use Qt 4.0 Today.
> >
> >As you see in this website : http://www.blogistan.co.uk/qt , most popular
> >Linux distros uses Qt 4.1.x
> Thanks but this doesn't answer my question.
qVersion(), it took me 2 seconds thinking (how could Qt provide a
version number?) and 5 seconds looking up a global function which
contains "version" in it... ;-)
Andreas
--
[ signature omitted ]
Message 12 in thread
I think I'm aware of qVersion() but I need some #ifdef kind of thing for
compile time (if possible at all), because the function
setAutoFillBackground () will just not compile under 4.0.
I guess its not very important, but is there a way?
:)
-Manish
Andreas Pakulat wrote:
> On 05.07.06 13:02:01, Manish Motwani wrote:
>
>>> No one use Qt 4.0 Today.
>>>
>>> As you see in this website : http://www.blogistan.co.uk/qt , most popular
>>> Linux distros uses Qt 4.1.x
>>>
>> Thanks but this doesn't answer my question.
>>
>
> qVersion(), it took me 2 seconds thinking (how could Qt provide a
> version number?) and 5 seconds looking up a global function which
> contains "version" in it... ;-)
>
> Andreas
>
>
Message 13 in thread
> I think I'm aware of qVersion() but I need some #ifdef kind of thing for
> compile time (if possible at all), because the function setAutoFillBackground
> () will just not compile under 4.0.
> I guess its not very important, but is there a way?
Going to http://doc.trolltech.com/ and searching for QT_VERSION, turns up
things like
http://doc.trolltech.com/4.1/qtglobal.html#QT_VERSION
and
http://doc.trolltech.com/3.2/qapplication.html#qVersion
(Note: read this last one carefully...it's more than just qVersion().)
This surprised me, too, because I expected the version macro to be named
QT_UNICORN_DROPPINGS, but it wasn't. Funny, that.
Nathan
--
[ signature omitted ]
Message 14 in thread
Gee, maybe I should have read more carefully. Well, thanks!
Manish
Nathan Carter wrote:
>> I think I'm aware of qVersion() but I need some #ifdef kind of thing for
>> compile time (if possible at all), because the function setAutoFillBackground
>> () will just not compile under 4.0.
>> I guess its not very important, but is there a way?
>>
>
> Going to http://doc.trolltech.com/ and searching for QT_VERSION, turns up
> things like
>
> http://doc.trolltech.com/4.1/qtglobal.html#QT_VERSION
> and
> http://doc.trolltech.com/3.2/qapplication.html#qVersion
>
> (Note: read this last one carefully...it's more than just qVersion().)
>
> This surprised me, too, because I expected the version macro to be named
> QT_UNICORN_DROPPINGS, but it wasn't. Funny, that.
>
> Nathan
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 15 in thread
On 05.07.06 13:41:47, Manish Motwani wrote:
> I think I'm aware of qVersion() but I need some #ifdef kind of thing for
> compile time (if possible at all), because the function setAutoFillBackground
> () will just not compile under 4.0.
> I guess its not very important, but is there a way?
Is it really that hard to do a
cd <qtdir>/include/Qt
grep "#define" qglobal.h | grep -i version
? I mean, after all qglobal.h is kind of a central place in Qt, so it's
most likely that what you look for is in there. And it is.
Andreas
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
