QCheckBox trouble + How to refresh a paint window if an other is open over and select

[andreaQt]

My goal is to freeze the state of checkbox when i push the START button and unfreeze it when i push the STOP button, i write this code but it doesn't work (find the line "//SUGGEST WHAT TO DO" and make a brekpoint at about line 186); see the file.
An other question is:
I write an other program that visualize the data that i've sended (with Qpaint->repaint() call), but if this window isn't select the paint window isn't refresh till i select it; what is the best practice to do it? My goal is to refresh the window even it isn't select.
An other question is:
What is the best practice to open an other window and pass to the new window all parameters/class of mainwindow?
Thank you.

[andreaQt]

I found this solution for paint the widget if even the window is not selected:
you have to set this attribute in the mainwindow where the widget are inserted (but i have a trouble when i paint the last draw i want):
setAttribute(Qt::WA_ShowWithoutActivating);

[anda_skoa]

If you want to "freeze" a widget, simply set it to "disabled".

Not sure what you mean with not painting while not being selected.

When a widget has new data to display, it can simply request redrawing by calling its update() method.
Qt will then issue a new paint event and let the widget redraw itself.

If you need to share data between windows, simply pass a pointer or reference to that data, for example as an argument to the second window's constructor.

Cheers,
_

[andreaQt]

.. so i have just to #include "mainwindow.h" in the file nextwindow.h ..
ok, thank you anda_skoa.
where i can find the button to close this thread/post?

[anda_skoa]

.. so i have just to #include "mainwindow.h" in the file nextwindow.h ..

Only if the new window needs to access the previous window's API.



where i can find the button to close this thread/post?

That's not necessary.

Cheers,
_

[d_stranz]

.. so i have just to #include "mainwindow.h" in the file nextwindow.h ..

Usually that's a sign of a "very bad idea", especially if it means you would be doing something like declaring MainWindow's "ui" or other member variables as public so that NextWindow could have access to it.

Think about how to accomplish the same thing in the Qt way - use signals and slots to set up a member function level communication between MainWindow and NextWindow. If something changes in MainWindow that NextWindow needs to know about, create a signal for that in MainWindow and a slot to handle it in NextWindow. Connect those in the part of MainWindow where NextWindow is created. If you do it correctly, there will be no need at all to include the mainwindow.h header in NextWindow's code.

You will have to include nextwindow.h in MainWindow's code, but you have to do that anyway if you are going to create an instance of NextWindow from inside of MainWindow's code. But there is usually no need at all to go the other way.