Le 4 mars 2015 à 10:15, Christian Schmitz <[email protected]> a écrit:
> Well, first there can be bugs in the system functions or my plugin. That'd be something to sort out. > If the object is not kept alive long enough, the destructor will shutdown the > event properly. Correct; I've defined it as a property for that reason. > And if copy is too short it will properly not call event. That may be my problem. I'm relying on the event to start the next file (so each file is copied serially). I understand that StatusChanged event is a “catchall” event: it doesn't differentiate if the copy starts, runs, or ends. It's not very reliable to know when a copy is finished if there's neither a specific event for that and the only available one may not execute at all. It's even worse, as I don't see a workaround. I could use a timer approach (the timer checks each second if the copy has finished and, if yes, launch the next copy), but the MacFileOperation class also lacks a property to check the state outside of the StatusChanged event. What's the proper way to copy files serially using this class? > As well as if main thread is too busy. It makes no difference if I don't break into my code or not, so the only thing that could block the main thread (i.e. RS resuming the suspended app) isn't the issue, I believe. Thanks _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
