@JonB thank you

No, it's not about a performance issue.
I was just not satisfied with leaving this function running until the end, since I already had my result and the rest will not bring me anything more.
If I need to write it in a simple 'foreach' loop, I would write something like

for( value : list ) if( value == search ) return true; return false;

And I wanted to keep the same spirit with 'mappedReduced' (as long as this doesn't violate any "thread-rules" and without having to "hack" QtConcurrent).

But yes, in fact I'm blocking my application untile I receive the results. My other methods that need to perform an action on all the items use 'blockingMapped', 'blockingMappedReduced' and 'blockingFiltered'. It's for a library that I am writing. And the applications that will use it are procedurale, not a GUI (or, maybe later...who knows?). But they may have to handle very long lists, and the 'compute' function are heavy. So QtConcurrent is a welcome help.

I think I'll keep the first solution, the most elegant one in my eyes, if I don't get any warning.

@red.green said in How to assign property values temporarily without breaking existing binding in qml?:

How do I make sure that the previous binding is kept intact?

Assigning a value breaks the binding - if it was not this way QML would be horribly broken ;-)

There are a few ways around it, though. First, most obvious one - set the new value on the binding source. So if you have:

Text { text: someProperty }

Assign your temporary value to someProperty. You can add some code that will manage it's temporary nature there (onPropertyChanged or better in some object that holds the value of that property).

Another way is to set up the binding using Binding element, disable it when Cancel is pressed, then enable it again once your temporary situation changes.

@DougyDrumz said in Can't Cancel Progress Dialog.:

OK. I found it. I was being dumb! I have two flavors of Progress Dialogs. One is inside an App, and the other is standalone, meant to be called form a script. I was looking at the one in the App when I should have been looking at the other one. The standalone one doesn't have have a cancel slot.

Good !

Thanks to all of you.

I have no time to dedicate close to a day to implement and test a method to copy files little by little (although there have to be loads of code parts already implemented I'm sure). By the moment, If the user is copying a large list of files and wants to interrupt the process, the process will finish when it finishes to copy the current file at that moment, and will erase the previous files. If the current file is huge, the user is going to wait until the end of the copy.

We know now the behaviour of the Qt copy process, so in the future if it is a problem for somebody, we will have to implement the buffer...

Again, thanks!