Discussion :

[bizulk]

Bonjour,

J'ai du reprendre une IHM de simulation de client réseau sur un protocole proche de Modbus. L'IHM est codée avec VC++ 6.0.
Lors des essais j'ai oublié d'intégrer un bouton à cocher d'émission périodique.
Le testeur, plutôt que de reprendre les sources a préféré coder en python des essais complémentaire.
Je voudrais exposer les classes (en particulier les méthodes d'émission/réception) à un script qui serait appelé via la GUI, et inversement lister les fonctions d'un script trouvé dans un fichier sélectionné. Cela permettrait à l'IHM de s'adapter à des essais complémentaire tout en gardant une présentation épurée.

J'avais fait cela très facilement avec une autre application Qt qui intégrait un moteur Javascript (très bien fait avec un éditeur/débogueur qui se lançait en cas de Pb).
Ici c'est moins évident, ou alors j'ai trop de choix : entre OLE, ActiveX, et COM mon coeur balance.
D'autres solutions (LUA, python) seraient envisageables mais elles créent de nouvelles dépendances sur des softs à installer que je préfèrerais éviter.

J'ai fais quelques recherches et parcouru en diagonale des chapitres de livres, mais ça s'adresse plutôt à ceux qui savent déjà ce qu'est OLE/ActiveX et COM et présente l'utilisation.

Merci pour vos suggestions.

[bacelar]

Le rapport avec les MFC ?

OLE, ActiveX, et COM, c'est pareil.

OLE2 a été implémenté avec COM (OLE1, oublié depuis plus de 20ans)
ActiveX était le "nouveau" nom, plus "hype", de COM.

Je ne comprends pas trop votre problème, c'est intégrer un interpréteur dans un code C++ ?
http://www.codeproject.com/Articles/...ing-Lua-into-C

Mais je ne vois vraiment pas l'intérêt d'une IHM pour un simulateur de client réseau.

Cela devrait être une simple application console avec un simple "script" indiquant les choses à émettre sur la socket.

[bizulk]

"ActiveX était le "nouveau" nom, plus "hype", de COM."

Le livre que j'ai consulté (VC6 Ivor Horton) le présentait comme un nom marketing, mais j'ai bien trois chapitres distincts.

"c'est intégrer un interpréteur dans un code C++ ?"

C'est ça.

Mais je ne vois vraiment pas l'intérêt d'une IHM pour un simulateur de client réseau.

C'est plus conviviale pour un premier contact, on assiste à la construction de la trame, on affiche les données qui vont être envoyées, etc... Elle a une utilité pour un scénario de test non automatisé et convenait dans la plupart des cas.

"Cela devrait être une simple application console avec un simple "script" indiquant les choses à émettre sur la socket. "

Pour l'imagination des testeurs je suis d'accord.

Donc vous vous conseilleriez malgré tout LUA quitte à installer un interpréteur. Je vais regarder ça j'ai peu de temps mais si l'interpréteur fonctionne bien sous windows pourquoi pas.
Merci.

[bacelar]

"Donc vous vous conseilleriez malgré tout LUA quitte à installer un interpréteur. Je vais regarder ça j'ai peu de temps mais si l'interpréteur fonctionne bien sous windows pourquoi pas."

Non.

Les possibilités pour un client réseau, c'est juste des trames à envoyer dans un ordre ou dans un certain délai.

Pas la peine d'implémenter tout un langage pour ça.

Une routine d'interprétation ligne à ligne d'un fichier, avec des séparateurs de colonne pour les paramètres, devrait faire largement l'affaire.

c'est quelques lignes de code, pas plus.

[bizulk]

"Une routine d'interprétation ligne à ligne d'un fichier, avec des séparateurs de colonne pour les paramètres, devrait faire largement l'affaire."
Oui pourquoi pas...
En fait, oui, on peut définir quelques commandes et lire basiquement ligne à ligne un fichier.

Mais le but de l'interpréteur c'est de réaliser ces opérations banales sans restriction, et éventuellement d'utiliser l'affichage pour analyser les échanges et lister les résultats. Si c'est facile à intégrer c'est une solution aussi, applicable partout

Discuter de ce choix n'est pas vraiment l'objectif de thread, même si je pense qu'au vu du temps que j'ai je vais faire comme vous le proposez.
Avez-vous une expérience sur l'intégration d'un interpréteur avec les MFC, est-ce si compliqué pour préférer s'en passer ?

Merci.

[bacelar]

Mode relou On.

Ajouter une fonctionnalité sans besoin réellement déterminé, c'est jamais un bon calcul.

Le langage, ou le type de langage donc il faut intégrer l'interpreter doit être déterminé en fonction du besoin.
Un interpreter prolog ou lisp n'a pas grand chose à voir avec python mais bien plus efficace pour appliquer des règles de comportement.

Intégrer un interpreter n'est jamais anodin.

Donc, vous le voyez comment votre "ces opérations banales sans restriction" ?

Car un interpréter ligne à ligne avec peu ou pas de variable d'état, cela est bien plus simple, et l'affichage devrait être adapté au domaine fonctionnel.

Si c'est un outil pour développeur, il faut juste intégrer l'interpreter du langage fétiche du développeur le plus casse-noisette avec cette "fonctionnalité".

Mais intégrer un interpreter n'est jamais anodin.

[Médinoc]

OLE, ActiveX, et COM, c'est pareil.

Pour moi, ActiveX est une technologie COM, plus précisément les contrôles qui doivent implémenter tout plein d'interfaces (IObjectWithSite, IOleInPlaceActiveObject, etc.) pour marcher.

[Mat.M]

J'avais fait cela très facilement avec une autre application Qt qui intégrait un moteur Javascript (très bien fait avec un éditeur/débogueur qui se lançait en cas de Pb).
Ici c'est moins évident, ou alors j'ai trop de choix : entre OLE, ActiveX, et COM mon coeur balance.

avant d'embrayer toute une usine à gaz un simple fichier XML de configuration ne suffit pas ?
Sinon si tu crées un Active X je ne vois pas comment cela te servira à incorporer un interpréteur

[bizulk]

Toute une usine à gaz ?
Peut-être que le moteur Javascript de Qt est une usigne à gaz, mais je l'ai intégré en deux coups de cuillère à pot. Et j'ai exposé mes objets Qt très rapidement.
Avec un fichier xml, il faut que je rapporte toutes les commandes que je souhaiterais appliquer pour permettre le développement d'une batterie de tests. Pas si compliqué à faire mais fastidieux.
Bah pour l'instant je suis ailleurs, mais je préfère encore porter l'application sous Qt si je m'y mets.