In the example you provided in your website how to upload/download async FTP with Progress Info (https://www.example-code.com/objc/async_ftp_progress.asp) you used the CkoTask to keep tracking the progress status and the completion status of the task inside a while loop sleeping every 0.1seconds. I was wondering if there was a way to use the CkoTask with the EventCallbackObject, demonstrated in the sync FTP Upload with progress event callback (https://www.example-code.com/objc/ftp_upload_with_progress.asp), this way I don’t need to stay in the while loop and check every X seconds if something has happened, letting the EventCallbackObject alert me when something has happened. One of the goals to use the CkoTask is that we can cancel the task whenever the user wants to cancel something.
The answer is Yes, you can do it.
This answer applies to those specific programming languages where event callbacks are supported. This answer is also further restricted to those programming languages where event callbacks in a background thread are generally possible. (If using the Chilkat ActiveX, this is typically not possible.)
For C, C++, and Objective-C, this is easily possible.
You'll want to go to the online reference documentation. For Objective-C, the documentation is at https://www.chilkatsoft.com/refdoc/objcCkoFtp2Ref.html
In the left rail, scroll down to find the "Events" section at the bottom. (In the left rail, the Properties are listed first, then Methods, and finally Events.) Click on the "overview" link under "Events".
For the case of C++ and Objective-C, you'll see code snippets of how to define a class that inherits from a back class (in this case CkoFtp2Progress). In your class, you would override one or more methods, and then "install" the callback handler like this:
CkoFtp2 *ftp = [[CkoFtp2 alloc] init]; MyFtp2Progress *callbackObj = [[MyFtp2Progress alloc] init]; [ftp setEventCallbackObject:callbackObj];
Some Important Notes:
1) You must be careful though, because the callback will be in the background thread. If your callback handler accesses objects or data structures that could be simultaneously accessed from the foreground thread (or any other thread), then you'll need to make the access thread-safe.
2) The Task object is not involved in these callbacks. The callbacks are coming through the Chilkat object (CkoFtp2 in this case) just like they are for a non-async method call.
3) Notice that you're providing a pointer to your MyFtp2Progress object. A common mistake is when the MyFtp2Progress object is a local variable on the stack. Let's say you initiate the asynchronous transfer and provide a pointer to the MyFtp2Progress object which is a local variable on the stack. If the MyFtp2Progress object is destructed (i.e. goes out of scope), then you won't get callbacks. Chilkat manages to safeguard against hard crashes in this case through some internal cleverness, but you'll be left wondering why callbacks aren't happening. Your callback object must have a lifetime that outlives the operation.