Hi! 2011/12/18 Abderrahim Kitouni <[email protected]>: > [...] >I implement an internal class in Vala, >> which defines the following callback: >> public signal Results request_whatprovides (uint filters, uint >> provides, [CCode (array_length = false, array_null_terminated = true)] >> string[] search); > > AFAIK, signals with return values aren't supported in Vala. Another > important thing you didn't mention is what is result (is it a class, a > struct). It is a GObject-derived class. (I thought this was clear when I wrote it's a pointer to a GObject) If return values aren't supported, shouldn't valac emit a warning/error-message, so I don't even try to do this?
> And since you're talking about a callback, maybe you meant > delegate instead of signal. Yep, I didn't think of using a delegate before! This solved all issues now, thanks! (Sometimes the easiest solution is the best) >> [...] > I think you really mean a delegate, and if so, your callback should have > the arguments (guint filters, guint provides, gchar** search, gpointer > user_data), and return a Results* if Results is a reference type, and > have the arguments (guint filters, guint provides, gchar** search, > Results* result, gpointer user_data) if Results is a struct. > >> xy_request_whatprovides_cb (BackendProxy *sender, >> PkBitfield filters, >> PkProvidesEnum provides, >> gchar** search, >> gpointer user_data) > > Why are you using different types for the arguments? You should probably > have bindings for the library that is used by both you app and the > loadable module. I used different parameters to work around some problems before. But using different types isn't really a problem here. Thank you for your delegate hint :P Really stupid that I haven't thought about this before! Cheers, Matthias _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
