@Dariusz Sorry to make a post to just confirm what @SGaist has said above, but 20 * 75 == 1,500-odd line edits average. That's a lot! (And I pity the user who has to fill those in ;-) ) I think the suggestion that you look at the possibility of some kind of table instead needs reiterating. And @VRonin will then be here to ensure that you achieve this using item delegates instead of widgets in your table, so it will all be fast and not use up too much memory/resources ;-)

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