Trying to alter value with a method:
$x = 2
Add-Member -InputObject $x -MemberType ScriptMethod -Name "AlterValue" -Value {param ([int]$NewValue) $NewValue; $this = $NewValue}
$x.AlterValue(3)
$x
No error (even with Set-StrictMode -Version Latest), no update either.

$y = 'b'
Add-Member -InputObject $y -MemberType ScriptMethod -Name "AlterValue" -Value {param ([string]$NewValue) $NewValue; $this = $NewValue}
$y.AlterValue('a')
Error: Method invocation failed because [System.String] does not contain a method named 'AlterValue'.
Then trying like this:
$y | Add-Member -MemberType ScriptMethod -Name "AlterValue" -Value {param ([string]$NewValue) $NewValue; $this = $NewValue}
Runs without error, but $y.AlterValue('a') results in the same error as above. Same if I only wanted to implement the simple method $y | Add-Member -MemberType ScriptMethod -Name "Get" -Value {$this}, $y.Get() fails.

Add-Member accepts any crap as -InputObject:
Add-Member -InputObject crap -MemberType ScriptMethod -Name "AlterValue" -Value {param ([int]$NewValue) $NewValue; $this = $NewValue}
Runs without error, even with Set-StrictMode -Version Latest.

I do not have PS Core to test it, but might be the same.

On Windows 10 / Server 2012 / 2016 I can set the "short time format" by using the Get-UICulture and Set-Culture commandlets to the 12 hour format with AM/PM indicators.
However, I can not change it from 12 hour format to 24 hour format. It remains in the 12 hour format - meanwhile there is no problem to set the 24h format from the Settings app in Windows.

(In contrast to that, the LongTimePattern works fine both ways)

Steps to reproduce

(Get-UICulture).DateTimeFormat | Select ShortTimePattern,LongTimePattern | fl
$modCulture = Get-UICulture
($modCulture.DateTimeFormat).ShortTimePattern = "h:mm"
($modCulture.DateTimeFormat).LongTimePattern = "h:mm:ss"
Set-Culture $modCulture

(Get-UICulture).DateTimeFormat | Select ShortTimePattern,LongTimePattern | fl
($modCulture.DateTimeFormat).ShortTimePattern = "HH:mm "
($modCulture.DateTimeFormat).LongTimePattern = "HH:mm:ss"
Set-Culture $modCulture
(Get-UICulture).DateTimeFormat | Select ShortTimePattern,LongTimePattern | fl

Expected behavior

It should change the short time format to 24h format "HH:mm"

Actual behavior

The time format never gets set to 24h format. It remains in the AM/PM 12 hour format.

I am trying to launch the Win10 bluetooth configuration page via PowerShell shortcut.

In a nutshell:

start-process -FilePath "shell:appsFolder\windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel" -ArgumentList "Page=SettingsPageDevices"

does open the device settings, but the argument to navigate to the Bluetooth Devices is not taken.

Background: I exported the tile settings using:
Export-StartLayout -UseDesktopApplicationID -Path m:\layout.xml
That gave me:
<start:SecondaryTile AppUserModelID="windows.immersivecontrolpanelcw5n1h2txyewy!microsoft.windows.immersivecontrolpanel" TileID="SystemSettingsL2_SettingsPageDevices" DisplayName="" Size="2x2" Column="2" Row="0" Arguments="page=SettingsPageDevices" Square71x71LogoUri="ms-appx:///" Square150x150LogoUri="ms-appdata:///local/SettingsTiles/Devices.png" Wide310x150LogoUri="ms-appdata:///local/SettingsTiles/wide.Devices.png" Square310x310LogoUri="ms-appx:///" ShowNameOnSquare150x150Logo="true" ShowNameOnWide310x150Logo="true" BackgroundColor="#00000000" ForegroundText="light" />

When I call the above to start it in the same way, I am not getting to the arguments being applied. I tried many different notation for the args instead of a=b format eg. "--a b", "-a b", "/a b", "/a:b", "a b", "a:b" "a,b", but nothing works, it always ends the call without applying the arguments.

Thanks for any help.

I have a simple win32 console application (example.exe) which just printf's all its arguments. In the windows registry I've set up a file association so that the file extension ".myfile" invokes "example.exe %1".

In a CMD window running .\example.exe file.myfile displays the output in the cmd window. (this is good)
In a CMD window running .\file.myfile invokes example.exe and displays the output in the cmd window. (this is good)

In a Powershell window running .\example.exe file.myfile displays the output in the powershell window. (this is good)
In a powershell window running .\file.myfile opens a new cmd window, in which example.exe is run, and the output is printed. The cmd windows then closes. (this is NOT good). The console application should run inside the powershell window.

The Name and the ProcessName properties of the Get-Process, Stop-Process and Wait-Process CmdLets seems to use the wrong process names compared to the Win32_Process WMI class and other process related tools such as Windows task manager.
Where WMI and task manager lists task names like Notepad.exe or Calculator.exe, Get-Process returns just "Notepad" or "Calculator" and Stop-Process requires me to specify these shortened names too.
I understand that I can get the full name of the executable by specifying the -FileVersionInfo with Get-Process but it still doesn't allow me to search for a process using it's real process name.

Couldn't at least one of the Name/ProcessName output properties list the full name of the process and couldn't the ProcessName input parameter accept both variants?
If not, can you at least add input/output properties that works with the full process name?

I recently did a fresh install of Windows 10 Pro. After some time I recognized that Ctrl-R (back-i-search) did not work anymore. I tried to follow instructions of #350 to resolve the problem. But when I tried to call Get-PSReadLineOption or Install-Module I got errors.

I also tried deleting the whole powershell folder c:\Windows\System32\WindowsPowerShell\v1.0\ and ran sfc /scannow but still ctrl-r is not working.

Environment

```
Windows build number: Microsoft Windows [Version 10.0.18363.592]
Powershell Version (if applicable):
Major Minor Build Revision

5 1 18362 145
```

Steps to reproduce

Install-Module

Expected behavior

cmdlet Install-Module at command pipeline position 1
Supply values for the following parameters:
Name[0]:

Actual behavior

Install-Module : The term 'Install-Module' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1
+ Install-Module
+ ~~~~~~~~~~~~~~

  + CategoryInfo          : ObjectNotFound: (Install-Module:String) [], CommandNotFoundException

  + FullyQualifiedErrorId : CommandNotFoundException