contrôle Winsock ocx dans VC++ 2005 express

Bonjour,

j'ai un souci d'utilisation du contrôle OCX Winsocks (winscks.ocx récupéré de VB6) que j'ai importé dans la toolbox de Visual C++ 2005 Express (l'importation a été faite directement depuis la boite à outils et s'est déroulée sans erreur).

Pour vérifier la fonctionnalité de ce contrôle j'ai commencé par faire une application très simple, une simple fenêtre incluant ce contrôle (donc que du code généré automatiquement). Le build se passe très bien, sans aucune erreur ni warning, mais au moment du lancement de l'application, j'ai un message d'erreur contenant "File not found -> axWinsock.1.0.dll or one of its dépendancies"  qui apparaît en boite de dialogue.
Il semble que ce fichier soit généré automatiquement à partir de l'ocx de base lors de son importation dans la toolbox, et les propriétés du projet concernant la référence à ce contrôle pointent bien vers le répertoire qui a été créé dans lequel se trouve cette DLL. J'ai essayé de copier ce fichier dans d'autres répertoires (celui de l'exe), mais rien n'y change.

Est-ce que quelqu'un aurait déjà vu ça et aurait une solution ?

Merci

Salut,

or one of its dépendancies
C'est pas forcément cette dll qui manque, ça peut aussi être une dll dont elle à besoin.

Je te propose la méthode du barbare sangunaire :
Tu renomes axWinsock.1.0.dll en axWinsock.1.0.txt.
Tu ouvres tout ça dans notepad.
Tu fais une recherche de .dll là dedans.
Maintenant que j'y pense y a peut être l'unicode qui apporte son grain de sable...
Ptêt qu'une recherche de . d l l (Avec des espaces entre les caractères) suffit à gérer le coup de l'unicode.

Y a aussi sûrement des logiciels qui ferait ça mieux que notepad...

[ Lien ]

D@runia

merci pour le conseil et le lien vers dependencywalker.

Le test de cette DLL sous dependancywalker montre qu'à part apphelp.dll, aucun fichier de dépendance ne manque. Le apphelp.dll n'existe pas sous windows 2000 (mon pc tourne avec cet OS), donc c'est normal qu'il ne le trouve pas.
Pour vérifier si ce n'est quand même pas ça le problème, j'ai récupéré cette DLL sur un PC avec WinXP, cette fois dependancywalker trouve tous les fichiers, mais signale deux ou trois exports de fonctions dans des "delay-load" modules qui sont non résolues notamment une dans MDR.dll, une dans NTDLL.dll et 4 dans Kernel32dll.

Je me demande si finalement le problème ne vient pas du fait que je suis sous Windows 2000...
J'ai vu dans un post sur vbfrance que l'import de MSwinsock fonctionne très vien sous VB2005 s'il est fait depuis le toolbox, je vais installer la version express de vb2005 sur ce même PC et voir si ça fonctionne ou pas.

voilà,

j'ai testé la même manip sur le même PC avec VB2005 express, et là ça fonctionne...
Peut-être que l'importation s'est mal déroulée sous VC++2005 express, je vais recommencer la même manipulation en reconstruisant complètement l'importation, à suivre donc...

J'ai re testé sous visual C++ 20005 express, refait l'importation du contrôle dans la toolbox, créé une nouvelle application avec juste un form et le contrôle posé dedans, (exactement les mêmes manips que sous VB 2005, sans aucune erreur signalée), et là, toujours la même erreur au moment du lancement de l'exe.

Franchement je sèche sur ce problème, peux-être que sous XP ça marche, mais je peux pas tester car je n'ai pas de XP released en SP2 donc pas de VC++ 2005 express sous XP pour le moment.

Si quelqu'un pouvais tester la manip avec VC++ 2005 sous winXP, ça me permettrai de conclure sur ce problème...

La seule vraie solution pour un développeur C/C++ est l'utilisation des sockets.
Cet ocx est un joujou pour scriptologue d'interprété, il ne nous concerne en rien.

ciao...
BruNews, MVP VC++

Je suis partiellement d'accord, mais l'enjeu pour moi était le portage d'un application dont le développement a été commencé avec ce contrôle ( mais pas sous VC++ 2005), et donc d'éviter de perdre du temps à réécrire toute la partie concernant la gestion des sockets initialement traitée par ce contrôle.
Mais vu qu'apparemment je vais devoir passer autant de temps à faire tourner cet ocx sous VC++2005 (pour autant que ça soit possible), je vais me passer de ce contrôle et laisser tomber la résolution de ce problème.