dotnet
Make ProgressDialog public
Background and motivation
If we decide to make DownloadFileAsync public, making ProgressDialog public would greatly simplify the design and anyone using it the API would have more control over behavior if ProgressDialog was public.
API Proposal
Namespace Microsoft.VisualBasic.MyServices.Internal
''' <summary>
''' A dialog that shows progress used for Network.DownloadAsync and Network.UploadAsync
''' </summary>
Public NotInheritable Class ProgressDialog
Inherits Form
API Usage
''' <summary>
''' Centralize setup a ProgressDialog to be used with FileDownload and FileUpload.
''' </summary>
''' <param name="address">Address to the remote file, http, ftp etc...</param>
''' <param name="destinationFileName">Name and path of file where download is saved.</param>
''' <param name="showUI">Indicates whether or not to show a progress bar.</param>
''' <returns>New ProgressDialog.</returns>
Friend Function GetProgressDialog(
address As String,
destinationFileName As String,
showUI As Boolean) As ProgressDialog
If showUI AndAlso Environment.UserInteractive Then
'Construct the local file. This will validate the full name and path
Dim fullFilename As String = FileSystemUtils.NormalizeFilePath(path:=destinationFileName, paramName:=NameOf(destinationFileName))
Return New ProgressDialog With {
.Text = Utils.GetResourceString(SR.ProgressDialogDownloadingTitle, address),
.LabelText = Utils.GetResourceString(SR.ProgressDialogDownloadingLabel, address, fullFilename)
}
End If
Return Nothing
End Function
If showUI AndAlso Environment.UserInteractive Then
'Construct the local file. This will validate the full name and path
Dim fullFilename As String = CompilerServices.FileSystemUtils.NormalizeFilePath(destinationFileName, NameOf(destinationFileName))
dialog = GetProgressDialog(address, destinationFileName, showUI)
End If
Dim t As Task = DownloadFileAsync(
addressUri,
destinationFileName,
networkCredentials,
dialog,
connectionTimeout,
overwrite,
Alternative Designs
User will have to invent their own ProgressDialog
Risks
Low it already exists and is use in WinForms Repo
Will this feature affect UI controls?
Documentation for New control will be needed VS Designer will not need to support Since it is currently used in FileUpload and FileDownload accessibility and localization are already covered.
I will schedule this for internal discussion in this week's team meeting and see what is remaining for us to get into the API Review queue from Immo and what the timeline is they're looking at. The team is pretty tied up with preparing for .NET Conf and the release of .NET 9.
@merriemcgaw Without making some of the DownloadFileAsync functions Public (requiring API Review) there is little benefit making ProgressDialog Public, it would just make it easier to replace the obsolete WebClient, but probable not enough to justify the overhead. Though it is a very useful API most people that need it probably have their own solutions.
Unfortunately, not just yet. @KlausLoeffelmann is just getting back from vacation and we need to fold this in with our other current priorities - though I really do like this idea, so I'd love to see it for 10 myself!
@merriemcgaw no rush, code change is trivial (Friend becomes Public) if API isn't changed it's documentation of the API that would be needed.
@KlausLoeffelmann @merriemcgaw I think I wrote a comment about this is the wrong place so I will repeat it here.
The current implementation does not handle long file names/paths well. If the is to be made public there should be some Flags that specify how long paths should be handled. The default would be leave as is, other options would be
Truncate Path to show as much of the path as fits with truncation would start with drive so filename would most likely be visible. Give a maximum path of 32,767 characters there really is no guarantee that even filename would fit.
Other options would be to expand width and/or height or dialog and to allow more of the filename to fit.
The address in the Title Bar has similar issues though not shown in the example.