The show() method...

[salmanmanekia]

Hi,
I have written a program in which i have implemented Graphics View Framework..the output is there and it s perfect ,but the problem is that i have written the command of show() in my class constructor while in the main where i have instantiate the object of that class ,the

show() shows an empty screen...

but i think its the common and good practice to put show() command in the main

In Conctsructor It work fine

TrainingUI::TrainingUI(QGraphicsView *parent):QGraphicsView(parent)
{
  ..
view.setScene(scene);
view.show(); // WORKS FINE HERE
..
}

TrainingUI::TrainingUI(QGraphicsView *parent):QGraphicsView(parent)
{
  ..
view.setScene(scene);
view.show(); // WORKS FINE HERE
..
}

To copy to clipboard, switch view to plain text mode 

But in Main it shows an empty screen

#include "trainingui.h"
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    TrainingUI w;
    w.show(); // EMPTY SCREEN
    return a.exec();
 
}

#include "trainingui.h"
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    TrainingUI w;
    w.show(); // EMPTY SCREEN
    return a.exec();

}

To copy to clipboard, switch view to plain text mode 

[jpn]

TrainingUI is already a QGraphicsView. So why do you have another graphics view as a member? Allocating widgets on the stack (the member variable) is not a very good idea in the first place anyway.

[salmanmanekia]

so you recomend that

1, i should make TrainingUI as QWidget ..?,something like

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)
{}

and to be honest with you i am not crystal clear with this base-derived thing in QT,so i thought that if i am developing a GraphicsView class then the base should be GraphicsView

also do you recommend

2, QGraphicsView *view = new QGraphicsView;
v->show();

but with respect to my problem i tried these things and it doesnt make any difference..also can you tell me what difference does it make if i allocate a widget on stack or heap ?
Thanks..

[jpn]

so you recomend that

1, i should make TrainingUI as QWidget ..?,something like

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)
{}

TraniningUI IS ALREADY a QWidget, namely QGraphicsView. And yes, QWidget is a more sensible parent parameter than QGraphicsView.

and to be honest with you i am not crystal clear with this base-derived thing in QT,so i thought that if i am developing a GraphicsView class then the base should be GraphicsView

It is not a Qt thing but C++/OOP thing. You should consult your favourite C++ and OOP books to learn inheritance.

also do you recommend

2, QGraphicsView *view = new QGraphicsView;
v->show();

but with respect to my problem i tried these things and it doesnt make any difference..

No, as I said, TrainingUI is already a QGraphicsView, you don't need another one.

also can you tell me what difference does it make if i allocate a widget on stack or heap ?

Every QObject deletes their children upon destruction. If you add the graphics view to a window, the window will delete it once the window itself is deleted. Now if the graphics view is allocated on the stack as a member variable, you'll get a crash due to double free attempt: 1) deleted by parent 2) goes out of scope according to normal C++ rules. This issue has been discussed tons of times, please search the forum for more details.

[salmanmanekia]

TraniningUI IS ALREADY a QWidget, namely QGraphicsView. And yes, QWidget is a more sensible parent parameter than QGraphicsView.

what do you mean by sensible and can you please elobrate on this statement ?,because this statement is rather confusing that it is a QWidget namely QGraphicsView.

It is not a Qt thing but C++/OOP thing. You should consult your favourite C++ and OOP books to learn inheritance.

, I know from OOP that void func():a(1),means that memeber variable 'a' would have a value 1..but i cannot absorb the understanding for

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)

and why it is so neccesary

No, as I said, TrainingUI is already a QGraphicsView, you don't need another one.

what i understand from this is that that a QGraphicsView member variable is useless since TrainingUI is already QGraphicsView...now question is that
If i would not declare the QGraphicsView as member variable then how should i be able to view the scene

Every QObject deletes their children upon destruction. If you add the graphics view to a window, the window will delete it once the window itself is deleted. Now if the graphics view is allocated on the stack as a member variable, you'll get a crash due to double free attempt: 1) deleted by parent 2) goes out of scope according to normal C++ rules.

what i conclude from this statement is that that every QObject child should be declared on heap so it is not been tried to delete twice ...am i right ?? an i hoped that QGraphicsView would be inherited from QObject but i cannot find it in this list
http://doc.trolltech.com/4.4/qobject.html

[jpn]

