Question ValueFromPipelineByPropertyName et obj differents

sarou écrit:

Pour les switchs, tout ce que je veux c'est indiquer à la fonction si elle doit gérer les droits et la réappropriation ou l'un ou l'autre. Seul $true m'intéresse, je ne traite pas $false.

C'est bien à ça que servent les Switches, à passer à $true une propriété alors que par défaut elle va être considérée comme $false par PS :

[code:1]
function say-hello ([Switch]$poliment)
{
if ($poliment) {\"Bonjour $env:username.\"}
else {\"Salut vieux !\"}
}
[/code:1]

Tu noteras qu'il n'y a pas besoin de préciser $true comme valeur par défaut. Si on ne précise pas le paramètre, il est considéré comme $false, si on le précise, il prend la valeur $true.

L'inverse au sens strict n'est pas possible ($false si le paramètre est précisé mais sans lui indiquer de valeur, $true s'il n'est pas précisé).

Par contre on peut déclarer un paramètre booléen qu'on mettra à $true par défaut, et auquel on peut passer la valeur $false :

[code:1]
function say-hello ([Boolean]$poliment=$true)
{
if ($poliment) {\"Bonjour $env:username.\"}
else {\"Salut vieux !\"}
}
[/code:1]

Dans ce 2e exemple, le salut est poli par défaut. Par contre, contrairement au 1er exemple où le paramètre de type Switch pouvait être précisé tout seul sans avoir à explicitement lui donner la valeur $true ou $false, ici on ne peut plus passer \"-poliment\" en paramètre tout seul. Il faut lui préciser une valeur :

[code:1]
PS> say-hello -poliment $false
Salut vieux !
[/code:1]<br><br>Message édité par: janel, à: 31/01/11 14:54

sarou écrit:

Je pensais que Laurent voulait que je vire mes conditions if :

Non, je pensais que tu connaissais le type switch.
Concernant la déclaration d'un paramètre couplant ValueFromPipeline=$true et ValueFromPipelineByPropertyName=$true, c'est possible , la règle suivante s'applique :

When a parameter is both ByValue and ByPropertyName bound, PowerShell attempts to bind in this order:

Bind ByValue with no type conversion
Bind ByPropertyName with no type conversion
Bind ByValue with type conversion
Bind ByPropertyName with type conversion

Une solution pour ton pb, sans appliquer la règle précédente, (ce sera pour la v2 ) :
[code:1]
Function Repair-Homedir{
# par défaut on manipule des users issus d'AD
[CmdletBinding(DefaultParameterSetName = \&quot;ADUserObject\&quot;«»)]
param(
[parameter(Position=0,Mandatory=$false,ValueFromPipeline=$true,ParameterSetName=\&quot;ADUserObject\&quot;«»)]
$User,
[parameter(Position=1,Mandatory=$false,ValueFromPipelineByPropertyName=$true,ParameterSetName=\&quot;SamAccountName\&quot;«»)]
[Alias('FullName')]
[string]$Name,
[parameter(ParameterSetName=\&quot;SamAccountName\&quot;«»)]
[Switch]$HomeDirectory,
#Les switchs suivant sont membres des deux jeux de paramètres déclarés
[Switch]$Right,
[Switch]$Owner)
begin {
#ipmo module. Pas testé !
}
process {
#Ici on ne sait pas quel paramètre on récupère du pipeline
#dans tous les cas on récupère un objet, $null compris
$CurrentObject=$_
$PsCmdlet.ParameterSetName
switch ($PsCmdlet.ParameterSetName)
{
#Dans le switch $_ correspondant à la valeur recherchée et pas à l'objet courant du pipeline
\&quot;ADUserObject\&quot; { Write-Warning \&quot;$user $($CurrentObject.GetType())\&quot;;Write-Host \&quot;Fonctionnalité 1 ($_)\&quot;; break}
\&quot;SamAccountName\&quot; { Write-Warning \&quot;$name $($CurrentObject.GetType())\&quot;; Write-Host \&quot;Fonctionnalité 2 ($_)\&quot;; break}
}
}
end {
#remove-module. Pas testé !
}
}

#conversion automatique de l'objet en string, qui est égal à FullName
dir |? {!$_.PSIscontainer}|Repair-Homedir
#utilise l'alias FullName (du paramètre Name)
dir |? {!$_.PSIscontainer}|Repair-Homedir -HomeDirectory

#conversion automatique de l'objet en string, qui est égal ici à Type.FullName
Get-Service|select -first 2 |Repair-Homedir
#utilise le membre Name déclaré sur la classe Service
Get-Service|select -first 2 |Repair-Homedir -HomeDirectory
[/code:1]