[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XForms] Some requests
From: |
LukenShiro |
Subject: |
Re: [XForms] Some requests |
Date: |
Mon, 28 Dec 2009 15:51:42 +0100 |
Il giorno Mon, 28 Dec 2009 14:14:32 +0100
Jens Thoms Toerring <address@hidden> ha scritto:
> 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...
It's likely you are right; alas for now it is a temporary hack, until I
catch where the problem is deep-seated (I would not be astonished if it
wasn't ctypes fault, but a flaw of mine).
> 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;-)
Uhmm, in fact it is not so much clear, it's simply a little mess,
I guess :-//
> 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.?)
Alas AFAIK if I access to a FL_OBJECT struct member, I've necessarily to
transpose FL_OBJECT struct to a FL_OBJECT class (inherited from
ctypes.Structure class), to deal with it.
> 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).
Maybe some C getter functions (as you said) would be greatly helpful
for individual struct members that are supposed to be
evaluated/considered (but I didn't mean to burden too much upon your
work ...).
Regards.
--
GNU/Linux * Slackware64 current
Slackware 13.0-32bit VM
LU #210970 SU #12583 LM #98222/#412913
Re: [XForms] Some requests, Jens Thoms Toerring, 2009/12/27