Hello,
في ن، 06-12-2010 عند 13:50 +0100 ، كتب Marco Trevisan (Treviño):
> Yes, this is right indeed. The signature is not the same, so why don't
> allow to define async signals?
How do you define an async signal?
> > > > You can also try to pass the begin method directly (but I'm not sure it
> > > > works).
> > >
> > > No, I tried that, but it didn't work, I got an error since the begin
> > > return value was considered just like a void.
> >
> > Hm, the begin function returns a void, but that's what the signal expects
> > anyway, so it seems like that one should work. That would be a bug than.
>
> It doesn't work to me:
>
> ma...@tricky:/tmp$ valac --pkg dbus-glib-1 --pkg gio-2.0
> dbus-connect-async.vala
> warning: D-Bus GLib is deprecated, use GDBus
> dbus-connect-async.vala:38.15-38.39: error: invocation of void method
> not allowed as expression
> if (name in sender.list_names.begin())
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> Compilation failed: 1 error(s), 1 warning(s)
>
> Is this a bug?
No, this is expected behavior : the begin method just starts the async
method, and does not wait for the return value and thus returns void.
But I don't understand how is this related to the topic (connecting an
async method to a signal).
What I was suggesting is that you should be able to pass the begin
method as a signal handler (assuming your signal doesn't expect the
handler to return a value), so when the signal is emitted, your method
gets started. In your example, this would be :
session_proxy.name_acquired.connect (this.name_acquired.begin);
HTH,
Abderrahim
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
