2017-06-06 1 views
1

Ich habe ein PowerShell-Skript mit einer WPF-GUI, mit der Benutzer Werte eingeben und aus Dropdown-Listen auswählen können. Es funktioniert gut, aber einige Benutzer möchten es umgehen und das Skript manuell ausführen (geben Sie ihre eigenen Werte direkt in das Skript ein).Boolesches Flag zum Anzeigen oder Ignorieren der PowerShell-GUI

Gerade jetzt ist die Struktur:

#A bunch of XML and PowerShell that generates the GUI 

$WPFbutton.Add_Click({ 

#Variables that get populated by the GUI 

#The rest of the script 

}) 

Ich möchte noch etwas hinzufügen:

$UseGUI = $true

an der Spitze des Skripts, das sie auf false ändern kann, was das verursacht Skript, um die XML- und Schaltflächenklickzeile zu ignorieren.

Ich dachte, ich könnte die XML-Sachen in einer if-Anweisung basierend auf $UseGUI umgeben, aber das hilft nicht mit dem Button-Klick-Teil.

Eine Sache, die ich weiß funktionieren würde Kopieren und Einfügen das gesamte Skript auf eine andere if-Anweisung basierend auf $UseGUI. Das Problem dort ist, würde die Skriptgröße verdoppeln, und es ist schon 2000 Zeilen.

+0

Sie versuchen, optional params hinzufügen sollten, und dann prüfen, ob sie null sind Bevor Sie mit der GUI auffordern, müssen Sie jedoch einen guten Teil Ihres Codes aus den Sounds neu schreiben. – ConnorLSW

Antwort

1

Eine Idee wäre, eine Funktion und die Parameter zu verwenden, um festzustellen, ob die Person, die das Skript will die GUI verwenden oder hat die richtigen Informationen selbst geliefert:

param 
(
    [Parameter(ParameterSetName = 'Interface', 
       Mandatory = $true, 
       Position = 0)] 
    [switch] 
    $UseGUI, 

    [Parameter(ParameterSetName = 'CommandLine', 
       Mandatory = $true, 
       Position = 0)] 
    [ValidateNotNullOrEmpty()] 
    [string] 
    $Person 
) 

function SayHelloTo ($User) 
{ 
    Write-Output "Hello $User" 
} 

if ($UseGUI) 
{ 
    #A bunch of XML and PowerShell that generates the GUI 

    $WPFbutton.Add_Click({ 

     #Variables that get populated by the GUI 

     #The rest of the script 

     $variable = "jdope" 

     SayHello -User $variable 

    }) 
} 
else 
{ 
    SayHello -User $Person 
} 

Die Parametersätze werden das Skript verhindern mit beiden Optionen aufgerufen werden, wenn Sie überprüfen, ob UseGUI ist $True Sie wissen, um die GUI anzuzeigen (und erhalten Sie die Eingabe zum Aufruf der Funktion) oder rufen Sie die Funktion mit der Eingabe.

Um das GUI Aufruf das Skript mit -UseGUI

.\MyPowerShellWpfScript -UseGUI 

Zur Versorgung der Person Informationen und umgehen die GUI Verwendung

verwenden
.\MyPowerShellWpfScript -Person "jdope" 
+1

Ich mag den Ansatz im Prinzip, aber bitte, bitte benutze 'Write-Host' nicht, es sei denn, es gibt einen guten Grund dafür (und es gibt wenige). Warum sollte '-UseGUI' _pipeline_ input unterstützen? Wenn überhaupt, sollte es "-Person" sein, obwohl Sie in beiden Fällen einen 'Prozess'-Block benötigen würden. Von der Abteilung "Quibbles": _interface_ ist nicht dasselbe wie _interactive_. – mklement0

+0

@ mklement0 Was ist falsch mit Write-Host? Ich benutze es ziemlich viel für die Ausgabe, um den Status des Skripts zu geben. – jdope

+1

Die Gefahr besteht darin, dass Anfänger daran denken könnten, dass 'Write-Host' die Art der Ausgabe von _data_ in PowerShell ist (analog zu' echo' in traditionellen Shells), während __ der (Erfolgs-) Ausgabestrom _beitet. Diese Verwirrung ist sehr häufig und, ich denke, es lohnt sich zu vermeiden. – mklement0

Verwandte Themen