ookii-dialogs / ookii-dialogs-wpf

Awesome dialogs for Windows Desktop applications built with Microsoft .NET (WPF)
BSD 3-Clause "New" or "Revised" License
1.14k stars 85 forks source link

Implement IProgress<T> in ProgressDialog #58

Open augustoproiete opened 3 years ago

augustoproiete commented 3 years ago

Discussed in https://github.com/ookii-dialogs/ookii-dialogs-wpf/issues/12#issuecomment-733567493

Originally posted by **vpenades** November 25, 2020 The use case most of the times is going to be background tasks initialized with an Object value that can be cast to multiple versions of `IProgress` so they can report back the progress of the backgrond task. I think the interface is not widely used because it's not very well known, but since `IProgress` exists from quite some time, I did a small search to see how people is using it, and I found: ```csharp IProgress // progress reported in values between 0-1 IProgress // progress reported in values between 0-100 ``` It is very tempting to have a structure that keeps all the information required by the progress dialog (percent, text, description), but this _must be avoided_ because that would mean the caller needs to fill that structure, which would force it to have a dependency on the ookii library, this is probably not desirable for background tasks, or pure code libraries that don't want to depend on an UI library. So, in order to pass rich progress information, we need to use only BCL types and collections. Unfortunately, `IProgress` does not define a standard.... but in general I guess everybody will expect (int Percent, string Text, string Description) So, I would propose adding these interfaces: ```csharp IProgress // by far, the implementation I've found most occurences searching on github. IProgress< KeyValuePair > // where key is the name of the property to set (percent, text, desc) ``` Additionally, the current `IProgress` and `IProgress` could cache the content so they're not mutually exclusive; the current code already caches the progress, but it should do the same with the text. So a background task could call these interfaces consecutively without loosing the value set by the previous call on the other property.