Question [Convert-Form][V2.0] Migration

Projet migré vers Github

La dernière version réalisée (1.2.1 du 08/2010) est désormais intégrée dans un module autonome.

La nouvelle version est en cours de migration/développement.

Le répertoire TestsWinform contient les fichiers de tests réalisés sous Visual Studio 2010 version Ultimate.

Reste à vérifier si ces projets se chargeront dans une version Express...
Une validation sous VS 2012 est prévue.

Message édité par: Laurent Dardenne, à: 25/08/14 21:07<br><br>Message édité par: Laurent Dardenne, à: 8/04/17 13:09

Une nouvelle version :

Refonte de la gestion des exceptions.
Ajout de deux cas d'analyse du code source C#
Localisation ( FR pour le moment)
Reformatage du code source
Modification des instructions Trap en instruction Throw

Suppression du paramètre -AddInitialize et -STA
Ajout du paramètre -Encoding
Renommage des paramètres -DontLoad -DontShow en -noLoadAssemblies -noShowDialog

Ajout du code des fonctions Win32 (Show-Window, Hide-Window)
Ajout de la fonction Add-Win32FunctionsType
Correction de la fonction New-RessourcesFile<br><br>Message édité par: Laurent Dardenne, à: 31/08/14 20:00

De nombreuses modifications dans le code source, mais pas de nouvelle version pour le moment.

Une recopie d'écran d'une partie des tests. Ici la validation des certains paramètres attendant des noms de chemin:




Le fichier de test Pester associé.<br><br>Message édité par: Laurent Dardenne, à: 19/09/14 20:34

Désormais :
- le paramètre -Destination attend un nom de répertoire.
- On peut manipuler des Path et des LiteralPath
- On peut également manipuler des Destination et des DestinationLiteral
- on aussi peut les combiner.

Ces modifs dont dues au fait que l'on peut nommer les fichiers d'un projet Visual Studio de la sorte :
[code:1]
G:\PS\ConvertForm\TestsWinform\Test21LiteralPath[AG]Naming\Frm[AG].Designer.cs[/code:1]
Malheureusement pour gérer ces cas, il faut du PowerAspirine qui n'est pas disponible en pharmacie

Donc le conseil du jour, tant que faire ce peut, ne proposez pour une fonction qu'un seul paramètre manipulant un chemin et laisser l'utilisateur de votre fonction se charger du reste.
C'est à dire qu'ici la fonction Convert-Form ne devrait gérer que le fichier Designer.cs d'une WinForm et renvoyer une collection de chaîne de caractères.
Ce serait à l'utilisateur de gérer la création du fichier .ps1 associé, via un Out-File par exemple.
Mais pour ce contexte ce n'est pas évident, car une Winform peut être liée à plusieurs fichiers, ceux-ci sont donc à la charge du développeur.

En passant, la gestion des exceptions sous Pester 3.0, c'est comment dire, à pester !
Pester, quel beau métier.

Voici pour finir, sans rentrer dans les détails, ce qu'on doit coder dans une fonction public d'un module pour propager $ErrorAction/$ErrorActionpreference :
[code:1]
$_EA= $null
#correction de bug : ErrorAction est-il renseigné sur la ligne d'appel ?
[void]$PSBoundParameters.TryGetValue('ErrorAction',[REF]$_EA)

if ($_EA -eq $null)
{
#ErrorAction n'est pas renseigné :
# on récupère du contexte de l'appelant, au moins pour Pester,
# la valeur de la variable ErrorActionPreference.
$ErrorActionPreference=$PSCmdlet.SessionState.PSVariable.Get('ErrorActionPreference').Value
}
else
{
#ErrorAction est renseigné :
# on récupère sa valeur.
#Celle-ci remplace localement la valeur de la variable ErrorActionPreference.
$ErrorActionPreference=$_EA
}
[/code:1]
Une fois ceci fait, on peut tester sans pester les appels à Write-Error comme ceci :
[code:1]
Context \&quot;Seconde passe : Erreur sur le verrouillage du fichier .ps1 'FrmTest3Menus.ps1'\&quot; {
It \&quot;fails\&quot; {
{
$ErrorActionPreference='Stop'
Set-LockFile \&quot;$DestinationDirectory\FrmTest3Menus.ps1\&quot;
$ErrorActionPreference='Continue'
} | Should Throw
}
}
[/code:1]
C'est évident !<br><br>Message édité par: Laurent Dardenne, à: 20/09/14 10:16

Une Winform pouvant être utilisé comme AddOn ISE:
[code:1]
$psISE.CurrentPowerShellTab.AddOnsMenu.Submenus.Add('MyDisplayName', {GeneratePrimaryForm},'ALT+F2')
[/code:1]
j'ai ajouté la possibilité de gérer une fonction (-AsFunction), et simplifier la génération des forms secondaires (-Secondary).

J'ai corrigé la gestion des ressources provenant des propriétés d'un projet. On peut donc avoir deux fichiers ressource par form :
[code:1]
FrmMainProperties.resources
FrmMain.resources
[/code:1]
Il reste 3 projets sur 39 qui ne passent pas le test de syntaxe :
[code:1]
TestsWinform\Test5Panel\FrmTest5PanelTableLayoutPanel.Designer.cs
TestsWinform\Test19Localisation\FrmMain.Designer.cs
TestsWinform\Test14BoitesDeDialogue\FrmTest14BoitesDeDialogue.Designer.cs[/code:1]
Le projet Test19Localisation nécessite une étude afin de gérer un troisième fichier ressource, pour la v4 peut être...

Reste à valider le code des 36 projets <br><br>Message édité par: Laurent Dardenne, à: 21/09/14 21:05

Une version stable avec l'aide en Français. La prochaine archive contiendra les démos , dont un addin ISE.

En passant, l'usage du cmdlet Set-PSBreakPoint peut éviter d'écrire du code de debug avant et après chaque transformation d'une ligne csharp :
[code:1]
$setBrkPnt=$true
if ($setBrkPnt -and ($DebugPreference -ne \&quot;SilentlyContinue\&quot;«»))
{
$BPLigneRead=Set-PSBreakpoint -Variable Ligne -Mode Read -Action { Write-Debug \&quot;[R]$Ligne\&quot;}
$BPLigneWrite=Set-PSBreakpoint -Variable Ligne -Mode Write -Action { Write-Debug \&quot;[W]$Ligne\&quot;}
$setBrkPnt=$false
}

#fin de tratiement
if ($DebugPreference -ne \&quot;SilentlyContinue\&quot;«»)
{ $BPLigneRead,$BPLigneWrite | Remove-PSBreakpoint }
[/code:1]
C'est très verbeux et l'inconvénient est qu'on ne connait pas le contexte d'appel, car la variable $PSDebugContext n'est pas renseigné dans la console.