The same code works under Windows and fails under GNU/Linux
-
At least if you need some qobject_cast<> later on. And in principle it is a good idea to put the macro in every QObject derived class. Even if you do not need the functionality, it does not harm. And you need not worry about it if you change minds afterwards.
-
I thought as much.
Not really needed for this, but a good habit to do for every QObject decendant class. -
Good discussion, coming back to main question here.
which code is getting executed here on Linux could u check that thru debug statement or some other way?
I mean is it
@ MyApp app(argc,argv);
return app.exec(); // event loop
@OR
@
if (argc == 3) run(argv[1],argv[2]);
@And how it is different from Windows execution?
Problem seems simple here i guess, its just you have to check the difference between win and Linux in terms of main() code execution, max u might have to go 1 layer down but that should resolve ur problem.
-
Show us the implementation of your MyApp constructor, please.
-
[quote author="vishwajeet" date="1298555161"]
Problem seems simple here i guess, its just you have to check the difference between win and Linux in terms of main() code execution, max u might have to go 1 layer down but that should resolve ur problem. [/quote][Highlighting by me]
Can you please use correct english in your writings. It's hard to read these non obvious abbreviations, especially for non-native speakers. This is neither Twitter nor SMS, we do have far more than 140 available :-) so no need to confuse people.
-
Now the MyApp class has the below declaration :
@class MyApp : public QApplication
{
private:Q_OBJECT
public:
bool tested;
QString program;
streambuf *coutbuf;
virtual ~MyApp();
MyApp(int &,char **);
};@And below is its definition :
@MyApp::MyApp(int &argc,char **argv) : QApplication(argc,argv),program(argv[0]),coutbuf(cout.rdbuf()),tested(false){
MainWindow *mainWindow = new MainWindow(argc,argv);
mainWindow->show();
}@
I recompiled all but I still get the same issue.
-
It's common to instantiate your UI class in the main function after the QApplication (-derived) object has been created.
I have not tested if that is the cause of your problem, but at least it's common coding style in Qt world.
-
Ohhhh i apologies for too many abbreviations in my writing.
[quote author="Volker" date="1298556541"][quote author="vishwajeet" date="1298555161"]
Problem seems simple here i guess, its just you have to check the difference between win and Linux in terms of main() code execution, max u might have to go 1 layer down but that should resolve ur problem. [/quote][Highlighting by me]
Can you please use correct english in your writings. It's hard to read these non obvious abbreviations, especially for non-native speakers. This is neither Twitter nor SMS, we do have far more than 140 available :-) so no need to confuse people.
[/quote]To jerome.bouat
Could you please check if @MyApp app(argc,argv);
return app.exec(); // event loop@ is getting executed in case of windows and Linux ? -
The below code fragment is being executed
on Windows (because the application works properly)
and Linux (because I don't get the error if I comment it) :
@MyApp app(argc,argv);
return app.exec(); // event loop@I moved the GUI initialization in a separate method (createWindow) :
@class MyApp : public QApplication{
private:
Q_OBJECT
public:
bool tested;
QString program;
streambuf *coutbuf;
virtual ~MyApp();
// empty, just call super class constructor
// and initialize object attributesMyApp(int &,char **);
void createWindow(int &,char **);
};@
Into this new method, I don't get the error message
if I comment the "show()" call
@void MyApp::createWindow(int &argc,char **argv){
MainWindow *mainWindow = new MainWindow(argc,argv);
mainWindow->show(); // no error if commented
}@
Thus, the issue seems to be located into the super-super class method QWidget::show().
-
No way to analyze this here. Can you please:
- make a small test case
- put it into a complete project
- make sure it compiles, runs and shows the error
- put the sources (and only these) into a ZIP
- put the ZIP on dropbox, pastebin or make it available somewhere else
- post the link here
-
It seems to be an OpenGL issue but the error message I reported is far from that.
I'm investigating.
-
Just a Qt newbie question : I assume that all calls like below should be located into header files only and not cpp files :
@QObject::connect(scrollBar, SIGNAL(valueChanged(int)), label, SLOT(setNum(int)));@
?Or could we possibly use this call into cpp files by including the right Qt file ?
-
It's an ordinary call of a static method. You put it into regular method bodies. That happens mostly in the .cpp files, but can be put into headers too.
-
What's more, in most cases the right file is already included when you call this: the header of either of the objects you want to connect. If you find that you can not use the connect call: it is to be found in the QObject header.
-
I assume the "emit" keyword can be used in cpp files ?
-
Perhaps you should work through one of the basic Qt tutorials. This is all explained very well in the documentation, there is even a section called "Signals & Slots" that explains in detail how this all works.