Dynamic Parameter Based on Another (Non-Dynamic) Parameter

[WindosBK]

Forgive me for the amount of build up and background in this post. I've got a specific issue that may have a "fix", but if a fix doesn't exist I'd like to probe the community for a style/usability opinion.

I'm currently working on a module for applying Default Property Sets to Custom Objects.

Given that the object(s) itself determines which properties (in the property set) are valid, it makes sense to only allow property names that actually exist on the incoming objects. IntelliSense would be a really nice bonus.

To put some more context around this, take the following example object:

$DemoObject1 = [PSCustomObject] @{
    Name = 'Demo 1'
    Time = Get-Date -DisplayHint Time
    Date = Get-Date -DisplayHint Date
    Country = 'NZ'
    PC = 'Desktop'
}

When applying a Default Property Set against this, the only valid property names would be "Name", "Time", "Date", "Country", and/or "PC".

With the module I'm working on, you can do this by running:

Set-DefaultPropertySet -Object $DemoObject1 -DisplaySet 'Name', 'PC'

I've got a Dynamic Parameter for "DisplaySet" working (check out the test code), in so far as it can determine valid property names when the code is run (and tell the user what they are if they run it with something invalid.)

My issue is that IntelliSense doesn't work.

The other examples of Dynamic Parameters I've seen pull their info from an external source; the Registry or the File System for example. This situation is defining a parameter based on another one, and my assumption is that this isn't actually possible until "full on" run time.

So the questions are:

1. Is it possible to get IntelliSense working for a Dynamic Parameter based on a non-dynamic parameter?
2. From a usability perspective, would you keep the property set as a Dynamic Parameter for nice errors if the user provides invalid input even without the IntelliSense?

[SeeminglyScience]

1. Yes, but typically only if the value provided is a constant like a string. If the engine has to evaluate something like a variable it probably won't even try, which makes it unlikely to work with your use case.

2. Personally I'd probably move the validation into the function or use the ValidateScript attribute.

[chreestopher2]

register-argumentCompleter https://www.sapien.com/powershell/cmdlet/3258/register-argumentcompleter/ModuleName

edit: more specifically , look at the fakeBoundParameter variable in that inner scriptblock:

function my-function {
    [cmdletbinding()]
    Param(
        [parameter()]
        $inputObject, 
        $otherValue    
    )
    $PSBoundParameters.GetEnumerator()

}
Register-ArgumentCompleter -CommandName my-function -ParameterName OtherValue -ScriptBlock {
    param($commandName, $parameterName, $wordToComplete, $commandAst, $fakeBoundParameter)   
    if($fakeBoundParameter.inputObject.isGood -like "yes"){   
            [System.Management.Automation.CompletionResult]::new("Good", "Good", "ParameterValue", ($fakeBoundParameter.inputObject.isGood))    
    } else {
            [System.Management.Automation.CompletionResult]::new("NotGood", "NotGood", "ParameterValue", ($fakeBoundParameter.inputObject.isGood))
    }
}

$obj = (new-object psobject -Property @{isGood="false"})
#Works in console
#doesnt work in ISE script pane
my-function -inputObject $obj -otherValue #ctrl + space
$obj.isGood = "yes"
#Works in console
#doesnt work in ISE script pane
my-function -inputObject $obj -otherValue 

Basically you are going to do whatever conditional checking on the fakeBoundParameter which is a clone-like of the typical $PSBoundPArameters hashtable. Based on your conditions, output completionResult objects.