Portabilité des VIs sur différentes plates-formes

Aide LabVIEW 2014

Date d'édition : June 2014

Numéro de référence : 371361L-0114

»Afficher les infos sur le produit
Télécharger l'aide (Windows uniquement)

Parmi les problèmes de portabilité, il faut noter des différences de noms de fichiers, de caractères séparateurs, de résolutions et de polices, un risque de chevauchement des étiquettes et des différences de format des images.

VIs portables et VIs non portables

Les VIs sont portables sur toutes les plates-formes qui exécutent LabVIEW à partir du moment où les versions de LabVIEW sont identiques. Les VIs qui contiennent des fonctionnalités spécifiques à une plate-forme, comme .NET ou ActiveX, ne sont pas portables. Toute tentative de port rendrait ce type de VI non exécutable.

LabVIEW utilise le même format de fichier sur toutes les plates-formes.

Lorsque vous ouvrez le VI sur la nouvelle plate-forme, LabVIEW détecte que le VI provient d'une autre plate-forme et recompile les instructions correctes pour le processeur utilisé. Si vous transférez les VIs sur un disque formaté pour une autre plate-forme, il vous faudra peut-être un programme utilitaire, comme Apple File Exchange sur Macintosh, pour lire le disque.

Les VIs suivants ne sont pas portables :

  • Les VIs distribués dans le répertoire vi.lib — Chaque distribution de LabVIEW contient son propre répertoire vi.lib. Ne transférez pas les VIs du répertoire vi.lib d'une plate-forme à une autre.
  • Les VIs de compatibilité — LabVIEW utilise des VIs de compatibilité dans le cas où vous avez créé des VIs dans des versions antérieures de LabVIEW et que vous voulez les ouvrir dans une version plus récente. Les VIs de compatibilité émule les fonctionnalités des versions précédentes de LabVIEW. Le fait de porter ces VIs les brise car ils appellent des bibliothèques partagées qui sont spécifiques à une plate-forme.
  • Les VIs qui contiennent la fonction Appeler une fonction d'une DLL — Toute tentative de port rendrait ces VIs non exécutables, à moins qu'ils ne trouvent une bibliothèque du même nom que celle référencée dans Appeler une fonction d'une DLL.
  • Les VIs de communication spécifiques à une plate-forme, comme les fonctions .NET ou ActiveX sous Windows et les VIs AppleEvents sous Mac OS X.
  • Les fonctions VISA Peek et VISA Poke.

Différences de noms de fichiers

Pour faciliter le port entre plates-formes, soyez attentif au nom de fichier. Les noms de fichiers Windows, OS X et Linux peuvent comporter 255 caractères, extension .vi comprise. Évitez d'utiliser des caractères dans un nom de fichier qui ne sont pas valides sur une autre plate-forme. Le deux-points (:) n'est pas valide sous OS X, la barre oblique (/) n'est pas valide sous Linux et les caractères suivants ne sont pas valides sous Windows : \, /, :, *, ?, ", <, > et |.

Pour éviter toute complication, enregistrez les VIs avec des noms valides sur toutes les plates-formes ou enregistrez-les dans une LLB. Les noms de LLBs doivent se conformer aux limites de chaque plate-forme, mais les VIs dans les LLBs peuvent avoir des noms comportant jusqu'à 255 caractères, quelle que soit la plate-forme. Les LLBs représentent donc le format le plus pratique pour le transfert de VIs puisqu'elles éliminent en grande partie la dépendance au système de fichiers.

Les noms de fichiers ne sont sensibles à la casse que sous Linux. Si vous faites référence à un VI en le désignant par son nom, mettez-le toujours en majuscules.

Différences de caractères séparateurs

Si vous développez un VI pour l'utiliser sur d'autres plates-formes, n'utilisez pas les caractères séparateurs de chemin spécifiques à une plate-forme \ , / , : dans vos noms de fichiers. Évitez d'utiliser des caractères spéciaux dans les noms de fichiers car différents systèmes de fichiers peuvent les interpréter différemment. Par exemple, sous Linux, les fichiers cachés commencent par un point.

Différences de résolution et de police

Les polices de caractères peuvent varier d'une plate-forme à une autre. Après avoir porté un VI, sélectionnez d'autres polices pour obtenir un affichage attrayant. Lorsque vous développez des VIs, n'oubliez pas qu'il y a trois polices pour lesquelles la correspondance est optimale d'une plate-forme à l'autre : la police de l'application, la police du système et la police des boîtes de dialogue.

