Hmm good catch! Although it turns out that I can't flick the list, because the items require some custom mouse move handling ... which reduces it to a non-interactive PathView. So, solved I guess! Thanks for pointing out the Tumbler though, and I hope my examples prove to be useful to others.

main.qml - What is the top level item ? Is it window or Item ? loginform.qml - What is top level item ? Is it window or Item ? This is typical issue of object deleted already is getting delete due to parent child relation ship ?

@jsulm When the pop up Message Box shows "python has stopped working", I clicked "debug" rather than close, then visual studio was started, in visual studio, it shows Unhandled exception at 0x0000000059A17DF1 (QtGui4.dll) in python.exe: 0xC000041D: An unhandled exception was encountered during a user callback I was using pycharm to trace code step by step, however it nev, aer run to this issue by step by step since there are two many small steps/callback/signal/slot to go through, as long as I let it run without breakpoint, it will crash with segmentation fault.

@VRonin Oh and you provide a model based solution. Much more elegant :) https://forum.qt.io/topic/72974/link-two-qlistwidget/4

thanks for the enlightening!

@pauledd :) class MyWidget : public QWidget << yes that is subclassing :) Also, a widget can only paint on it self. its not possible to paint on other widget from inside a paintevent. Thats why the first sample didnt work. You asked painter to paint on tab from inside mainwindows paintEvent :) I guess you already found out but its just to make clear for other readers.

@Wieland Thanks for the informations! In the Surface Example they only delete the Q3DSurface instance. But i will pass the parents to the classes, so i can be sure, that they are destroyed. Thanks!

@Chris-Kawa This is to ensure there's only one instance of it Ah, yes, I completely slept through this minor detail ... :$ Sure you could do something like this instead No thanks, I'll take your QPointer suggestion any day. The latter is ... well it's work-aroundishly ugly ... Sorry about that. Not at all, I agree with the "premature optimization is the root of all evil" stance I just didn't see the proximate cause for it here, that's all. ... hard to get wrong. This is what I always liked about the stack, as I'm lazy and don't like debugging bad code ... especially if it's mine ... ;)

@Chris-Kawa said: A simple fix is to set the parent back to null when you no longer need the widget e.g. after you call settingsApply(). Well that gets the job done. I was wondering whether there was a better / proper solution to this. Thank you for your help! I appreciate it a lot!

@kshegunov Thanks for your reply. Yes retrieving the child model via child and then setting data worked for me .

@SGaist It happens even to the best ... at the very least we both support it, so that has to account for something ;)

Hi, Isn't that pretty much the same question as here ?

Besides what @Rondog mentions, you could also read about layouts http://doc.qt.io/qt-5.5/designer-layouts.html If you assign a layout to the window, and put the tab in it, Qt can then automatically adjust the size if user resize the window. It takes a little bit to learn layouts but the reward is great.

In order to be future-proof I implemented the abstract node based concept as suggested by @Chris-Kawa and @Harb (in the first post). Everything is working nicely. Thanks for your help!

Yes my bad, I pointed you to the wrong property. Actually you must set the windowModality property : http://doc.qt.io/qt-5/qwidget.html#windowModality-prop, or the modal prop (only for QDialogs) : http://doc.qt.io/qt-5/qdialog.html#modal-prop. I believe that is the solution you've been looking for.

@SGaist said: Hi, @SysTech : deleteLater won't remove things when the thread is done, but at the next event loop iteration. Thanks. I wasn't exactly sure when it deleted it but good to know!

@Chris-Kawa That's a valid point I hadn't considered. I'll just have to give this some more thought. It seems like maybe the most "Qt-correct" design would be to override childEvent(QChildEvent* event) to take the pointer into the member object when a child is added to the parent object. This would then, at least, bypass the need to call "findChild" over and over again.

I fix this problem with signals and slots, but I firts create what a call a log, and after one minute a close that log. I'm getting this error while closing the log QEventLoop::exec: instance 0x8d4418 has already called exec()