what do you mean by sensible and can you please elobrate on this statement ?,because this statement is rather confusing that it is a QWidget namely QGraphicsView.

A parent widget is not the one you inherit from. C++ inheritance and Qt's parent-child relationship are different concepts. Make sure you understand the difference. Here's an article about the subject. A short quote from the article:

Parent Objects versus Base Classes

Parent objects should not be confused with base classes. The parent-child relationship is meant to describe containment, or management, of objects at runtime. The base-derived relationship is a static relationship between classes determined at compile-time.

It is possible that a parent can also be an instance of a base class of some of its child objects. These two kinds of relationships are distinct and must not be confused, especially considering that many of our classes will be derived directly or indirectly from QObject.

, I know from OOP that void func():a(1),means that memeber variable 'a' would have a value 1..but i cannot absorb the understanding for and why it is so neccesary

I'm sorry I'm afraid I cannot understand what you mean with something being necessary.

what i understand from this is that that a QGraphicsView member variable is useless since TrainingUI is already QGraphicsView...now question is that
If i would not declare the QGraphicsView as member variable then how should i be able to view the scene

TrainingUI is a QGraphicsView so instead of creating a new graphics view you can just call any graphics view method of this, like "setScene(scene)" instead of "view.setScene(scene)" like you had before.

what i conclude from this statement is that that every QObject child should be declared on heap so it is not been tried to delete twice ...am i right ??

Well actually it's not that simple. It depends on the context. It is perfectly valid to allocate a QObject without a parent on the stack. There is no general rule for this, you just have to understand the concept.

an i hoped that QGraphicsView would be inherited from QObject but i cannot find it in this list
http://doc.trolltech.com/4.4/qobject.html

QGraphicsView is not a direct subclass of QObject. The inheritance chain looks something like this:

QObject <- QWidget <- QFrame <- QAbstractScrollArea <- QGraphicsView

QObject <- QWidget <- QFrame <- QAbstractScrollArea <- QGraphicsView

To copy to clipboard, switch view to plain text mode 

[salmanmanekia]

I'm sorry I'm afraid I cannot understand what you mean with something being necessary.

I am talking about the constructor declaration in this way that why it is so neccesary to consider (QWIdget *parent):QGraphicsView(parent) in the below given code

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)

To copy to clipboard, switch view to plain text mode 

beacuse as you know from OOP i know

I know from OOP that void func():a(1),means that memeber variable 'a' would have a value 1

Well actually it's not that simple. It depends on the context. It is perfectly valid to allocate a QObject without a parent on the stack. There is no general rule for this, you just have to understand the concept.

so are you saying that since QObject is always the parent so it should be declared on stack so that it is being handled by compiler itself..any other article link or a brief description from you would be helpful,since

it is not that simple

The view thing is clear, thanks for that and the QObject heirarchy..
one last thing .as i mentioned in my first post that

i think its the common and good practice to put show() command in the main

..
so am i right with this concept..Thanks AGAIN ..!!

[jpn]

I am talking about the constructor declaration in this way that why it is so neccesary to consider (QWIdget *parent):QGraphicsView(parent) in the below given code

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)

TrainingUI::TrainingUI(QWIdget *parent):QGraphicsView(parent)

To copy to clipboard, switch view to plain text mode 

beacuse as you know from OOP i know

I know from OOP that void func():a(1),means that memeber variable 'a' would have a value 1

I wouldn't call that OOP but just particular C++ syntax. Anyway, I'm not here to teach you everything starting from the basics. You should at least read the following documentation: Object Trees and Object Ownership. After reading that you should have an idea what is a parent.

so are you saying that since QObject is always the parent so it should be declared on stack so that it is being handled by compiler itself..any other article link or a brief description from you would be helpful,since

And what was wrong with the first article? Did you actually bother to read it carefully with thought?

The view thing is clear, thanks for that and the QObject heirarchy..
one last thing .as i mentioned in my first post that

i think its the common and good practice to put show() command in the main

..
so am i right with this concept..Thanks AGAIN ..!!

But did you realize what was the difference? You were calling show() and two DIFFERENT graphics view objects.

PS. Next time please read the documentation links and articles people give to you. You are not giving a very good picture of yourself if you keep asking questions that are clearly explained behind the links that were already pointed out to you.

[salmanmanekia]

You are not giving a very good picture of yourself

..is this any better..
any way thanks for the advice ..!!..