Discussion :

[fbtsra]

Bonjour,

J'utilise sous Access le composant Mscomm32.ocx pour récupérer des données du port COM lors de l'évènement écriture sur ce dernier. Ce composant fonctionne parfaitement sur des postes équipés de VB6. Par contre je ne parviens pas à le déclarer convenablement sur des postes ne disposant par de VB6.

Cette opération est elle possible et le cas échéant sous quel format ?

Pour info : API testé, mais ne gère pas à ma connaissance les évènements du port COM et contraint à l'utilisation d'un timer.

En vous remerciant par avance de votre aide.

[marot_r]

Bonjour.

J'ai fait une petite recherche Google : using Mscomm32.ocx with vba access

Celui-ci arbore différent points qui seront peut-être d'intérêt pour toi :
mscomm32.ocx communications control and Windows 7, Access 2010
https://social.msdn.microsoft.com/Fo...orum=accessdev

Celui-ci me parait le plus complet
Microsoft Access and Serial Port Communications
http://www.granite.ab.ca/access/serialport.htm

Il y a en a pleins d'autres ... et les ports com ne sont pas du tout ma spécialité donc difficile de faire tri.

A+

[fbtsra]

Bonjour,

Je te remercie de cette réponse.

J'ai parcouru les différents liens sans succès.

Sous un autre angle, que manque t il pour utiliser mscomm32.ocx sans VB6 sur le poste (puisque mscomm32.ocx fonctionne sous Access sur des postes équipés VB6) ?

Merci par avance pour toute piste sur le sujet.

[marot_r]

Autant que je sache, le VB6 n'est pas indispensable pour utiliser un activeX (.ocx).

Il suffit qu'il soit "enregistré" et il devient disponible pour n'importe quel langage capable de discuter avec un ActiveX (dont VBA).

A+

[fbtsra]

Bonjour,

J'ai le fin mot de l'histoire, après parcours de nombreux sites notamment orientés sur VB6 : c'est un problème de version.

- la version 1998 de MsComm32.ocx ne fonctionne sous Access 2013 que si VB6 est installé sur le poste : sans VB6, pas moyen de l'utiliser en le référençant en VBA ou en l'insérant comme contrôle. Dés l'installation de VB6, les deux méthodes refonctionnent parfaitement sur les postes dont je dispose. Aucune piste d'explication trouvée mais il semble que la version 2009 de MsComm32.ocx, cf ci-après, faisait partie d'un correctif intégrant ce problème.

- la version 2009 de MsComm32.ocx semble ne poser aucun problème sous Access 2013, en tout cas sur la base des premiers tests effectués.

Merci encore à marot_r de s'être penché sur le sujet.