Invoke-Item with Jobs

[StillLearning]

"Many ways to do this but you cannot open explorer from the job."

It does open, it's just slow.

I figured out how to make it as fast as the ISE

Code: [Select all] [Expand/Collapse] [Download] (Untitled.ps1)

1. if (!(Test-path "$folder\$user"))
2.                 {
3.                    
4.                 }
5.                 else
6.                 {
7.                     Invoke-Item $folder\$user
8.                 }

[jvierra]

If you open from the workflow you will not be able to open only the first one. You will not be able to stop the workflow because it is running many loops in parallel and they cannot be stopped.

Return the path from the workflow and run the Invoke-Item in the update script.

[StillLearning]

If you open from the workflow you will not be able to open only the first one. You will not be able to stop the workflow because it is running many loops in parallel and they cannot be stopped.

Return the path from the workflow and run the Invoke-Item in the update script.

I see where you're going with this. Now I've discovered a new problem. If I literally declare the user, it works.
If I try a variable, it has no idea the user so if opens up every folder :/
$user = $textbox1.Text.trim()

Or if it's not too much of a hassle, make an example of how you would handle this whole situation

[StillLearning]

I was able to do this with very good results.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.ps1)

1. $folders = get-content \\server\Scripts\servers.txt
2.   $user = $UserResults
3.   $wshell = New-Object -ComObject Wscript.Shell
4.   $wshell.Popup("Looking for Users Folder", 0, "Folder Finder")
5.   foreach ($folder in $folders)
6.   {
7.     if (!(Test-path "$folder\$user"))
8.     {
9.       [System.Windows.Forms.Application]::DoEvents()
10.     }
11.     else
12.     {
13.       Invoke-Item $folder\$user
14.       break
15.     }
16.   }