[Qt-interest] QWidget: Must construct a QApplication before a QPaintDevice
Stephen Jackson
spjackson42 at gmail.com
Tue Sep 1 10:34:04 CEST 2009
On Tue, Sep 1, 2009 at 8:40 AM, Andre Somers wrote:
>
> So, I am seeing this issue at a moment that I am sure a QApplication has
> already been constructred.
>
> First of all, good point Brad, I forgot to mention my platform. I am
> working on Windows XP using MinGW32.
> What I mean by debug and release, is simply setting the these flags in
> QtCreator. I am not manually adjusting any optimization flags. The point was
> the specific message that is printed to my console: "QWidget: Must construct
> a QApplication before a QPaintDevice". I really don't get how that can
> occur, as a QApplication //has// been constructed, and I verified that by
> printing a message with QApplication::applicationDirPath() (using my app
> variable) and the sessionId to the console using qDebug(). This message
> appears neatly in the output where I would expect it: right at the top of my
> output.
>
> I would really appreciate any more pointers, especially on how I can debug a
> case like this that only appears in release mode. I now feel like I am
> stumbeling around in the dark...
>
The Qt source reveals that you get this message if you construct a
QWidget and QCoreApplication::self is a null pointer.
The Qt source sets this to null
a) On initialisation
b) When a QCoreApplication object is destroyed (perhaps via the
destruction of a QApplication object)
Are you creating a secondary (core) application object? There is a
Q_ASSERT_X to guard against this but I haven't checked whether this
behaves differently between release and debug.
If you are definitely not doing that, then something must be
overwriting this global pointer - you can get different layout of
global variables between debug and release. Check for memsets etc. Add
some debugging statements that show the value of qApp at various
points.
--
HTH,
Stephen Jackson
More information about the Qt-interest-old
mailing list