Re: [XForms] Some requests

[Jens Thoms Toerring]

On Mon, Dec 28, 2009 at 12:25:39PM +0100, LukenShiro wrote:
> Il giorno Mon, 28 Dec 2009 00:08:42 +0100
> Jens Thoms Toerring <address@hidden> ha scritto:
> > Just to make sure I understand things correctly (and I have to
> > admit that I don't have any good idea how the ctypes library
> > works and I guess without a deeper understand of Python's in-
> > ternals will be a bit difficult for me to grasp). When you
> > write "uses different created instances of FL_OBJECT" does
> > that mean that they don't get created with the fl_make_object()
> > function which is always used to create objects used within
> > XForms?
> 
> Sorry, almost all public XForms functions are called by corresponding
> python functions in my wrapper (so I'd say fl_make_object is not
> directly called, but it works nonetheless as it is called by a function
> in C that is called by another function). When I call e.g.
> fl_add_button(..) the return value is indeed a FL_OBJECT (so it was
> correctly created by fl_make_object beforehand).
> 
> The awkward ctypes behaviour I was referring to is:
> http://python.net/crew/theller/ctypes/tutorial.html#surprises
> 
> The problem relies mainly into accessing struct members, if a XForms
> function sets a value for a struct member and then I, in python, have
> to retrieve it, it is not guaranteed I have that previously C set value.
> 
> E.g. for obj->visible
> in fbrowse.c there is a function hide_show, roughly as such:
> 
> if <visible>
>   fl_hide_object(..)
> else
>   fl_show_object(..)
> 
> Value of <visible> in python was always 0, so this function didn't work.
> 
> I see C fli_show_object(...), called by fl_show_object(...), sets
> obj->visible = 1; but when my wrapper function retrieves pointer to
> FL_OBJECT this value is 0. I've managed to resolve this problem adding
> to my function a statement to set .visible attribute to 1 _after_
> calling C fl_show_object(...), and adding a statement to set .visible
> attribute to 0 after calling C fl_hide_object(...): with this trick it
> works perfectly.
> 
> The same happens with fl_activate_object(...) and
> fl_deactivate_object(...): in these cases I've to set .active attribute
> to 0 or to 1, after calling correlative C functions.
> 
> I suspect that the problem can be applied to other struct members as
> well, I've to verify throughly.

Mmmm, I supspect that there's something going wrong on a deeper
level and that your "trick" is leading you into a bad direction,
i.e. a fight you can't win. E.g. setting the .visible attribute
of the object alone after a call of fl_show_object may not be
enough since an object may have child objects that also have
their visibility changed. And the call may also have changed some
other attributes beside - having to find out what may change and
reproduce it in Python is going to be a loet of hard work and there
are no guaranties that what you found out with a lot of effort and
then reproduced in Python will still hold in three years (or even
three months) time...

I am groping a bit in the dark here since I don't understand
enough about Python/ctypes and the explanations given at

http://python.net/crew/theller/ctypes/tutorial.html#surprises

aren't really clear to me. But what I get from it is that in
some cases copies of objects will be created when you don't
expect it and in other cases no copies are made when you
want them to be created;-)

My gut feeling is that Python/ctypes better shouldn't be aware
at all of what an FL_OBJECT consists of, it should be treated
on that level as an opaque pointer so the contents of an
FL_OBJECT never get copied - the copy may get out of sync
with what is stored in the original in hard to trace ways and
the question is how "deep" the copy is (does the copy e.g. also
contains pointers to copies of child objects or pointers to the
child objects of the original, and then what about children's
child objects etc.?) Of course, to be able to do that a number
of new accessor methods for object attributes may have to be
added, like 'fl_object_is_visible()' or 'fl_object_is_activated()',
but writing them isn't a big deal (I hope).

                                Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de