Discussion :

[electroremy]

Bonjour,

Problème bizarre avec VB5

Si je renomme le dossier où se trouve mon projet ou si je le déplace, mon projet ne se charge plus ; plus précisément VB ne charge plus mes OCX

Les OCX que j'utilise sont dans le même dossier que mes sources (les .frm, les .frx, les .bas, le .vbp, ect...)

Bizarre ni dans le .VBP ni dans les .FRM je ne trouve le chemin de mes OCX (ce qui expliquerai le bug...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Type=Exe
Object={5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0; MSFLXGRD.OCX
Object={6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0; SYSINFO.OCX
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\Windows\system32\stdole2.tlb#OLE Automation
Form=CiDess.frm
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
VERSION 5.00
Object = "{6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0"; "SYSINFO.OCX"
Begin VB.Form CiDess 
   BackColor       =   &H00C0C0C0&
   Caption         =   "CiDess"
   ClientHeight    =   6045
   ClientLeft      =   60
   ClientTop       =   750
   ClientWidth     =   9345
   Icon            =   "CiDess.frx":0000
   LinkTopic       =   "Form1"
   ScaleHeight     =   6045
   ScaleWidth      =   9345
   Begin SysInfoLib.SysInfo PC_Info 
      Left            =   4380
      Top             =   2760
      _ExtentX        =   1005
      _ExtentY        =   1005
      _Version        =   327681
   End
...

Auparavant j'avais résolut ce problème qui est peut être lié : https://www.developpez.net/forums/d1...en-etre-admin/

Alors j'ai essayé, à tout hasard, de supprimer les fichiers .manifest mais sans effet

Je pense que la solution est d'indiquer à VB5 que mes OCX sont dans le répertoire racine de mes sources mais comment faire ???

Car en remplaçant par exemple
Object = "{6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0"; "SYSINFO.OCX"
par
Object = "{6FBA474E-43AC-11CE-9A0E-00AA0062BB4C}#1.0#0"; "C:\ProgsVB5\Cidess\SYSINFO.OCX"
ça ne marche pas non plus...

Encore plus étrange : le .EXE que j'avais généré précédemment fonctionne parfaitement !

Le soucis vient donc de ce qu'il y a dans les sources mais ou ?

Merci

à Bientôt

[electroremy]

Bonjour,

quelques recherches dans la langue de Shakespeare se révèlent intéressantes :

Once an OCX has been registered you can't move it because the registry contains its location.

It is very poor practice to dump such libraries into System32, which is really only for Microsoft-created libraries. A 3rd party library should normally be put into a location such as:C:\Program Files\Common Files\{creator/app name}

Placing them "next to" an EXE results in all sorts of problems as has been explained here many, many times. Your problem sounds like this very mistake has been made.

If an OCX is "private" to an application (never used by any other programs) it is safe to put it into a subfolder under the EXE's folder but never in the same folder as the EXE! Then you manually register it.

Of course if you ever want to delete or move the library you still have to unregister it first.

This registration-by-first-run is a sort of "dufus mode" meant to make things easy for the average slob but it has lots of negative consequences. I guess the idea was you'd be reinstalling Windows before long anyway.

The hazard of the "next to" scenario is that on first run of your VB6 EXE the runtime will locate the library via DLL Search and call its self-registration entrypoint. Now it is registered globally as living in this exact place in the filesystem. It has been published for use by any other program.

If you ever move it or remove the file you'll have a broken component registration in your system's registry. This breaks your program and any other program that happens to use it. The only "fix" is to put the file right back where it was when it got registered.

With your system in the screwed up state that it apears to be now, you'd have to put that file back where it was the first time it was used. Then you could unregister it, delete the file, and put it into a proper permanent location and then register it there.

Barring that (no idea what the folder was?) you'd have to go in with RegEdit and cut out all of the orphaned entries. Alternatively you might try to track down every place where the original file path is in the registry and edit those to reflect the new location.

This is frought with perils unless you know what you are doing.


When somebody makes a compiled VB6 DLL or OCX available for other people to develop programs with they are supposed to include the library itself, a .DEP file, and optionally a .CHM Help file. These are supposed to be bundled as an installer to put the files into their proper places (NOT System32).

When they only provide source it is up to you to deal with proper compiling and installing of such libraries.

Stay away from sites like POS-Code. If you lie down with dogs, you'll come up with fleas. The file had probably been named as a .txt file for a reason. Precompiled binaries probably violate even their lax quality guidelines and it was probably done to fool their uploaded file scanner.

Alors ceci est vraiment, vraiment ennuyeux...

Placer les .OCX avec le .EXE et utiliser des fichiers .manifest était une bonne solution pour rendre l'application "étanche" et autonome par rapport au système : autrement dit, mon programme :
- utilise uniquement les OCX fournis avec
- n'utilisera pas d'éventuelles autres OCX de version différentes installées sur le système
- ne nécessite pas d'installation, est "portable" et donc ne modifie pas la configuration d'un ordinateur (chose appréciée par de nombreux utilisateurs)

Mais cela ne correspond pas à la philosophie de VB5 qui cherche à tout prix à enregistrer les OCX dans le système

Comment procéder pour faire en sorte que les OCX utilisées par mon programme soient considérées et restent "locales" ?

Beaucoup de gens le disent : le mieux est de ne plus utiliser d'OCX !

J'avais d'ailleurs commencé dans cette voie, en faisant mes propres boîtes de dialogue pour ne plus utiliser ComCtl32.ocx

Pour SYSINFO je pourrais le faire probablement, en effet je n'utilise cette OCX uniquement pour récupérer 4 valeurs :
.WorkAreaLeft
.WorkAreaTop
.WorkAreaWidth
.WorkAreaHeight

Ca doit pouvoir se faire avec une API, sans utiliser l'OCX...

Mais pour remplacer MsFlexGrid ça va être beaucoup plus ardu... car refaire un contrôle équivalent "maison" :
- sans que ça rame
- sans que ce soit une "boucherie" au niveau de l'affichage quelque soit la version de windows et le thème
- gérant correctement la navigation et la saisie à la souris et au clavier


Bref les OCX sont de jolis cadeaux mais un petit peu empoisonnés quand même

A bientôt