Discussion :

[VBLed]

Bonjour, je viens de m'inscrire, étant développeur VB6 depuis de nombreuses années.
Je rencontre un problème très agaçant depuis quelques jours :

J'ai un PC sous windows 10. J'y ai installé mon VB6 et repris mes sources de mon ancien PC sous seven.

Cela ne s'est pas fait sans mal, mais cela s'est fait (s'habituer à W10 !)

Il y a quelques jours, mon VB ne "reconnais plus MSCOMCTL.OCX que j'utilise plus que de raison dans mes progs.

Quand je lance mon .vbp, VB démarre (en mode admin) et affiche : Impossible de charger'' après j'ai toute la série de .log qui me renvoie "La classe MSComctlLib.ListView du contrôle ListView1 n'est pas une classe de contrôle chargée."
Et quand je crée un nouveau projet et veux ajouter MSCOMCTL.OCX, l'IDE plante en mode non admin et affiche pareil Impossible de charger'' (avec les deux apostrophes) en mode admin

Il y a aussi un truc, très souvent quand je charge un vpb, une alerte visual component manager s'ouvre :La méthode '~' de l'objet '~' a échoué

Pourtant j'ai bien cet OCX dans sysWOW64 (il y a MSCOMCTL OCX, OCA, SRG et DEP) l'OCX date du 9/01/2013 et fait 1 070 152 oct, version 6.01.9834

(Je l'ai aussi dans System32 !!!
Dans regedit je vois que les objets du genre imagelist, treeview et consort se réfère à celui qui est dans sysWOW64, mais je trouve aussi une référence à celui qui est dans system32 !!!)

Cet OCX marche très bien sur mon ancien PC (sous seven) avec le même VB et a marché très bien sous ce PC ci (sous W10) depuis décembre dernier

Je l'ai re-régistré (en mode administrateur, sinon _> erreur) avec succès

Quelqu'un a-t-il une idée pour me sortir de ce mauvais pas ?

Cordialement

[l_autodidacte]

Salut et BIENVENU sur DVP.

Une question pareille(ou presque) a été posée ICI.
Essaie de regarder les réponses qui y sont, peut-être que l'une d'elles te vient en secours.

[VBLed]

Salut et BIENVENU sur DVP.

Une question pareille(ou presque) a été posée ICI.
Essaie de regarder les réponses qui y sont, peut-être que l'une d'elle te vient en secours.

Bonjour l_autodidacte
Merci de votre accueil
Je suis un fidèle de VB6 depuis ... je ne me souviens plus
Je n'ai jamais pu migrer vers .net et maintenant je crois que c'est trop tard, en outre je n'ai jamais compris pourquoi MS avait fait tellement de changements, il aurait tout simplement pu faire un IDE ou on peut mélager sans soucis du VB (VB6) et du C++.

Bon, concernant mon problème, j'ai lu le post 8589101
Mon service pack refuse de s'installer, me répondant qu'il n'y a pas de VB sur mon poste ! Grrrr !
Mais je ne suis pas sûr que cela soit vraiment nécessaire puisque les OCX du SP6 sont présent de toute façon.
En outre, avant il y a quelques jours, ça marchait

Mais

je viens de faire un essai. Je crée un .vbp et y insère une copie de MSCOMCTL.OCX que j'ai placé dans le même répertoire, et là ... ça marche
En revanche il ne veux pas de celui (le même) qui est dans sysWOW64.

Bon, quand je regarde le .vbp je vois référencé Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX mais pas d'indication du chemin vers le répertoire du projet, où l'IDE trouve-t-il cette info ?
En revanche, il a créé un MSCOMCTL.OCA dans le répertoire du projet

Merci de m'aider

[unparia]

Bonjour

Mon service pack refuse de s'installer, me répondant qu'il n'y a pas de VB sur mon poste

une question (et je crois qu'elle te rappellera quelque-chose) : sais-tu ce que veut dire "appli vb6.exe tombée d'un camion ?" ?

[VBLed]

Bonjour


une question (et je crois qu'elle te rappellera quelque-chose) : sais-tu ce que veut dire "appli vb6.exe tombée d'un camion ?" ?

Non

[l_autodidacte]

Mais je ne suis pas sûr que cela soit vraiment nécessaire puisque les OCX du SP6 sont présent de toute façon.

Justement, il s'agit d'une mise à jour.

Pour l'appli tombée d'un camion : Il veut dire qu'on ne trouve même pas les morceaux de cette appli, le camion étant très haut.
Autrement dit il te décourage à continuer d'utiliser VB6 et t'incite à passer à autre chose de plus récent.

En outre, avant il y a quelques jours, ça marchait

Peut-être une mise à jour de Windows qui en est la cause !

Bon, quand je regarde le .vbp je vois référencé Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX mais pas d'indication du chemin vers le répertoire du projet, où l'IDE trouve-t-il cette info ?
En revanche, il a créé un MSCOMCTL.OCA dans le répertoire du projet

Quand il s'agit du répertoire courant, il ne l'indique pas.
La référence est lue directement à partir du fichier lui-même et non à partir du registre. Une fois la lecture faite, il crée le fichier .OCA dont le contenu n'est autre que celui du fichier .OCX avec quelques autres infos qu'utilise VB6.
D'ailleurs, j'ai codé une petite Application qui recherche tout ce qui est utilisable dans les fichiers ocx, oca, dll, exe, tlb, pkg ...

[VBLed]

La référence est lue directement à partir du fichier lui-même et non à partir du registre. Une fois la lecture faite, il crée le fichier .OCA dont le contenu n'est autre que celui du fichier .OCX avec quelques autres infos qu'utilise VB6.
D'ailleurs, j'ai codé une petite Application qui recherche tout ce qui est utilisable dans les fichiers ocx, oca, dll, exe, tlb, pkg ...

En tout cas ce que je vois c'est que quand je référence cet OCX (ce n'est pas vrai pour les autres) depuis sysWOW64 ou system32 ça plante, mais depuis le répertoire du projet ça marche
Glups, tout de même

Bon WE

[unparia]

@VBled : l'appli VB6.exe "tombée d'un camion" est une appli "récupérée" sans licence. Et ses service packs successifs éventuels s'en ressentent assez bien.
Re-question, maintenant que tu le sais : ton appli VB6.exe est-elle "tombée d'un camion" ? (Réponse oui ou réponse non)

[VBLed]

@VBled : l'appli VB6.exe "tombée d'un camion" est une appli "récupérée" sans licence. Et ses service packs successifs éventuels s'en ressentent assez bien.
Re-question, maintenant que tu le sais : ton appli VB6.exe est-elle "tombée d'un camion" ? (Réponse oui ou réponse non)

Aucunement !