Par défaut, LabVIEW utilise la police de l'application dans la palette Commandes, la palette Fonctions, l'aide contextuelle et les info-bulles.

  • (Windows 7/Vista) Par défaut, LabVIEW utilise Segoe UI.
  • (Windows XP) LabVIEW utilise la police que Windows utilise dans l'Explorateur Windows pour les noms de fichiers. En général, la version anglaise (US) de Windows utilise Tahoma. La taille de la police dépend des paramètres du driver vidéo car s'il s'agit d'un driver vidéo haute résolution, vous pouvez spécifier l'utilisation de petites polices ou de grandes polices. Par souci de cohérence, utilisez Small Fonts et les paramètres standard de Windows.
  • (OS X) Par défaut, LabVIEW utilise Lucida Grande.
  • (Linux) Par défaut, LabVIEW utilise la police Helvetica.

Par défaut, LabVIEW utilise la police du système pour les menus.

  • (Windows 7/Vista) Par défaut, LabVIEW utilise Segoe UI.
  • (Windows XP) LabVIEW utilise la même police que la police de l'application, mais sa taille peut être différente.
  • (OS X) Par défaut, LabVIEW utilise Lucida Grande.
  • (Linux) Par défaut, LabVIEW utilise la police Helvetica.

Par défaut, LabVIEW utilise la police des boîtes de dialogue pour le texte des boîtes de dialogue et des commandes système.

  • (Windows 7/Vista) Par défaut, LabVIEW utilise Segoe UI.
  • (Windows XP) LabVIEW utilise la même police que la police de l'application.
  • (OS X) Par défaut, LabVIEW utilise Lucida Grande.
  • (Linux) Par défaut, LabVIEW utilise la police Helvetica.

Lorsque vous portez un VI qui contient une de ces polices sur une autre plate-forme, LabVIEW assure une bonne correspondance de police sur la nouvelle plate-forme.

Si vous n'utilisez pas les polices prédéfinies, la taille de la police risque de changer sur la nouvelle plate-forme si les polices disponibles et la résolution de l'affichage sont différentes d'une plate-forme à l'autre. Par exemple, si vous choisissez la police Geneva ou New York sur Macintosh et que vous portez le VI vers Windows, LabVIEW ne trouvera pas cette police sous Windows et la remplacera par Arial. La police de remplacement ne sera peut-être pas identique à celle d'origine, et certains objets risquent de se chevaucher. Si vous portez un VI sur Windows et que Windows ne reconnaît pas ses polices, la nouvelle police s'affichera peut-être différemment.

De même, il se peut qu'une police ne soit pas reconnue sur un système d'une autre langue. Par exemple, un système japonais risque de ne pas reconnaître la police Arial de Windows. Utilisez les polices de l'application, des boîtes de dialogue et du système pour ne pas devoir redéfinir les polices lorsque vous localisez une application.

Si vous utilisez une police prédéfinie sur une portion de texte, évitez de changer la taille de ce texte. Si vous n'utilisez pas la taille par défaut de la police et que vous transférez ensuite le VI sur une plate-forme différente, LabVIEW essaie de faire correspondre la police à la nouvelle taille, ce qui risque de ne pas être approprié pour la résolution de l'écran.

Problèmes de codes de caractères

Un ordinateur représente les données sous forme d'octets. Il stocke les lettres et les autres caractères en assignant à chacun un code de caractère.

Dans le cas le plus simple, un octet correspond à un caractère selon une table de correspondance ou d'encodage. La plupart des systèmes d'exploitation supportent de nombreux encodages différents. Un type d'encodage est l'encodage à simple octet, qui peut représenter jusqu'à 256 caractères. Pour représenter des caractères supplémentaires en-dehors des caractères anglais, les systèmes d'exploitation supportent aussi les encodages multi-octets. Les encodages multi-octets peuvent représenter des milliers de caractères mais requièrent plusieurs octets pour chaque caractère. Les systèmes japonais et chinois utilisent des encodages multi-octets pour représenter plusieurs milliers de caractères. Maintenenant, presque tous les systèmes d'exploitation supportent aussi l'encodage à octets variables, qui utilise moins d'octets pour des caractères plus courants. Un encodage à octets variables, tel que l'UTF-8, utilise un octet simple pour les 128 premiers caractères puis ajoute un octet supplémentaire selon le besoin pour élargir le nombre de représentations de caractères possibles.

