Discussions au sujet des autres produits NI

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

labview.dll (??)

Français + Allemand = Suisse, nan? Smiley très heureux

 

Je me suis habitué très vite au QWERTZ, je ne peux plus voir les AZERTY maintenant... chacun ses ptites manies.


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Compliments
Message 11 sur 17
2 913 Visites

Le probleme est le changement récurrent entre un AZERTY, un QUERTZ, un QWERTY (USA) et un QWERTY (Pologne).

 

Quand à la définition du suisse... Allemand + Francais = Alsacien. Suisse = Alsacien + Italien. Quelquechose du genre.

 

Pour revenir au sujet, j'ai fait quelques tests: il apparait impossible de publier des fonctions à partir d'un exe compilé avec CVI. Je m'y suis cassé les dents pendant une petite heure avant de trouver une discussion sur le sujet expliquant que ce n'était pas réalisable. 

 

Ceci-dit, il semble que cette méthode ait quelquechose de monstrueux et que Microsoft la déconseille autant que possible, hormis pour quelques applications extrêmement spécifiques: Dans le cas d'un appel externe dynamique (LoadLibrary sur le fichier exe), le code de d´marrage et les données globales ne seront pas initialisées, entrainant potentiellement tout un tas de comportement "Rock'n'Roll".  

______________
Florian Abry
Inside Sales Engineer, NI Germany
0 Compliments
Message 12 sur 17
2 908 Visites

pour Naity (version release)

 

Cet exécutable a été généré avec Visual C++ 2008 Express

 

ceci dit, vous dites :" ... impossible de publier des fonctions à partir d'un exe compilé avec CVI ..."

 

par "publier" je suppose que vous parlez "d'exporter" (?)

si c'est le cas ... je ne vois vraiment pas pourquoi il serait impossible de faire cela avec CVI.

CVI, c'est du C ... alors Visual C++ ou CVI ... c'est la même chose.

Si CVI reconnait "__declspec(dllexport)", et c'est le cas, rien à mon sens n'interdit la manip.

0 Compliments
Message 13 sur 17
2 893 Visites

Merci Ouadji pour la version Release de l'exe.

 

Dans mon post precedent, je parlais bien d'exporter, excusez le travers de langage. 

 

La raison pour laquelle il ne l'autorise pas m'est obscure. J'ai simplement trouve l'affirmation suivante de la part d'un collegue d'Austin. Cette affirmation semble recouper les tests effectues cet apres-midi:

"You cannot export a function from an executable in CVI, I guess the way the options are set, you are only allowed to export symbols only if you create a dll."

 

Que ce soit en utilisant __declspec(dllexport) ou un fichier .def , la fonction n'a pas ete exportee et, du moins depuis LabVIEW, ne peut pas etre appelee. J'essaierais demain de voir si je peux l'appeler depuis Visual Studio via LoadLibrary() mais je ne suis pas optimiste.

 

Cordialement

______________
Florian Abry
Inside Sales Engineer, NI Germany
0 Compliments
Message 14 sur 17
2 889 Visites

hummm ...

Le compilateur C de CVI,

n'autorise pas l'assembleur en ligne,

n'autorise pas d'exporter depuis un exe,

quoi d'autres ?

 

pourquoi "brider" ainsi les choses ... autorisées par les autres "grands" compilateur C (de la concurrence).

 

0 Compliments
Message 15 sur 17
2 885 Visites

C'est probablement la raison pour laquelle le compilateur C de CVI devrait changer dans un peu plus d'un an.

 

Pour en avoir discute avec la PSE du produit, je ne crois pas qu'il s'agit de brider le compilateur. La seule limitation intentionelle concerne les fonctions bas niveau qui ont ete "castrees" il y a un an (il me semble). Le compilateur a ete cree pour repondre a des besoins bien precis il y a deja plusieurs annees et a "grossi" au fur et a mesure des ajouts.  On est dans un schema classique ou le produit de base a ete cree pour un marche specifique, des ajouts de fonctionnalite ont ete faits au cours des ans, au bout d'un moment la complexite de l'architecture arrive a un point ou il est necessaire de la repenser et, plutot que d'ajouter toujours plus et que le produit devienne trop lourd et ingerable, on repense le produit pour s'adapter aux nouveaux besoins. C'est un cycle classique et c'est ce qui se passe dans ce cas precis.

 

On y verra surement plus clair quand une version beta du nouveau compilateur sera disponible mais je doute que les "brides" sus-citees soient intentionnelles.

 

Coridalement

______________
Florian Abry
Inside Sales Engineer, NI Germany
0 Compliments
Message 16 sur 17
2 882 Visites

oui, je comprends.

 

répondre à des besoins ... voila une phrase cléf.

 

Je connais très peu CVI (quasi pas) ... je connais un peu mieux LabVIEW.

Mais avec labview, je ressens la même chose ... labview est là pour répondre à des besoins !

En ce qui concerne LV, NI "pense" (il me semble) en terme d'outil et non en terme de langage.

Comme une vieille réminiscence de ses débuts ... outil destiné aux tests et mesures. (et point barre)

Or, il me semble que LV est devenu bien plus qu'un outil ... LV, à mon sens, est devenu un langage à part entière.

Un langage graphique, intuitif, puissant !

Quand on regarde certaines fonctions proposées par LV ... comment dire ... certaines ne sont pas génériques, "globales".

Un seul petit exemple, "rotate string" ... cette fonction est complètement "bridée" par rapport à un "rotate logique".

C'est un tout petit exemple (insignifiant), il y en à d'autres.

Si la fonction ne correspond pas à un besoin (demandé par la majorité) ... cela n'est pas nécessaire de l'implémenter.

La notion de cohérence globale de l'objet (LV) me semble parfois passée au second plan.

Il y a comme un "esprit" (presque une tradition ?) dont on arrive difficilement à se séparer ... l'esprit "outil".

Labview est avant tout un "outil" ... et doit le rester ???


0 Compliments
Message 17 sur 17
2 880 Visites