@Robin_Khn Ok super. So its just qmake/moc that is a little slow sometimes. So when you add something to the UI from and go back to the code, you can press ctrl+shift+b (build file) it knows the new Widget right away.

@mrjj If it works with setters, it should be fine. I'm relatively new to Qt and since you have signals and slots, I thought using setters is maybe not the best way, so there MUST be another solution :) haha Ok I will try it out tomorrow and let you know if it worked for me :) EDIT: @mrjj @SGaist Thank you guys, passing the pointer to my data with constructor and setting the data to a local member to use it inside my WindowChildClass worked for me.

Hi, The terminate as it names suggest kills the the thread so it's state is not guaranteed as mentioned in the documentation. Not that you are automagically destroying everything once your operation is done. See your connections to the deleteLater slots.

@jsulm TBH, I'm not I exactly sure I understand my own question! @mrjj & you explained the practicalities --- you just need a QObject. (I am PyQt, so I don't have a "Q_OBJECT macro", but I guess PyQt's QObject() automatically has that present if I use such an object or inherit from it?) My question was more of a "conceptual" one. If the OP has subclasses "with no UI", they are divorced from the UI, so I don't really see how they & the UI would know which signals to exchange/place slots on. But it's a bit of a woolly question....!

I've found the problem it is a process deleted without initialized.

Hi and welcome There is a special sender() in a slot you can use to know which button was the sender of the clicked() signal void aaa::on_push_button1_clicked() QPushButton *butt=qobject_cast<QPushButton *> ( sender() ) ; if (butt) { } that way u can use a variable and not ui->NAME All you buttons should be connected to same slot then. You could do that after setupUI() QList<QPushButton *> list = this->findChildren<QPushButton *>(); foreach(QPushButton *b, list) { connect(b, XXX }

@oblivioncth said: Ok, its shaping up , super :) "Helps givez me codes". We do help those too but good questions often get better answers. Also its clear that you do try to fix it first yourself, so some holes in c++ is no issue. Cheers

hi normally you would not allow directly accesses to UI class from outside as then all of the program know you have a QFrame in there. The better way is simple to create public function that sets the data u need in the class that owns the UI say like public: SetSugarViewData( QString Name ); and in cpp you implement it and there u can use ui->SugarView Then main will talk to "sugerview" via the public functions and has no need to have access to UI-> directly.

@mrsurge Hello, Ok I have a separate form, cpp, and .h for my dialog, does all this still apply? do i need to add anything to my dialog.cpp or .h? It shouldn't matter how you initialize the dialog, provided you call QDialog::accept() at the appropriate place, i.e. when a save/ok button is clicked. Kind regards.

@maximo Ok :) I am going to test again with stylesheets. It would be very nice it it worked as docs says. Or at least to understand why it did not. Update: Ok, one must unpolish/ polish each widget as doing it to Mainwindow doesn't seems to work. But it also works with setStyleSheet(styleSheet()); in MainWindow to reload (whole) style sheet. Update 2: Ok. Having qframes with bool error property. It will update in Designer, if setting it. No code. Sheet on MWindow. So it does work with properties it seems.