View Full Version : Static functions and class members

22nd December 2006, 10:25
I am currently having a problem in using a third party SDK. It involves some Qt, but since it's primarly C++ related I post it here.

The SDK consists of a range of classes, all derived from the same base class. There is a static callback function in this base class, which is used for error handling. Normally this callback is just set by the user once in the beginning, typically by allowing for some dialog to be displayed when errors occur.

I would like to use a QErrorMessage object inside my callback function, but there is a problem there. I have a QMainWindow based class, where I construct the QErrorMessage in the QMainWindow constructor. I noticed QErrorMessage can not be created on the stack, otherwise the dialog disappears immediately. So I have to do it this way.

Now, if I don't make the QMainWindow class the parent of QErrorMessage, I get weird behaviour. In the other scenario, I have a whole lot of problems. The QErrorMessage object is a member of my QMainWindow class and is not-static. Therefore, it can not be used in my static callback function. If I make the QErrorMessage static, it can not have the QMainWindow object as a parent. And trying to work around this just has me going round and round and ...

Basically, I'm just looking for a work-around to give static functions (a static error handling function inside my QMainWindow object) access to members of the class. I know it can not be done normally, therefor the work-around question :D

22nd December 2006, 10:27
Let's start from the beginning - what "weird behaviour" do you get when not having the window as the parent?

22nd December 2006, 10:31
There is a problem when multiple errors occur in a row. Normally they should be queued. If I do not make the QMainWindow a parent, only the first error is shown and the others are just dismissed. This has nothing to do with the checkbox for ignoring the same errors in the future, it is just a difference in behaviour regarding the parent selection. I have to admit this does not make that much sense to me.

22nd December 2006, 10:37
Do you use threads?

22nd December 2006, 10:48
No, I don't use threads. I tried it as a work-around, but got stuck there too. Also seemed to be too complicated for what I need.

Here is some code to illustrate things :

.h file :


#include <QtGui/QMainWindow>
#include "OctoObject.h"

class QErrorMessage;
class OctoNormalise;

class MainWindow : public QMainWindow

MainWindow(QWidget *parent = 0, Qt::WFlags flags = 0);

OctoNormalise* normalise;

//All static objects to allow for the use of the static callback function
static QErrorMessage* errorMessage;
static void _stdcall errorHandler(OctoObject::error_code error);


#endif // MAINWINDOW_H

.cpp file :

#include "QTGUI"
#include "mainwindow.h"
#include "OctoNormalise.h"

QErrorMessage* MainWindow::errorMessage = 0;

MainWindow::MainWindow(QWidget *parent, Qt::WFlags flags)
: QMainWindow(parent, flags)
//Create the QErrorMessage Object
errorMessage = new QErrorMessage;

//Set the error handler

//Create an object from the SDK as a test (this force the generation of several errors the way it is done now)
normalise = new OctoNormalise;


void __stdcall MainWindow::errorHandler(OctoObject::error_code error)
//Select the dialog text based on the error coming from the SDK

switch (error)
case OctoObject::HaspErr : errorMessage->showMessage(QString("No valid HASP key available")); break;
case OctoObject::FileOpenErr : errorMessage->showMessage(QString("File could not be found/opened")); break;
// ...

//Delete all used objects
delete normalise;
delete errorMessage;

//Resets the error handler to a dummy function (not actually NULL, this is implemented in the SDK to be handled safely)


22nd December 2006, 11:00
Hmm, I noticed there are strange things going on with the callback pointer, it seems to change. Maybe this is not entirely Qt related, I am going to contact the supplier.

Off course, this does not change the fact it is a pity the static function can not access members of the class. Any suggestions there remain interesting :).