Re: troubles with Gnome::Vfs::Transfer::transfer()

[Marko Anastasov <marko marko anastasov name>]

У нед, 27. 05 2007. у 22:09 +0200, Sergio Perticone пише:
> 
> Sergio Perticone wrote:
> > I'm sending this here because gnomemm list seems to be died, so sorry if
> > it's a little bit off topic.

No, it's not offtopic - this list is for gnomemm talk as well.
gnomemm list has been killed recently.

> > 
> > I'm studying libgnomevfsmm, but I've a problem with this example code:
> > 
> > [snip]
> > 
> > transfer() throws _always_ an exception. e.what() returns "Operation
> > interrupted".
> > I really don't know what's wrong with that... anyone have any ideas?

Note that you passed XFER_ERROR_MODE_QUERY as a parameter - this
means that you've explicitly stated that in your signal handler
you will determine the action in case of an error.

> Solved!
[snip]

> With default SlotProgress() it doesn't work... Maybe when 
> progress_callback is not specified the wrapper should call 
> gnome_vfs_xfer_uri() with NULL, NULL as last two arguments..?

Hmm, I don't see a way to determine that. When the callback is
not specified it means that you're relying on the default one.
And that's of course not null... Anyway, I think that if a
non-query call to transfer() with a default signal handler
left results in an exception, that deserves some investigation.
Frankly, I've never even thought of not providing a handler.
I guess if you're using this API you probably need a bit more
than what a couple of standard C calls could do.

Now the important detail. Transfer::SlotTransfer's signature
is not correct, ie it returns bool which blocks the use of
on-query action-defining return values. This is why there are
now Transfer2 and Async2 namespaces, currently available only
in svn trunk.


    Marko