[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 12:25:39 +0100

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:

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>

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.

I think a uid member can be useful if I set a random value
every time I create/add an object from python, so it has a unique
value and it can be compared with another object's value (but it's a
problem I'll have to deal with in python, hopefully not for you in C).

I don't know if I can explain better, but it works perfectly if I
use, in python, e.g.:
obj1 = fl_add_button(...)
obj1[0].u_ldata = 255  (roughly the same as C obj1->u_ldata = 255)

then I compare this object's .u_ldata attribute with the product of
fl_do_forms()'s equivalent attribute.

> On the other hand, would a pointer comparison function written
> in C really do? I have just added a function
> int
> fl_is_same_object( const void * obj1, const void * obj2 )
> {
>      return obj1 == obj2;
> }

I've inserted this function in my XForms git local copy and wrapped it
in python, and it works very well.

> PS: > > > [X11 libraries functions wrapping]
>     This is finished and should be avaliable shortly from the
>     git repository. If you find more places where this is
>     necessary please tell me, I had a look a forms.h but
>     didn't find any others yet.

Thank you.

GNU/Linux * Slackware64 current
Slackware 13.0-32bit VM
LU #210970 SU #12583 LM #98222/#412913

reply via email to

[Prev in Thread] Current Thread [Next in Thread]