GUI w skryptach – porównanie
Zadanie
zadanie jest proste – napisać GUI, które pozwoli wyłączyć maszynę w Azure z opcją force. tego normalnie z interfejsu zrobić się nie da, a operacja potrzebna. chodzi o przeniesienie zadania z 2giej czy 3ciej linii wsparcia do 1szej, czyli nie ma opcji na jakąkolwiek linię poleceń. musi być GUI.
poniżej dwa skrypty, które realizują to samo zadanie. jeden napisany w tym co PS daje [z małym wyjątkiem], drugi w Formsach. przykład ma posłużyć do porównania tych metod i pozwolić się zastanowić jakie są ‘za’ i ‘przeciw’ dla obu.
(prawie) natywny PowerShell
pełny skrypt można pobrać z GitHuba, poniżej omówienie fragmentów.
założeniem tej wersji jest szybkość działania i uniwersalność. nie korzystam póki co z wersji PS Core ale na pewno korzystanie z biblioteki forms nie będzie możliwe. dla Core można korzystać z XAML UI, którego również jeszcze nie testowałem. jak już pisałem – jedną z bolączek pisania skryptów z GUI jest już sam dobór bibliotek i decyzja ‘gdzie ten skrypt będzie uruchamiany i przez kogo’ /:
dla tego ‘natywne’ skrypty zachowują lepszą kompatybilność i uniwersalność.
niestety natywnych kontrolek jest niezmiernie mało. najważniejszą jest out-GridView, które umożliwia wyświetlenie listy lub obiektów w postaci interaktywnej tabeli, pozwalając na sortowanie, filtrowanie etc. pozwala również na wybranie pojedynczego lub wielu elementów – czyli może być przydatny również wtedy, kiedy chcemy pozwolić użytkownikowi wybrać obiektów do dalszego przetworzenia. i choć daje wiele możliwości, to równocześnie bardzo niewielką kontrolę.
fragment kodu do którego się odwołuję to:
function select-RG {
param(
$RGList
)
write-host -ForegroundColor Yellow "Select Resource Group VM resides on"
$RG=$RGList|out-gridview -title 'Select Resource Group' -OutputMode Single
if([string]::isNullOrEmpty($RG)) {
write-host 'cancelled by user. quitting' -foreground Yellow
exit -1
}
write-host "$($RG.ResourceGroupName) chosen. reading VMs..."
return $RG.ResourceGroupName
}
w szczególności linia pokazująca listę odczytanych Resource Groups w postaci interaktywnej. Out-GridView ‘daje-to-co-daje’ czyli nie da się kontrolować wyglądu okna. to co możemy zrobić to:
- title: ustawić tytuł okna. ponieważ nie jest to coś, co rzuca się specjalnie w oczy, staram się poprzedzać to dodatkowo odpowiednim komunikatem na ekranie. zwiększy to prawdopodobieństwo, że użytkownik tego nie przegapi i będzie widział po co w ogóle jakieś okno mu wyskaqje na ekran.
- OutputMode: przyjmuje wartości ‘single’ lub ‘multiple’ dzięki czemu możemy kontrolować czy oczekujemy pojedynczego wyniku czy listy. np. jeśli piszemy skrypt, który usuwa pliki – chcemy mieć możliwość wybrania od razu wielu. tutaj użyte jest ‘single’ co bloqje opcję multi-choice. dodatkowo ten parametr *zastępuje* passthru.
- PassThru: to starsza wersja, nie jestem pewien w której wersji pojawiło się OutputMode… w każdym razie sam ‘ogv’ [bo taki ma alias] po prostu wyświetla. można się pobawić i zamknąć. tyle. natomiast dodanie opcji PassThru [lub użycie OutputMode] spowoduje dodanie guzika wyboru ‘OK’, po wybraniu którego wybrane elementy zostaną przesłane jako wyniki [pipelined].
siła tkwi w prostocie. chwilę później jednak można zobaczyć:
do {
#choose RG
$ResourceGroupName=select-RG -RGList $RGsInThisSub
$VMlist=get-VMList -RGname $ResourceGroupName
if([string]::isNullOrEmpty($VMlist)) {
write-host "This Resource Group do not contain any VMs. Do you want to select another RG?"
switch (
[System.Windows.Forms.MessageBox]::show($this,"Choose another Resource Group?",'CONFIRM','OKCancel')
) {
'OK' {
#do nothing - VMList is null which will trigger loop
}
'Cancel' {
Write-Host -ForegroundColor Yellow "operation cancelled by the user. quitting."
exit -1
}
}
}
} while( [string]::isNullOrEmpty($VMlist) )
czemu nagle pojawia się Forms? to niestety sqcha twórców PowerShell – o ile WScript dysponował prostym okienkiem OK/Cancel, o ile jest OGV w PS… o tyle nie ma takiego prostego okienka OK/Cancel w PS.
co ciekawe, można takie okienko wyświetlić bez Forms! w taki sposób:
Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::show("Choose another Resource Group?",'CONFIRM','OKCancel')
pomimo, że wyglądają bardzo podobnie, i dają niemal ten sam efekt, pod spodem wydarzają się trochę inne rzeczy. jeden jest częścią PresentationFramework drugi Forms, mają inne konstruktory. lepiej używać Formsowego z dwóch powodów:
- zazwyczaj to nie będzie jedyny element GUI, więc jeśli importujesz biblioteki .NET, lepiej już wybrać tą bardziej rozbudowaną w tym kierunq
- wersja z PF nie pozwala w konstruktorze na zdefiniowanie okna nadrzędnego – magiczne ‘$this’ na pierwszej pozycji show($this,”Choose another Resource Group?”,’CONFIRM’,’OKCancel’) – a w efekcie takie okienko często lądowało pod spodem czegoś aktywnego.
a co z readKey?!
jak już coś pisaliście co wymaga interakcji, powinniście zadać pytanie – czemu nie użyć readKey? natywne, nie wymaga importu bibliotek, szybsze … i tak dalej.
zgoda. ale celem nadrzędnym jest wygoda endusera i założenie, że nie jest bystrym inżynierem (; kiedy zrobiłem readKey, a skrypt miał mieć GUI, sam łapałem się na tym, że czekałem i czekałem… aż zorientowałem się, że to skrypt czeka na mnie, a nie odwrotnie. załamanie logiki – tutaj interfejs a tu linia poleceń – jest bardzo złym podejściem. albo decydujemy się robić skrypt tak, albo inaczej – ale musi być spójnie. inaczej ani nie jest łatwy w użyciu ani prosty w strukturze.
readKey to nie GUI tylko metoda na interakcję bez GUI.
wersja Forms
całość do pobrania z GitHub . kilka uwag n00ba dotyczących pisania PS+Forms.
pierwszą rzeczą jaka rzuca się oczy to narzut ilości kodu. do wykonania mamy jedno polecenie (jedna linijka). w wersji opisywanej wcześniej wyszło 126 linii kodu, tutaj mamy już prawie 19o. jasne się staje że podstawowym problemem będzie możliwy bałagan wynikający z samej ilości. dla tego części dotyczące rysowania samego interfejsu warto oddzielić od reszty. niektórzy decydują się na utworzenie projektu, w ramach którego jest kilka oddzielnych pliqw, i definicje interfejsu wyrzuca się do takiego oddzielnego pliq. spoko, ale ze względu na spójność, przy takich małych toolach wolę trzymać wszystko w pojedynczym pliq. łatwiej go przesłać do niedoświadczonych użytkowników, wytłumaczyć że to taki plik i już, niż kazać tworzyć jakąś strukturę, czy martwić się, że ktoś kawałek usunął czy nie skopiował. ale to oczywiście kwestia wyboru – ważne, żeby sobie oczyścić kod i możliwie mocno oddzielić logikę od definicji.
nie jest to oczywiście do końca możliwe, bo tak, jak opisywałem poprzednio, logika jest de facto związana z interfejsem – trigger-action. klikniemy guzik to uruchomi się jakiś kawałek. całą sekwencyjność szlag trafia.
ja póki co przyjąłem metodę tworzenia regionów – widać znaczniki #region i #endregion które dzielą skrypt na bloki – tutaj 3 bloki – interfejs, akcje interfejsu i cała reszta. zaleta jest taka, że większość edytorów rozpoznaje ten znacznik i pozwala zwinąć tą część kodu żeby nie pasqdziła widoq.
na koniec
niewątpliwie pisanie skryptów z GUI jest dużo trudniejsze i dużo bardziej czasochłonne. tak, jak przy zwykłym skrypcie 6o-8o% czasu to praca nad logiką działania, tak tutaj, ok. 9o% czasu zjadło mi badanie reguł interakcji między poszczególnymi elementami. ok, uczę się więc potem będzie łatwiej, ale nawet przy tak banalnym skrypciq sprawdzenie czy odpowiednio wyczyszczą się wartości konkretnych kontrolek, czy finalnie ustawiona/przeczytana zmienna jest prawidłowa, czy może pozostało coś z klikania usera, czy guziki są aktywne kiedy trzeba, do tego jak to zoptymalizować, że nie ładowało w kółko po pół minuty…
do tego commandlety Az są… hmm.. nie działają zbyt dobrze q: connect-AzAccount się regularnie [niedeterministycznie] zawiesza po zabiciu okna logowania [cancel], zawiesza się dużo bardziej w Vistual Studio Code, a get-AzContex nie implementuje prawidłowo ErrorAction SilentlyContinue…. żeby tak podać najważniejsze. ogólnie to dość trudna biblioteka do współpracy, bez względu na GUI.
eN.
filtrowanie po wartości
proste, jasne i przyjemne… i łatwo znaleźć na
setkachtysiącach stron…dla tego inne pytanie – a jak przefiltrować po wartościach wszystkich parametrów? np. “pokaż wszystkie parametry obiektu, które mają ‘name’ w nazwie”, albo “pokaż wszystkie wartości parametrów, które zawierają ‘abc'”. tego już tak łatwo zrobić się nie da. to będzie nieco nieprzyjemna przejażdżka, bo wymaga rozebrania obiektu na kawałki – czyli tracimy automatykę PS, która tak ślicznie pomaga w ‘normalnych’ zapytaniach, i grzebiemy we flakach.
aby osiągnąć cel trzeba skorzystać z ukrytego parametru ‘psobject’, który pokazuje wnętrzności obiektu. dodatkowo sprawę kompliqje fakt, że wyjście jest często tablicą obiektów a nie pojedynczym obiektem. pobawmy się ‘get-service’ i zrealizujmy takie zadania:
w pierwszej kolejności zobaczmy jak taki obiekt wygląda wewnątrz. najpierw klasycznie…:
PS C:\_scriptZ> Get-Service|gm TypeName: System.ServiceProcess.ServiceController Name MemberType Definition ---- ---------- ---------- Name AliasProperty Name = ServiceName RequiredServices AliasProperty RequiredServices = ServicesDependedOn Disposed Event System.EventHandler Disposed(System.Object, System.EventArgs) Close Method void Close() Continue Method void Continue() CreateObjRef Method System.Runtime.Remoting.ObjRef CreateObjRef(type requestedType) Dispose Method void Dispose(), void IDisposable.Dispose() Equals Method bool Equals(System.Object obj) ExecuteCommand Method void ExecuteCommand(int command) GetHashCode Method int GetHashCode() GetLifetimeService Method System.Object GetLifetimeService() GetType Method type GetType() InitializeLifetimeService Method System.Object InitializeLifetimeService() Pause Method void Pause() Refresh Method void Refresh() Start Method void Start(), void Start(string[] args) Stop Method void Stop() WaitForStatus Method void WaitForStatus(System.ServiceProcess.ServiceControllerStatus desiredStat... CanPauseAndContinue Property bool CanPauseAndContinue {get;} CanShutdown Property bool CanShutdown {get;} CanStop Property bool CanStop {get;} Container Property System.ComponentModel.IContainer Container {get;} DependentServices Property System.ServiceProcess.ServiceController[] DependentServices {get;} DisplayName Property string DisplayName {get;set;} MachineName Property string MachineName {get;set;} ServiceHandle Property System.Runtime.InteropServices.SafeHandle ServiceHandle {get;} ServiceName Property string ServiceName {get;set;} ServicesDependedOn Property System.ServiceProcess.ServiceController[] ServicesDependedOn {get;} ServiceType Property System.ServiceProcess.ServiceType ServiceType {get;} Site Property System.ComponentModel.ISite Site {get;set;} StartType Property System.ServiceProcess.ServiceStartMode StartType {get;} Status Property System.ServiceProcess.ServiceControllerStatus Status {get;} ToString ScriptMethod System.Object ToString();a potem… od środka:
PS C:\_scriptZ> (get-service).psobject Members : {Count = Length, int Length {get;}, long LongLength {get;}, int Rank {get;}...} Properties : {Count = Length, int Length {get;}, long LongLength {get;}, int Rank {get;}...} Methods : {void Set(int , System.Object ), System.Object&, mscorlib, Version=4.0.0.0, Culture=neutral, Publ icKeyToken=b77a5c561934e089 Address(int ), System.Object Get(int ), System.Object GetValue(Params int[] indices), System.Object GetValue(int index), System.Object GetValue(int index1, int index2 ), System.Object GetValue(int index1, int index2, int index3), System.Object GetValue(long index) , System.Object GetValue(long index1, long index2), System.Object GetValue(long index1, long inde x2, long index3), System.Object GetValue(Params long[] indices)...} ImmediateBaseObject : {aciseagent, AdobeARMservice, AdobeFlashPlayerUpdateSvc, agiptd...} BaseObject : {aciseagent, AdobeARMservice, AdobeFlashPlayerUpdateSvc, agiptd...} TypeNames : {System.Object[], System.Array, System.Object}nas będą interesować ‘properties’, których nazwy zawierają ‘name’. nie będę się bawił w step-by-step, myślę, że taki początek wystarczy, a całą resztę trzeba po prostu usiąść i się pobawić. mamy podstawy więc teraz trzeba po PowerShellowemu zapisać zadanie “wyświetl wszystkie usługi (obiekty), następnie dla każdej usługi przefiltruj te parametry, który mają w nazwie ‘name’ a następnie wyświetl tylko nazwę i wartość”. po takim zapisie to już bułka z masłem:
Get-Service|%{$_.psobject.properties|? name -match 'name'}|ft name,valuea teraz drugie zadanie – i tu robi się na prawdę pasqdnie, bo wartości mogą być różnych typów i też są obiektami. ponadto samo ‘property, value’ będzie bezużyteczne bez dodatkowej informacji – nazwy usługi dla której je znaleźliśmy. poniżej rozwiązanie, zachęcam do zrozumienia – czyli samodzielnych testów:
get-service|%{$sn=$_.name;$_.psobject.members|?{$_.membertype -eq 'property' -and $_.value -eq $true}}|select @{N='ServiceName';E={$sn}},name,valueżeby nie było za łatwo… i tego nie potrafię wyjaśnić – z jakiegoś powodu ‘Stopped’ jest traktowany jako $true. fragment wyjścia:
… ale już nie chce mi się zagłębiać dalej.
sztuka dla sztuki? niekoniecznie. często trafiam na scenariusz, prostszy niż zaprezentowane, gdzie dostaję obiekt o dużej liczbie parametrów – np. obiekty EXO – i chcę sprawdzić czy gdzieś nie siedzi jakaś wartość, przy czym nie mam pojęcia jak może nazywać się parametr. o ile w ogóle istnienie. np. wyświetlmy wszystkie URI jakie są skonfigurowane dla grupy o365:
to tak w ramach przygotowań do ShareCon365 (; zapraszam na moją sesję!
PS. aahhh… jeśli ktoś czytał z uwagą, to powinien zadać pytanie – “a jakie jeszcze ukryte parametry mają obiekty?“. i jeśli ktoś takie pytanie by zadał, otrzymałby zapewne odpowiedź: “<your-command>|gm -force”
eN.