Re: [E-devel] Evas event handling -> void *event_info?

[Carsten H. (T. R. <ra...@ra...>]

On Sat, 17 Nov 2012 17:37:42 +0100 Andreas Volz <li...@br...> said:

> Hello,
> 
> I've just some problem to understand that event_info parameter in Evas
> callbacks. e.g.:
> 
> http://docs.enlightenment.org/auto/elementary/fileselector_example_c.html
> 
> ...
> /* 'selected' cb */
> static void
> _fs_selected(void        *data,
>              Evas_Object *obj,
>              void        *event_info)
> {
>    const char *selected = event_info;
>    /* event_info contains the full path of the selected file */
> 
>    printf("There's been a selection: %s\n", selected);
> }
> ...
>  /* the 'done' cb is called when the user presses ok/cancel */
>    evas_object_smart_callback_add(fs, "done", _fs_done, win);
> ...
> 
> In this example the event_info* is casted in sime magic way to a char*.

there is nothing magic about that :) stop thinking c++ and think C. :) the
event_info pointer points to some data that is specific to the type of event
that triggered the callback. what that thing it points to is will change from
event to event, thus its "void *" and up to the programmer to read the docs for
that event.

> My problem is that event_info* could always be anything and I don't
> know it without looking into the sources (here e.g. elm_fileselector).
> It's not written anywhere in the documentation that event_info* is a
> char*. (Or I didn't find it...)

well normally the docs will tell you what it is. if not then it probably should
be added. fyi the usage i'd sepect is not to use event_info at all there but to
GETthe selected file path inside the callback.

> So is there any way to find out as API user the type of event_info*
> which I should cast?

read the docs. :)

> In my special case (Eflxx C++ wrapper) have the problem to design a
> type safe interface. I've really no idea to do it. But even using the C
> interface I don't like it. Or did I miss understood the API?

general callbacks like this are preyy much impossible to get "typesafe". not
unless we go creating special cb tpes per event type and thus multiple callback
add funcs an thats just becoming insane code-wise. :)

> I would really prefer that event_info* would be some structure with a
> data pointer and some magic identifiers. Then it would be possible to
> find out the type of an event.

the expectation is: you set the cb - you thus know the event type and that cb
handes that specific event type only. - no multiplexing multiple events thru a
single cb... :)

> What do you think? Am I alone with this problem? Any ideas for a better
> event_info interface?

t=the problem is to make things "compile time type safe" we'd have an insane
number of macros and/or functions to force only sepcific callback prototypes to
be used and the number would baloon nastily. at runtime we could make it
basically as u mention - a struct with some type info etc, but then event_info
is beginning to become an object. as such it was built to carry ANYTHING you
wanted. an object ptr, a ptr to a strct on the stack, a string ptr, or whatever
- its the pointer via which context info for the event is delivered.

> regards
> 	Andreas
> 
> -- 
> Technical Blog <http://andreasvolz.wordpress.com/>
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...