Remarque  Dans les applications exécutées sur des systèmes multi-octets, n'essayez pas d'analyser une chaîne en la convertissant en tableau d'octets, car certains caractères sont susceptibles d'utiliser deux octets. Certaines fonctions Chaîne ne traitent pas les caractères multi-octets.

L'encodage à 8 bits le plus courant aux États-Unis et dans les pays d'Europe de l'Ouest est l'ISO Latin I, qui est une extension de l'ASCII.

L'encodage ASCII est un code à 7 bits (de 0 à 127). Il contient l'alphabet anglais en majuscule et minuscule, la ponctuation américaine, une numérotation en base 10 et quelques codes de commandes. Les codes de commandes sont une série de caractères non affichables utilisés pour la mise en forme du texte. Vous pouvez imprimer la plupart des caractères ASCII sur la plage de \0x21 à \0x7F.

Pour représenter des caractères internationaux, les systèmes d'exploitation supportent les encodages à 8 bits, tels que l'ISO Latin 1, comme extensions du format ASCII. Les codes des 128 caractères inférieurs sont identiques à l'ASCII, et ceux des 128 caractères supérieurs sont différents pour chaque encodage. Les différents caractères internationaux résident dans les 128 codes de caractères supérieurs. LabVIEW pour Windows, Linux et OS X (32 bits) utilisent des jeux de caractères 8 bits mais différents encodages, ce qui peut causer des problèmes de portabilité.

Pour les États-Unis et les pays d'Europe de l'Ouest, LabVIEW pour Windows et Linux utilisent l'encodage ISO Latin 1, également connu sous le nom de page de codes. LabVIEW pour OS X (32 bits) utilise une page de codes différente, appelée MacRoman. Pour les systèmes d'exploitation localisés en japonais, chinois ou coréen, LabVIEW utilise différents encodages multi-octets pour représenter des caractères dans chacune de ces langues. LabVIEW détermine l'encodage à utiliser en fonction des options régionales du système d'exploitation et des paramètres de langue. Ces encodages sont les mêmes sous Windows, Linux et OS X (32 bits), la portabilité est donc moins contraignante. Cependant, LabVIEW pour OS X (64 bits) utilise une extension de l'ASCII à longueur variable appelée UTF-8, qui représente n'importe quelle langue.

Remarque  Tous les systèmes d'exploitation supportent l'encodage UTF-8. Cependant, LabVIEW n'utilise pas UTF-8 sous Windows, Linux ou OS X 32 bits pour rester compatible avec les applications utilisateur existantes.

Lorsque vous portez un VI d'une plate-forme à une autre, d'OS X à WIndows ou de Windows à OS X par exemple, il est possible que vous rencontriez des problèmes à cause de la différence de pages de codes entre les plates-formes, surtout si vous utilisez des caractères non-ASCII dans la plage des 128 caractères supérieurs. Par exemple, le mot français café utilise le caractère étendu é, dont la valeur hexadécimale sous Windows est \0xE9. Pour afficher ce même caractère é sous OS X 32 bits, il faut utiliser \0x8E. Cependant, sous OS X 64 bits, il faut utiliser la séquence 2 octets \0xC3\0xA9 pour réprésenter le caractère é.

LabVIEW effectue une conversion de pages de codes pour les éléments comme les sous-titres, les info-bulles et les descriptions du VI et de ses paramètres, les titres de VI et d'autres données privées. Les données privées incluent les noms des éléments des menus déroulants, les titres des colonnes ou des lignes des tableaux, la police utilisée pour les cellules des tableaux, les noms des tracés des graphes, les noms des annotations des graphes et les noms des curseurs. Cependant, LabVIEW ne mappe pas les étiquettes et le contenu des chaînes. Les étiquettes et le contenu des chaînes peuvent apparaître de façon différente après avoir été portés sur une nouvelle plate-forme, et il faudra peut-être les modifier manuellement. Ainsi, si vous voulez porter des VIs de Windows ou de Linux sur OS X ou vice-versa, évitez d'utiliser des caractères internationaux dans les chaînes ou les étiquettes.

