When I ran into this, it has almost always been because of method
parameters initialized with default values in the constructor of some
PySide class. Let’s say class A gets instanced twice. If instance X is
garbage collected for whatever reason, when instance Y tries to use Y.b
it’ll complain about the C++ ref to 123 being lost.
class A:
def __init__(self, a=123):
self.b=a
*CHRIS GRANADOS - Xian*
Pipeline TD- CG Supervisor
Bs. As., Argentina
On Sat, 23 Mar 2024 at 16:56 Justin Israel <[email protected]> wrote:
> Qt (C++) usually honors the parent-child relationship, so it won't
> automatically delete a widget unless its parent is being deleted. And if it
> doesn't have a parent, it shouldn't be automatically deleted by reference
> count unless it is wrapped in a smart pointer. Or maybe you have looked up
> a reference to a widget through shiboken that you didn't create, which is
> how it could later become invalid.
> Do you make use of parent-child assigments in your Python code? Does it
> happen with widgets you created in Python, or only widgets you looked up as
> a reference through shiboken?
>
> I think it is fair for Marcus to ask to see concrete code as an example,
> because I don't think the idea of C++ objects randomly being deleted from
> under the Python refs should be considered normal. It shouldn't be
> something you just have to expect would happen at any moment. Rather, there
> may be a pattern in your code that should be avoided or worked around.
>
>
>
> On Sun, Mar 24, 2024, 7:42 AM Juan Cristóbal Quesada <
> [email protected]> wrote:
>
>> Hi Marcus, thanks for the reply.
>>
>> You see, that is what i want to avoid at all costs. I dont want this
>> thread conversation to evolve following a concrete, specific use case, but
>> rather try to aim at "the bigger" picture. There are may examples of where
>> and how this C++ already deleted error occurs. Im sure we all can think of
>> one example in our code.
>>
>> My question, generally speaking, was aiming at preventing this to happen
>> at all costs by following a "good coding practice" convention.
>> For example, is it good practice to store every python widget in a static
>> class variable? would that avoid all these kinds of errors? What if you
>> store a QWidget object in a python list and then try to access it because
>> it got registered as a subscriber, but, at the moment of calling the method
>> you subscribed for, the C++ bound object no longer exists because the C++
>> reference count went to zero?? Is it good practice to try to use the
>> shiboken2.isValid() method to validate everytime the C++ Widget pointer?
>> all over the code? and to use the MQtUtil.findControl() method to retrieve
>> a C++ alive pointer to a widget? What if we need to store a widget
>> temporarily with no parent so we are able to further on perform a
>> setParent() but the C++ object was already destroyed?
>>
>> All these are use cases that we all can encounter. Im just trying to
>> figure out a general method to avoid all these problems ,specially to the
>> more junior TDs, Tech Artists, etc.
>> That s why i was asking for a "general rule" to avoid these use cases.
>> Again, i would not like to make a discussion here out of a specific use
>> case. But rather, mostly curious towards how the more senior profiles
>> tackle with this.
>>
>> Thanks!!
>>
>> El sáb, 23 mar 2024 a las 19:07, Marcus Ottosson (<[email protected]>)
>> escribió:
>>
>>> It would certainly help if you could provide an example of something
>>> that causes the error, or at the very least a stacktrace of the error.
>>>
>>> On Saturday 23 March 2024 at 18:04:59 UTC [email protected]
>>> wrote:
>>>
>>>> Hi,
>>>> i ve been working for quite some time now and occasionally bumped into
>>>> this C++ "unfamous" error. Normally, when found occasionally, ive been able
>>>> to fix it by using the widget's "self.findChild"/"self.findChildren" which
>>>> i believe keeps the C++ reference count of the object's pointer alive. Fair
>>>> enough!
>>>> So, instead of storing the C++ widget in a python bound object, i would
>>>> retrieve it from the parent-child hierarchy, provided the widget has been
>>>> added firstly to the layout.
>>>>
>>>> Well, we have a snippet of code in our project that relies heavily on
>>>> the publish-subscriber/observer pattern and i wouldnt like to rewrite it
>>>> because of this C++ infernal error. So here is my question: what's the best
>>>> policy to try to avoid this RuntimeError "forever and after"? Ideally, i
>>>> would be tempted to use a "template" tool class that would register all the
>>>> widgets automatically in its __init__ method and perform a
>>>> MQtUtil.findControl/MQtUtil.findLayout, but i am still encountering this
>>>> error somewhere else.....
>>>>
>>>> I dont want to solve this punctually but rather establish a good coding
>>>> policy to avoid "forever" this!.
>>>> So, what is your policy trying to avoid this error? Have you found a
>>>> permanent solution to this?
>>>>
>>>> Thanks in advance,
>>>> My name is Juan Cristóbal Quesada
>>>> and i work as senior pipeline TD in Spain.
>>>>
>>>> Kind Regards,
>>>> JC
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/ea8d4cdc-d206-4492-bd54-d7ca3f2c5e23n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/python_inside_maya/ea8d4cdc-d206-4492-bd54-d7ca3f2c5e23n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CANOg8wX%2BfVvPD6zCcD_nhHGCxi5tnpdTdhMHzNY4VruF2VBDmQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/python_inside_maya/CANOg8wX%2BfVvPD6zCcD_nhHGCxi5tnpdTdhMHzNY4VruF2VBDmQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0SK3%3DrXu2JBWMH8nQ__AjB6VnywwgFNfwj_UTePCTWEg%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0SK3%3DrXu2JBWMH8nQ__AjB6VnywwgFNfwj_UTePCTWEg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAAgNOzSHxcBKNf39ziA7DZavEgzd4K4VQZp9y0wEi5cgOVL-Pw%40mail.gmail.com.
