Cant open Powershell dialog box from Visual Studio code

Question

Running the following code to use the "Open File Dialog" in Powershell ISE works fine. However, running the same code in Visual Studio Code wont open the dialog box...there is no error or so, it just seems to be running...

Does anyone have a solution or have encountered the same issue?

The code for the dialog box:

function Get-Files{
    $openFileDialog = New-Object windows.forms.openfiledialog
    $openFileDialog.Multiselect = $true
    $openFileDialog.filter = 'All files (*.*)| *.*'   
    $openFileDialog.filter = 'DataSource Or Report Files|*.rdl|All Files|*.*'     
    $openFileDialog.initialDirectory = [System.IO.Directory]::SetCurrentDirectory('c:\temp\') #'
    $openFileDialog.initialDirectory = [System.IO.Directory]::GetCurrentDirectory()
    $openFileDialog.title = 'Select Development *.RDL File to Copy:' 
    $openFileDialog.ShowHelp = $true
    Write-Host 'Select Datasource or Report File... (see FileOpen Dialog):' -ForegroundColor Green  
    if('Ok' -eq $openFileDialog.ShowDialog()){
        $openFileDialog.FileNames
    }
    
}

if($files = Get-Files){
    $fbd = [System.Windows.Forms.FolderBrowserDialog]::new()
    $fbd.ShowDialog()
    $files | %{$_.CopyTo($fbd.SelectedPath)}
}

Answer 1

When doing this in the ISE, it is very helpful in autoloading what it needs.

In the consolehost and VSCode, one needs to provide all that is autoloaded in the ISE instance. Well, at least I've had to.

So, are you sure the code is running?

When running code from the editor, I've had VSCode regularly get very quirky when using run code via F8 (selection) or F5 (all) and or the like. Very long load times, the code outliner hanging for no apparent reason (cause slow down and code not running until it completes), etc.

The fix was disabling all but the PowerShell extension, or saving and running as a script from the Integrated Terminal, or copy and paste the code block into the Integrated terminal, or selecting the code in the editor and then hit F1 and typing 'run selected text in the Active Terminal' ( You can make a key binding for this, I use shift+r)...

... for it to run. Even this funkiness happens, meaning, it can sometimes take a while to start.

#keybindings.json

{
    "key": "shift+r",
    "command": "workbench.action.terminal.runSelectedText"
}

Also, VSCode really does not like aliases. It will mark them as an error in your code until you fix them. It even offers to fix them for you and has an Expand all Alias option and even the ISE has an addon to do this. Aliases are fine for interactive stuff but really should never be used in scripts. Even as per Microsoft.

• Best Practices for aliaes Best Practice for Using Aliases in PowerShell Scripts https://devblogs.microsoft.com/scripting/best-practice-for-using-aliases-in-powershell-scripts https://devblogs.microsoft.com/scripting/using-powershell-aliases-best-practices

 Why worry about aliases in the first place? What is the big deal about using aliases anyway? If they make the code easier to type, what is the harm in using them in scripts? There are two things at work when it comes to a script. The first is that no alias is guaranteed to exist—even aliases that are created by Windows PowerShell.

Lastly, one needs to remember to force topmost when calling UX/UI which needs to have focus.

For Example:

# Load UX/UI resources
Add-Type -AssemblyName  System.Drawing,
                        PresentationCore,
                        PresentationFramework,
                        System.Windows.Forms,
                        microsoft.VisualBasic
[System.Windows.Forms.Application]::EnableVisualStyles()
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::
SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

$FolderBrowser = New-Object System.Windows.Forms.FolderBrowserDialog
$FolderBrowser.Description = 'Select the folder containing the data'

# Set focus
$result = $FolderBrowser.ShowDialog((New-Object System.Windows.Forms.Form -Property @{TopMost = $true }))

if ($result -eq [Windows.Forms.DialogResult]::OK){
    $FolderBrowser.SelectedPath
}
else {
    # Other code here
}

Answer 2

Seems it works, it opens in the background, so it is not recognized. Moreover, such Windows forms do not appear in the task bar, therefore, you need to minimize/close all your running applications to see the form. Watchout when working with multiple screens...