When a parameter definition in cmdlet is of an enum type, the Command Add On just shows a string field instead of a combo box. It will only show a combobox when the parameter has the ValidateSet attribute defined

A sample code to help

Add-Type -TypeDefinition @"
// very simple enum type
public enum SimpleEnumType
{

  Value1,

  Value2,

  Value3

}
"@

function Test-ISEEnum {

param(

    [Parameter(Mandatory=$true)]

    [SimpleEnumType]$WithoutValidateSet,

    [Parameter(Mandatory=$true)]

    [ValidateSet("Value1","Value2")]

    [SimpleEnumType]$WithValidateSet

)

}

In command line tab-key auto completion uses all enum values for both parameters.
ISE command add-on shows a combo box for only $WithValidateSet parameter and provided only the two values defined in the attribute instead of the three defined in the enum

My dayjob revolves mostly around PowerShell. The largest PowerShell project I've worked on has over 50 000 lines of PowerShell code, the second largest has nearly 20 000. As you can imagine, supporting projects that large is simply impossible with PowerShell ISE. The company I work for bought licenses for PowerShell Studio from Sapien, which made working on the projects tolerable.

By far the biggest problem with the projects were exhaustingly numerous runtime errors. This was long before the era of PSScriptAnalyzer and Visual Studio Code.

Even with recent improvements to PowerShell tooling, I still feel like PowerShell is lacking in support of proper projects and prevention of runtime errors.

Now, you might argue projects this large should be moved to C#/F# and Visual Studio. However, PowerShell Studio costs a fraction of what Visual Studio Professional or Enterprise does. Visual Studio also lacks subscription model, buy license once, get updates and new versions as long as the license is valid. The current licensing model is very expensive, so outdated Visual Studio with MSDN license is all I get.

What I really would like to see:
- Official support for PowerShell projects all IDEs could support, introduce a new official file format to contain necessary project data.
- Optional support for variables being immutable by default.
- Support gradual typing. https://en.wikipedia.org/wiki/Gradual_typing
- Support compiling PowerShell script files and modules into dll file. Compilation would catch many runtime errors at compile time, while protecting scripts from accidental or intentional tampering.

It looks like certain windows are screwed up in Windows 10 w.r.t. to it's alt+tab handling.

1. The modal:

a. Open PowerShell ISE
b. Go to Tools | Options...

Now try to alt+tab away from the "Options" window.

The first alt+tab entry is the "main PowerShell ISE" window which if you alt+tab to that, takes you right back into the "Options" window. So it takes 2 alt+tabs to escape from the "Options" window rather than the expected 1 alt+tab.

1. The non-modal "Edit | Find in Script..." suffers from the above problem as well.




2. The modal "Edit | Go To Line..." seems to work fine.

【Cause of the bug】
"inlinescript" is a keyword, but color wrong in ise,color as same as a command.

【bug with powershell version】
ise in win7 + powershell 2.0: not support PSWorkflow.
ise in win7 + powershell 5.0: yes have this bug,tested.
ise in win8 + powershell 3.0: unknown
ise in win8.1 + powershell 4.0: yes have this bug,tested.
ise in win10 10586：yes have this bug,tested.
ise in win2016 tp5 ：yes have this bug,tested.

【test code】
at first let font bigest,then test.
workflow aaa
{

inlinescript #<----color wrong

{

    "bbb"    

}

}

【how to fix】
unknown

【reporter】
By the chinese powershell study & research group. QQ group No. is 183173532

【date】
2016-06-23

In the PowerShell ISE Preview, the "ise" alias should not launch a new instance of the old powershell_ise.exe, it should open the script given to it as an argument in a new tab in the currently-running host ISE process (just the like psEdit function does).

Personally, I prefer to open scripts into new tabs using "ise" instead of "psedit" because it is shorter (and also a habit burned in from years of use). When the new PowerShell ISE is released later this year, please make "ise" an alias for the psEdit function, or a function in its own right, or at least otherwise continue making "ise" open up files in new tabs. When "ise" is run in the console powershell.exe, it should continue to launch a new powershell_ise.exe process and open the targeted script as expected. Thanks!

Function Test-StringDefaultParameter {

Param (

    [String] $Str = [System.Management.Automation.Language.NullString]::Value

)


if ($Null -eq $Str) {

    Write-Host "Str is null"

} else {

    Write-Host "Str is '$Str'"

}

}

When debugging above function (that is just placing a breakpoint in it somewhere in Powershell ISE) then calling 'Test-StringDefaultParameter' without any parameter behaves as expected! (printing out 'Str is null'!).
Not so though, if there is no breakpoint set! Then 'Str is ''' get printed on the console!

This happens (at least) with Powershell 5 on Windows 7 64 bit.

PS C:\Users\peh> Get-Host

Name : Windows PowerShell ISE Host
Version : 5.0.10586.117
InstanceId : 80c61d7e-c680-4f68-8176-84aabf69b1e9
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.Host.ISE.ISEOptions
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace

PS C:\Users\peh> $PsVersionTable

Name Value

PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

When a Write-Error output is used with multiple powershell tabs in the ISE it is automatically posted to the currently active tab regardless of which tab it originated from.

This was tested with the following command:

1..20 | % {if ($ % 2) { start-sleep -s 2; write-output $} else {start-sleep -s 2; write-Error $_}}

And across 3 different tabs in the same ISE.

While it seems useful behaviour to have a script report errors to the currently active tab, it then can cause problems when trying to actually debug those errors when switching back and forth between tabs to check the script and output.