No widget is shown, strangely

tomy

Other question, for the example, is in the test_1.cpp:

void test_1::updateStatus() {
    int completedCount = 0;
    
    for(auto t: mTasks)
        if(t->isCompleted())
            completedCount++;

    int todoCount = mTasks.size() - completedCount;
    statusLabel->setText(QString("Statuse: %1 todo / %2 completed")
                         .arg(todoCount)
                         .arg(completedCount));
}

t is of the class test_1 but how could it have called a method, bool isCompleted() const;, from another class, task?

jsulm

@tomy said in No widget is shown, strangely:

I think QMainWindow is not acting as a widget, the way I'm familiar with widgets; it mostly works as an application window, in that sense that we, for instance, can put a widget, like a QPushButon, onto a QFormLayout or another widget without coming another widget to the scene, but this for QMainWindow differs.

That's because QMainWindow has a widgets called Central Widget in its central part.

"The question is, where is the list of those special widgets (or better to say, containers —apart from QVector and so on)?" - in the documentation: https://doc.qt.io/qt-5/containers.html Also, containers do not have anything to do with widgets.

jsulm

@tomy said in No widget is shown, strangely:

t is of the class test_1 but how could it have called a method, bool isCompleted() const;, from another class, task?

Like any other method of a class? If updateStatus() is not static you need an instance of test_1 to call any public method on it...

tomy

@jsulm

Like any other method of a class? If updateStatus() is not static you need an instance of test_1 to call any public method on it...

Both t (mTask vector) and updatestatus() are of the same class test_1, whilest iscompleted() is a method of the class task (the whole example is above, in the first post and it works right!)

That QVector<Task*> mTasks; private data member can at the upmost level call other private/public data members/methods of the same class not another class just because that new class is also added to the project. I mean there should be a way to call them, if my recollection is accurate. Will "include task.h" work it out!?

jsulm

@tomy said in No widget is shown, strangely:

data members/methods of the same class not another class just because that new class is also added to the project. I mean there should be a way to call them

I don't understand the problem: you can call methods of other classes in a class as long as you have instances of that class:

void ClassA::someMethod()
{
    ClassB classB;
    classB.someMethodInClassB();
}

So, what is the problem?

tomy

@jsulm

That's because QMainWindow has a widgets called Central Widget in its central part.

So worse! It mustn't need another QWidget to be instantiated like in the posts #2, #3. And we should've been able to put the controls directly on it. But it sounds that, it's not a real central widget, but a place/room, that "must" be filled by another widget! :(

"The question is, where is the list of those special widgets (or better to say, containers —apart from QVector and so on)?" - in the documentation: https://doc.qt.io/qt-5/containers.html Also, containers do not have anything to do with widgets.

No, I didn't mean that indeed, although that link was also nifty. :)
I mean those widget/application windows containers like QMainWindow. That work as scaffolding covering the whole project and also need some widgets to be added to be able to put other controls on them, like the one above.

tomy

@jsulm

I don't understand the problem: you can call methods of other classes in a class as long as you have instances of that class:
void ClassA::someMethod()
{
    ClassB classB;
    classB.someMethodInClassB();
}
So, what is the problem?

I know that.
Oh, so sorry. The vector contains instances of the class Task. :)
I don't know why I didn't note that, I must have been out of my mind!

jsulm

@tomy said in No widget is shown, strangely:

But it sounds that, it's not a real central widget, but a place/room, that "must" be filled by another widget! :(

Wrong. There is already a widget by default which you can get using https://doc.qt.io/qt-5/qmainwindow.html#centralWidget
If you, for some reason, want to set your own widget you can do so as well: https://doc.qt.io/qt-5/qmainwindow.html#setCentralWidget

QMainWindow simply provides functionality you need in an application window. A QWidget is simply a base class for all widgets and does not (and should not) contain functionality needed in a main window of an application.

SGaist

@jsulm said in No widget is shown, strangely:

Wrong. There is already a widget by default which you can get using https://doc.qt.io/qt-5/qmainwindow.html#centralWidget

Just to clear one thing, as noted in the documentation, by default there is no central widget. You may have one though when using Designer as it might be added automagically for you.

tomy

Another question,
Please take a look at the following method of the example:

void test_1::addTask() {
   bool ok;
   QString name = QInputDialog::getText(this, tr("Add Task"), tr("Task name"),
                                        QLineEdit::Normal, tr("Untitled task"), &ok);

   if(ok && !name.isEmpty()) {
       Task* task = new Task(name);
       connect(task, &Task::removed, this, &test_1::removeTask);
       connect(task, &Task::statusChanged, this, &test_1::taskStatusChanged);
       mTasks.append(task);
       verticalTasksLayout->addWidget(task);
       updateStatus();
   }
}

Both connections are right and work correctly, inside the if condition, but my question is couldn't we declare those two connections somewhere else so that they're more general and not specifically inside that condition?

Declaring the connections inside a condition to my eyes looks rather weird! What are your opinions, please?

mrjj

Hi
Perfectly normal.
The connect statements are part of the new Task creation so its natural place to have them near where the instance is created.
if no new task is created, then no connection needed

tomy

@mrjj
But it's sort of repetitive, isn't it?
We here declare the connections once again each time a new task is created, while the whole connections' concept is a sole thing, I surmise.

mrjj

@tomy
Oh no.
A connection is pr instance .
Meaning, if you want every task to be able to report "statusChanged" then
each must be connected.
Its not as a type thing. Its from real object to real object.
So all must be connected.