LabVIEW ne mappe pas le contenu des chaînes, car les chaînes peuvent être interprétées comme des informations binaires. Si vous communiquez avec un instrument qui utilise le GPIB ou la communication série, et que votre instrument requiert la chaîne binaire \0x63\0x61\0x66\0xE9, cette chaîne s'affiche comme “café” sur la plate-forme Windows et comme “cafÈ” sur la plate-forme OS X 32 bits. Dans les deux cas, vous devriez envoyer la même chaîne binaire à l'instrument. Pour éviter tout type d'erreur de communication, LabVIEW n'effectue pas de mapping de caractères sur les valeurs de chaînes.

LabVIEW ne mappe pas les étiquettes car le remappage d'étiquettes à un nouvel encodage peut briser un VI. Par exemple, si vous utilsez la fonction Désassembler par nom et si LabVIEW remappe les étiquettes du contenu de clusters, le VI peut se briser car les références à la commande par nom ne correspondent plus.

Chevauchement d'étiquettes

Lorsque vous transférez un VI sur une nouvelle plate-forme, les commandes et les étiquettes risquent de changer de taille, suivant la taille des polices de la nouvelle plate-forme. LabVIEW s'efforce d'empêcher que les étiquettes chevauchent leurs propriétaires en les éloignant de la commande propriétaire. De plus, chaque étiquette et chaque constante a un attribut par défaut appelé Ajuster à la taille du texte. La première fois que vous créez une étiquette ou une constante, cet attribut est activé de façon à ce que les limites de l'objet se déplacent suffisamment pour afficher la totalité du texte.

Si vous redimensionnez manuellement l'étiquette, LabVIEW désactive cet attribut, et l'élément n'est plus coché dans le menu local. Une fois l'option Ajuster à la taille du texte désactivée, les limites de l'objet restent constantes et LabVIEW coupe et recadre le texte inscrit si nécessaire. Si vous ne voulez pas que LabVIEW coupe du texte lorsque vous passez d'une plate-forme à une autre, gardez cet attribut activé pour les étiquettes et les constantes. Après avoir redimensionné l'étiquette, vous pouvez manuellement activer Ajuster à la taille du texte.

Tous les ordinateurs n'ont pas des moniteurs haute résolution. Cependant, si vous avez un moniteur haute résolution, ne créez pas de faces-avant trop grandes si vous voulez pouvoir les porter facilement. Pour améliorer la portabilité, laissez un espace supplémentaire entre les commandes et évitez qu'elles ne se chevauchent. Si vous portez une étiquette qui en chevauche une autre, il se peut qu'elle chevauche toute la commande si la police de la nouvelle plate-forme est plus grande.

Différences entre les images

Le format d'image le plus élémentaire est une bitmap, constituée d'une série de valeurs définissant la couleur de chaque pixel de l'image. Les images plus complexes peuvent contenir des commandes que le système informatique exécute à chaque fois qu'il affiche l'image.

Utilisez la couche graphique d'une application graphique pour créer des images à partir de bitmaps. Les bitmaps constituent un format d'enregistrement d'images commun à toutes les plates-formes. Si vous utilisez des images qui contiennent des bitmaps sur vos faces-avant, les images restent généralement les mêmes lorsque vous chargez les VIs sur une autre plate-forme. Cependant, les images qui contiennent des commandes de dessin, comme des commandes de remplissage, peuvent inclure des commandes qui ne sont pas supportées sur d'autres plates-formes. Vérifiez l'aspect des VIs sur la plate-forme où vous souhaitez les utiliser.

Utilisez la couche vectorielle d'une application graphique pour créer des images qui contiennent des commandes de dessin. Pour faciliter la portabilité des images, collez l'image finale dans la couche graphique d'une application graphique avant d'importer l'image dans le VI.

(Windows et OS X) Avec certaines applications graphiques sous Windows et de nombreuses applications graphiques sous OS X, vous pouvez couper ou copier une image de forme non rectangulaire. Par exemple, sous OS X, vous pouvez utiliser l'outil Lasso pour sélectionner le contour d'un cercle, d'un triangle ou d'une forme plus élaborée, comme une note de musique, par exemple.

Il est possible que d'autres plates-formes dessinent ces formes irrégulières sur un fond blanc rectangulaire. Sous Windows, si vous voulez des images de forme irrégulière ou qui changent facilement d'échelle, utilisez des applications qui supportent les fichiers EMF (Enhanced Metafile).

CET ARTICLE VOUS A-T-IL ÉTÉ UTILE ?

Pas utile