1. #1
    Membre régulier
    Profil pro
    Inscrit en
    juin 2007
    Messages
    269
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2007
    Messages : 269
    Points : 118
    Points
    118

    Par défaut Projet qui ne charge plus les OCX si on change le nom ou l'emplacement du dossier des sources

    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

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    juin 2007
    Messages
    269
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2007
    Messages : 269
    Points : 118
    Points
    118

    Par défaut

    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

Discussions similaires

  1. Top 10 des raisons qui agacent le plus les utilisateurs de PC
    Par Hinault Romaric dans le forum Actualités
    Réponses: 28
    Dernier message: 19/02/2014, 17h12
  2. Réponses: 2
    Dernier message: 04/10/2010, 12h13
  3. Projet qui n'est plus connecté au SVN
    Par ziad.shady dans le forum Eclipse
    Réponses: 2
    Dernier message: 10/03/2010, 10h11
  4. Graveur dvd qui ne lit plus les cd-rw
    Par Hyoga dans le forum Autres Logiciels
    Réponses: 3
    Dernier message: 18/02/2006, 21h42
  5. Qui ne voi plus les images ou smiley du forum ?
    Par Marc Lussac dans le forum Evolutions du club
    Réponses: 30
    Dernier message: 13/09/2004, 14h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo