classe facilitant les interactions avec un port COM / RS232

Bonjour,

Je vous propose un nouvel élément à utiliser : classe facilitant les interactions avec un port COM / RS232

Cette classe (dialogueCOM) permet de faciliter les opérations de lecteur et d'écriture sur les ports COM et RS232. Elle marche aussi bien sur linux que sur Windows. J'ai rajouté un exemple pour montrer comment elle fonctionne.

Qu'en pensez-vous ?

http://www.webalice.it/fede.tft/seri...rial_port.html

La bas tu as un code de très bonne qualité avec boost::asio et boost::thread.
A voir si faudrait pas plus héberger ce code (qui est sur github par ailleurs)

Citation:

---

Envoyé par Davidbrcz

http://www.webalice.it/fede.tft/seri...rial_port.html

La bas tu as un code de très bonne qualité avec boost::asio et boost::thread.
A voir si faudrait pas plus héberger ce code (qui est sur github par ailleurs)

---

C'est vrai que je n'ai pas du tout eu l'idee de me servir de boost. L'avantage de ma classe c'est qu'il n'y a pas besoin d'une lib externe pour la faire fonctionner. Mais c'est vrai que ce serait une bonne chose de rajouter la possibilite d'une utilisation asynchrone. Si jamais je le fais je pense que ce sera sans passer par une lib externe.

Je débute en C++. J'ai essayé le code proposé avec CodeBlocks qui me signale l'erreur

suivante sur la ligne 299.

Citation:

---

F:\Documents\Programmes C\Code Blocks\Programmes console\RS232\COM RS232\dialogueCOM.cpp|173|

error: cannot convert 'wchar_t*' to 'LPCSTR {aka const char*}' for argument '1' to 'void* CreateFileA(LPCSTR, DWORD, DWORD, LPSECURITY_ATTRIBUTES, DWORD, DWORD, HANDLE)'|

---

La ligne en question contient l'expression suivante :

Code:

---

g_hCOM = CreateFile(buf, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_SYSTEM, NULL);

---

Est-ce dû au compilateur ou y a-t-il un vrai problème ?

Merci de votre aide

Mélange entre ASCII et UNICODE, vraisemblablement un problème dans les constantes de compilation.

L'expansion en ligne de CreateFile montre que la constante de compilation UNICODE n'est pas défini mais la variable buf a un type non compatible.
La déclaration de la variable buf, SVP.

On trouve cette déclaration juste avant (ligne 296) dans le contexte suivant :

Code:

---

1 2 3 4 5

int len; int slength = (int)nId.length() + 1; len = MultiByteToWideChar(CP_ACP, 0, nId.c_str(), slength, 0, 0); wchar_t* buf = new wchar_t[len]; MultiByteToWideChar(CP_ACP, 0, nId.c_str(), slength, buf, len);

---

Votre code ne semble pas compatible ASCII, définissez la constante compilation UNICODE.
Avec un peu de chance, le reste de votre code sera compatible UNICODE.

@d6bel: je n'ai pas réussi à reproduire ton erreur donc je ne vois pas trop comment t'aider. J'espère que la solution de @bacelar a fonctionné. J'ai mis le code sur github (ici). Si jamais tu as un autre problème, fais moi une issue.

Merci beaucoup de ton intervention. Peux-tu m’aider un peu plus en m'indiquant comment procéder pour définir la constante de compilation "UNICODE".
Est-ce par une directive de compilation (code ?) ou par une configuration des paramètres du compilateur" ?

Ce qui est bizarre c'est qu'il n'y a pas d'erreur lors de la déclaration de buf ?!

J'ai testé le même code sur un autre compilateur ( Dev C++) et j'obtiens le même message d'erreur. J'ai récupéré le code sur github (qui est très voisin du tien) je vais le tester, mais je crains de me heurter au même

problème. Sur quel compilateur travailles-tu? Le système d'exploitation (dans mon cas : W7) peut-il avoir un rôle?

Merci de ton aide

J'ai toujours bossé avec mingw sur windows (7 et 8). Pour les systèmes testés :

- Windows 7
- Windows 8
- OpenSUSE
- Fedora
- ElementaryOS
- Mint

Ils étaient tous en 64 bits. Donc je t'avoue que ton problème me surprend un peu puisque tu es le premier à l'avoir. Je vais re-tester de mon côté.

Je viens de tester sur un pc plus récent et en effet il m'a indiqué une erreur que j'ai corrigé (sur github). Tu peux me dire si c'est bon pour toi ?