Question guide de prod comment remplir un doc depuis wmi

Plus d'informations
il y a 14 ans 8 mois #1433 par Lemaire Patrice
Si sa dérange pas je met mon grain de sel ^^

Dan écrit:

pourtant $a.oslanguage est bien un nombre
sais tu expliquer ce probleme?


En fait non, ce n'est pas exactement un nombre.
C'est une structure de type System.UInt32.
Ce qui fait une légère différence ^^.

Essaye par contre d'écrire :

[code:1]
[System.Globalization.CultureInfo]::GetCultureInfo($operatingsystem.OSLanguage.gethashcode()).DisplayName
[/code:1]

Le HashCode lui est bien la clef numérique de l'objet, en principe sa fonctionne ...

Pat<br><br>Message édité par: Spirit, à: 8/01/08 18:52

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 14 ans 8 mois #1439 par daniel soares
Spirit
merci pour l'info ca fonctionne
je pense avoir compris le role du hashcode que je croise regulierement :)

Arnaud
je vais poster un fichier avec resultat dés que possible
j'utilise word 2003

l'utilisation du fichier deja nomé est lié a la facon dont nous travaillons mais je trouve ta solution plus sencée en effet


ce script met plusieures minutes par serveur et semble tres demandeur en ressources (word) sur le poste dans lequel il est executé car il y a une grande difference de temps (du simple au double) entre les machines sur lesquelles je l'ai testé

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 14 ans 8 mois #1448 par daniel soares
voici un resultat d'interrogation
en bleu ce qui est rempli par le script

La pièce jointe gp_nomserveur.zip est absente ou indisponible

Pièces jointes :

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 14 ans 8 mois #1460 par Jacques Barathon
Spirit écrit:

En fait non, ce n'est pas exactement un nombre.
C'est une structure de type System.UInt32.
Ce qui fait une légère différence ^^.


Pas du tout, les objets de type Int32 sont bien des nombres! D'ailleurs, il suffit de forcer le typage de la valeur pour que ça marche, sans avoir à aller chercher le Hash Code:

[System.Globalization.CultureInfo]::GetCultureInfo([int32]$a.OSLanguage)

Ca marche sans préciser [int32] avec la v2 de PowerShell, mais apparemment la v1 a besoin de se faire préciser le type pour une raison que j'ignore...

Janel

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 14 ans 8 mois #1469 par Lemaire Patrice
Pas du tout, pas du tout, je trouve que tu y vas fort …
Bon d’accord je pinaille ^^ mais je me suis sans doute mal exprimé.

Pour moi la notion de « Nombre » (qu’il soit entier ou à virgule flottante, signé ou non) c’est avant tout une façon très précise de coder son contenu en mémoire. Par exemple, dans un nombre entier signé le signe est stocké dans le bit de poids fort (0=+,1=-). Les premières versions des langages de développement utilisaient directement ce codage pour des variables de types de base, ou primaire.
Aujourd’hui cette « Notion » à été enveloppée dans ce que l’on appelle des objets. Voilà pourquoi, pour moi, INT32 ou UINT32 ne sont pas des nombres mais bien des objets qui représentent des nombres, ce qui n’est assurément pas là même chose.

Au vue de ce que tu décris comme différence entre la V1 et la V2 de PowerShell, je dirais que la V1 avait un Bug sur la méthode/propriété par défaut de l’objet Int32, puisqu’elle retournait un objet de type String, au lieu d’un objet de type INT32. Ils l’ont visiblement corrigé en V2.

Remarque au passage, la propriété « OSLanguage » de Win32_operatingsystem est de type UINT32, soit de 0 à +4 294 967 295, alors que la méthode « GetCultureInfo » attend un type INT32, soit de -2 147 483 648 à +2 147 483 647. Oui je sais j’exagère ^^.

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 14 ans 8 mois #1470 par Jacques Barathon
Bon, c'est vrai que tu exagères un peu, mais en même temps tu as raison de faire une distinction entre Int32 et UInt32.

Cela dit, pour ce qui est du bug de la v1, il faudra que je refasse des tests car maintenant je retrouve la même erreur avec la v2 alors que ça marchait quand j'ai posté mon message sur ce même fil... Bizarre!

A priori, le problème ne vient pas de la façon dont PowerShell traite les Int32 mais plutôt de la façon dont la méthode GetCultureInfo() traite ses paramètres: cette méthode a plusieurs syntaxes possibles, dont une qui accepte une String en paramètre. Or, de toute évidence cette méthode ne sait pas reconnaître un objet de type UInt32 comme étant potentiellement un Int32, donc elle le prend pour une String. Et comme la valeur passée ne correspond à aucun nom de culture connu, elle génère une erreur.

Quand on passe un UInt32 à une méthode qui attend un Int32, ça passe sans problème. Voir par exemple les méthodes statiques de la classe System.Math, elles prennent un UInt32 sans sourciller.

Il faudrait vérifier avec d'autres méthodes qui peuvent accepter soit un paramètre de type String soit un paramètre de type Int32 pour voir s'il s'agit d'un problème limité à GetCultureInfo() ou si c'est au niveau de PowerShell (ou du Framework) que la conversion se fait mal.

Janel

Connexion ou Créer un compte pour participer à la conversation.

Temps de génération de la page : 0.122 secondes
Propulsé par Kunena