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()