From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Menu unicode / codepage

Résolu !
Accéder à la solution

Desruelle_luc a écrit :

 

salut à tous, je passe rapidement avant de repartir......

je pense qu'il faut comprendre :  je souhaiterais afficher les menus en non Unicode, pour du chinois en l'occurence.

Panneau de configuration\Tous les Panneaux de configuration

Region et langue

onglet > Administration -> cadre "langue pour les programmes non unicode -> chinois trad

A+


Merci!

A+

0 Compliments
Message 21 sur 29
2 233 Visites

 

le ‎01-07-2014 05:35 PM


Eric.M a écrit :

 

 

Hello,

 

Malheureusement aux deux questions posées, la réponse est non... LabVIEW travaille en ASCII ou ISO-8859-1 et utilise le langage/charset de l'OS. Pas d'unicode natif donc, sauf pour certains éléments de la face-avant modifiable via le token UseUnicode évoqué. Pour contourner la chose, deux idées moins élégantes :

- Utiliser un conteneur .NET qui soit un menu (MenuStrip). Ca va demander un gros effort à faire mais, les polices sont complètement libres.

- Créer un "faux-menu", plutôt à la manière d'une barre d'outils, composée de booléens et autres listes déroulantes. Là non-plus ça ne remplace pas un vrai menu, mais s'agissant d'objets de la face-avant, le UseUnicode=True pourra être pris en compte.

 

Cdt

-Eric


 

Bonjour,

 

Me voici de retour car j'ai utilisé la technique du .NET pour refaire le menu comme le suggère Eric, cela fonctionne pour des caractères ASCII, mais je ne parviens pas à afficher des caractères chinois. Quelqu'un aurait-il une idée d'où le problème provient?

 

(Je précise qu'il faut ajouter la ligne UseUnicode=True dans LabVIEW.ini)

 

Vous trouverez c-joint, un exemple.

0 Compliments
Message 22 sur 29
2 200 Visites

salut, tu as vraiment besoin d'un menu unicode? tu ne peux pas garder un menu non unicode comme dans l'exemple de la page 1 de ce post? cela est plus simple à gérer.

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

0 Compliments
Message 23 sur 29
2 184 Visites

Salut,

 

Merci de ta réponse.

 

Et bien cela me génère des erreurs au chargement de d'autres softs déjà en exe présents sur les machines lorsque je bascule l'option régionale "appli non unicode vers du chinois".

 

Peux-tu me poster un exemple stp?

 

Les menu standards basculent pourtant bien dans toutes les langues en version exécutable avec le runtime si on a coché la langue chinoise à la construction et mis le pc en affichage Chinois, pourquoi cela n'est pas possible avec des menus personnalisés ?

0 Compliments
Message 24 sur 29
2 176 Visites

J’ai rencontré le même problème avec ce menu .NET (ToolStripMenu) : impossible de faire afficher des caractères Unicode.

 

Après plusieurs essais, j’ai abandonné en lisant cela :

 

“ A window class is supported by a window procedure. Your application can register a window class by using either RegisterClassA or RegisterClassW. New applications should typically use RegisterClassW.

 

If the application registers the window class using RegisterClassA, the function informs the operating system that the windows of the created class expect messages with text or character parameters to use a Windows (ANSI) code page character set.”

 

http://msdn.microsoft.com/en-us/library/windows/desktop/dd319108%28v=vs.85%29.aspx

0 Compliments
Message 25 sur 29
2 166 Visites

Bonjour JM,

 

Merci de ta réponse pertinente!

 

Eric M. s'est-il trompé? 😄

 

Il me reste la solution de Luc, qui fonctionne, mais qui demande à ce que toute la hiérarchie de VI soient sans caractère spéciaux (é,à,ç etc.) car au changement d'options régionales cela créé des conflits sur toutes les applications déjà compilées car les liens sont brisés.

 

Dans mon cas, tous les développeurs de ma société ont une librairie communes ne respectant pas toujours ce formatage, je vais devoir  convaincre mes collègues de modifier/recompiler toute notre librairie de VI datant d'une dizaine d'années, c'est pas gagné...

 

A+

0 Compliments
Message 26 sur 29
2 161 Visites

Salut à vous, faire de l’Unicode présente des avantages mais aussi des inconvénients...

Pour LabVIEW, il faut éviter de mettre des caractères autres que l'ASCII court dans les noms de VI car cela empêche la portabilité, entre OS mais aussi sur le même OS s’il a des langues différentes. Effectivement un exécutable, qui est un fichier binaire de la représentation du code, ne sera pas exécutable sur un PC dont l'OS est en chinois, s'il existe des "é" ou "°C" ou autres dans les noms de fichier. Il en sera de même sur des chemins codés en dur, entre différentes versions de l’OS. Et pour les deux exemples, je ne pense pas que l’Unicode peut le changer.

Pour le nom des fichiers, même problème avec un OS linux ou en fonction de la méthode de compression de 7zip.

 

Perso, je pars du principe : LabVIEW ne supporte pas en Natif, alors je ne fais pas, sinon c’est forcément des galères, il suffit d’attendre le jour où elles vont arriver !

A+


TeamJP34 a écrit :

 

 

Il me reste la solution de Luc, qui fonctionne, mais qui demande à ce que toute la hiérarchie de VI soient sans caractère spéciaux (é,à,ç etc.) car au changement d'options régionales cela créé des conflits sur toutes les applications déjà compilées car les liens sont brisés.

 

Dans mon cas, tous les développeurs de ma société ont une librairie communes ne respectant pas toujours ce formatage, je vais devoir  convaincre mes collègues de modifier/recompiler toute notre librairie de VI datant d'une dizaine d'années, c'est pas gagné...

 

A+


 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

0 Compliments
Message 27 sur 29
2 150 Visites

Bonjour TeamJP34,

 

Il semble que Eric_M ne se soit pas trompé, mais malheureusement il n'y a pas de chemin direct avec LabVIEW.  Voir son commentaire (26 nov. 2014):

 

https://decibel.ni.com/content/docs/DOC-17642#comment-39265

 

 

0 Compliments
Message 28 sur 29
2 110 Visites

Salut JM,

 

On peut désormais dire qu'il s'est aperçu qu'il s'est trompé :D, car il s'agissait bien d'une solution pour LabVIEW qu'il proposait, mais cela ne peut pas pas fonctionner. 🙂

 

Ce n'est pas grave, j'ai oublié l'idée du .NET et me suis rabattu sur la technique de Luc avec toutes les contraintes que ça comporte, notamment sur les Lvclass et pire encore avec les Xcontrol (noeud de propriétés, données etc... qui comportent des accents par défaut dans Labview en français :()

 

C'est un gros manque à mon sens dans LabVIEW de ne pas prendre en compte le unicode, dotant plus que LabVIEW est World Wide et est utilisé par des industriels qui, le sont aussi le plus souvent! 😉

 

 Bonne soirée à tous,

 

EDIT: Pour ceux qui pensent que l'idée d'une prise en charge du unicode semblent importante, je vous invite à encourager ce projet, voire le commenter via ce lien: http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/316/

0 Compliments
Message 29 sur 29
2 099 Visites