Current File Being Processed... Get the name and Path???

[MarkECrum]

Is there a way to get the current file name being processed? This should be available on the OnProgressChanged event... but I don't know if it is even possible to tap into that info from robocopy..... Can it be added?

[PCAssistSoftware]

In the OnFileProcessed event e.ProcessedFile.Name ?

[MarkECrum]

Yes of course, but that gives you the name AFTER it has already been processed, not while it is being processed or before the processing started... am I right?

[PCAssistSoftware]

I was pretty sure it shows the file currently being processed, certainly from my testing with large files it does

[MarkECrum]

hmmmm, ok then. I'll do that with a big file so I can see the results. I had already implemented it the way you suggested just to get it on the form... Only I change my lable from current to "Last file" !!!! Thanks I'll confirm results... ps. I have a question about the "Dispatcher" used for access to the main UI... can you shed light on that one...

[RFBomb]

see #100 for current file being processed
also, in #128 I'm adding this into the InProgress args

[RFBomb]

In Winforms, it is assumed the main screen runs off the main thread. Anything by that needs to talk from a spawned thread to main thread (or vice versa) needs to be invoked. That is via event subscription typically.

in winforms, unless otherwise specified, everything is handled in the same thread as the UI thread, so Invoking is only performed when threads talk to each other. Long processes can stall the UI for this reason.

In WPF, which the backup app uses, the UI thread is handled separately to keep to it snappy. Events generated from the UI (code behind a button press) do not need to be invoked, since the UI thread is running that event.

But anything method calls that are generated from outside the UI thread
(Such as reacting to an object be added to a list or a property change event) requires the Dispatcher to invoke the method. In this case, the Dispatcher tells the UI thread ‘Hey, do this ASAP!’

My understanding is that the dispatcher needs explicitly be called in WPF due to how the thread is managed, whereas in winforms its implied. (Winforms still requires Control.invoke, which would essentially automatically use the dispatcher, whereas WPF doesn’t automatically do that, probably to save resources overall)

atleast, from my short time working with both, what it feels like is happening. I didn’t actually research this, just kind of assumed based on the code that gets it functional.

[PCAssistSoftware]

@MarkECrum - you should now be able to get the information you need after changes made in #134 :)