[Bf-python] Re: Crazy tooltip bug

[Willian Padovani Germano]

Hi,

----- Original Message -----
From: "Stephen Swaney" <sswaney at swbell.net>
To: <bf-python at blender.org>
Sent: Friday, March 26, 2004 3:36 AM
Subject: Re: [Bf-python] Re: Crazy tooltip bug

(...)
> The catch here is that inside Number() we call
> PyArg_ParseTuple and get a C pointer to an existing C string
> that is part of the tooltip argument.  This C pointer is then
>  passed into uiDefButF() and friends.  This gives us a C pointer
>  into a Python string that, unfortunately in this case, goes out
> of scope when the draw() function exits.

I guess PyArg_Parse "unpacks", it creates new e.g. strings and return
pointers to them, not to a pyobject's content.  The problem here seems
to be that the returned string is local to the function and should be
"Blender malloc'ed" since it's needed after the function returns.

> It is a memory management issue, but I would not call it a
> python reference counting problem.  It is more of an issue with
> the interface between blender's C code and our python
> implementation.
(...)
> It's not *that* ugly and it has the virtue of working!

I agree with both comments.  Earlier, looking at Draw.c, I saw this
problem happens with the other functions that call uiDefBut***, too.

> The other approach would be to copy the character data out
> of the python tooltip string into a C structure that would
> then be managed by the blender ui code.  I didn't dive deeply
> enough into the UI internals to see how the responsibilty for
> memory allocation is passed around, but someone would have
> to handle freeing up the struct to prevent a memory leak.

Yes, since the tooltip is needed after the function returns and is local
to it, probably it should be copied to a Blender managed piece of
storage and code should be added to the py destructor to get rid of it
when the button goes away.  Will you fix it yourself, Steve, like you
did for a similar problem in Draw.c earlier?

--
Willian, wgermano at ig.com.br