Am Montag, den 26.09.2005, 09:47 +0200 schrieb Matthias Kaeppler: > The latter (I think the slot is called on_progress_sync), returns a > guint. But which values do I have to return when I handle a query in > this callback? http://developer.gnome.org/doc/API/2.0/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-xfer.html > Let's say I'm trying to overwrite a file which is already > present. Then this function is called. Okay, I handle the error and then > what? Depends on what you want to do, i.e. what member of GnomeVFSXferOverwriteAction you pick as retval. You should also be able to pass GNOME_VFS_XFER_USE_UNIQUE_NAMES as XFer option, which should make GnomeVFS query you for a new name (cf. new_file_transfer_callback/GNOME_VFS_XFER_PROGRESS_STATUS_DUPLICATE in nautilus-file-operations.c, which Alex already pointed out). Also note that the Xfer functions have proved to be quiet buggy under some circumstances throughout the last few months. The debugging efforts continue, but since at the moment almost only Nautilus uses our Xfer API it might take some time to get the whole xfer process really clean. Pleas help :) > Weird enough, my code even compiles when I don't return anything! > (at this point I have to mention that I am using the C++ bindings to > gnome-vfs, so this may not be true for C code). I don't even get a warning. Weird. I wonder whether you casted your function when passing it to gnome_vfs_xfer_uri. Maybe it's yet another "Welcome to the wonderful worl of C" issue - you can pass functions with arbitrary signatures (and therefore retvals) as function pointers if you cast them to the expected signature. This means however, that - in the case of passing a function with a void signature casted to a function with an int retval - the value and therefore the interpretation of the retval is undefined. -- Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part