Tim Curwick

My feedback

  1. 28 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick commented  · 

    Implementing the IContentCmdletProvider interface on the registry provider should be considered as a means to gives us improved access to the registry. This may not be a complete solution, but it would allow us to use Get-Content and Set-Content as well as ${HKLM:\SOFTWARE\Microsoft}

  2. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  3. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick commented  · 

    Daniel,

    It isn't exactly what you are looking for, but this syntax works:

    ( "False result", "True result" )[$BoolTest]

    For your example, it would be:

    $x = ( $y.Property2, $y.Property1 )[$someBoolCondition]

    PowerShell converts the boolean to an int32, 1 for $True, 0 for $False, and uses the result to index into the array of choices.

    To use an actual conditional, wrap it in parentheses within the square brackets:

    ( "False result", "True result")[( $A -lt 10 )]

  4. 29 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  5. 81 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    18 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  6. 16 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  4 comments  ·  PowerShell » PowerShell Gallery  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick commented  · 

    I would prefer something as consistent as possible to namespaces in functionality, terminology, and syntax. All existing scripts and modules would be in a default namespace.

    Tim Curwick supported this idea  · 
  7. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  5 comments  ·  PowerShell » Package Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  8. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  9. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  0 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick shared this idea  · 
  10. 21 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  11. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  12. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  13. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » Microsoft.PowerShell.* Modules  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  14. 8 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » Other PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  15. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  6 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick commented  · 

    I do like it.

    $Result = Get-Something
    $Result.Count

    is much better than

    $Result = Get-Something
    If ( $Result -is [array] )
    { $ResultCount = $Result.Count }
    Elseif ( $Result -eq $Null )
    { $ResultCount = 0 }
    Else
    { $ResultCount = 1 }
    $ResultCount

    Tim Curwick commented  · 

    I strongly disagree. This would be a breaking change. We can argue over what property name they should have chosen for this very useful, necessary property, but it does not matter. "Count" is the name that they chose and that we have been using for years, and it can't be changed now.

  16. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  1 comment  ·  PowerShell » Documentation  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  17. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  0 comments  ·  PowerShell » Other PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
  18. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  0 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick shared this idea  · 
  19. 16 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  3 comments  ·  PowerShell » Other PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick supported this idea  · 
    Tim Curwick commented  · 

    This bug appears to be related to the new functionality of Format-Table in which Powershell 5 holds incoming pipeline data for 300 milliseconds before deciding how to format it and write it to the output stream.

    It appears that when certain objects are sent toward the output stream, and PowerShell is implicity calling Format-Table (or the code related to it), the 300 millisecond timeout is not respected. If any additional data goes toward the output stream after 300 milliseconds have passed, PowerShell gets unstuck and behaves normally. But if nothing more is sent toward the output stream after 300 milliseconds, the data that PowerShell is holding on to is stuck until the script finishes.

    This code demonstrates the unexpected behavior.

    Write-Warning "Before"
    Get-Service E* |
    Select Status, Name, DisplayName |
    ForEach { Start-Sleep -Milliseconds 10; $_ }
    Write-Warning "After"
    Start-Sleep -Seconds 5
    Write-Warning "Long after"

    If the delay between objects is increased to 100 milliseconds, bringing the total time between the first and last objects to over the 300 milliseconds threshold, PowerShell behaves normally.

    Write-Warning "Before"
    Get-Service E* |
    Select Status, Name, DisplayName |
    ForEach { Start-Sleep -Milliseconds 100; $_ }
    Write-Warning "After"
    Start-Sleep -Seconds 5
    Write-Warning "Long after"

    Alternatively, if Format-Table is called explicitly, PowerShell behaves normally.

    Write-Warning "Before"
    Get-Service E* |
    Select Status, Name, DisplayName |
    ForEach { Start-Sleep -Milliseconds 10; $_ } |
    Format-Table
    Write-Warning "After"
    Start-Sleep -Seconds 5
    Write-Warning "Long after"

  20. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  1 comment  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Tim Curwick commented  · 

    Maybe functionality in ISE when opening a script to collapse any region that starts with #regionx.
    This could be quite useful, for example, for collapsing all regions to show a top level view of a long script by default. With current behavior, if you collapse everything, when you expand on a region, everything inside of it is still collapsed and you have to click on a lot of things to see it all. With the requested behavior, and entire region and all subregions and other collapsable things would be expanded with a single click.

    Tim Curwick supported this idea  · 
← Previous 1 3

Feedback and Knowledge Base