le 11-12-2014 07:58 AM
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+
le 11-18-2014 02:02 AM
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.
le 11-18-2014 07:32 AM
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.
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
le 11-18-2014 09:27 AM
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 ?
le 11-18-2014 10:47 AM
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
le 11-18-2014 11:15 AM
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+
le 11-19-2014 01:06 AM
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+
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
le 11-26-2014 09:47 AM
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
11-26-2014 11:10 AM - modifié 11-26-2014 11:25 AM
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/