none
2 erreurs de compilation VBA sous 2007 et 2010 RRS feed

  • Question

  • Bonjour,

    je développe une nouvelle version d'une application qui tourne, depuis Access 97 (plus de 10 ans pour la version 1).

    La dernière version (6.00), date de 2005, et était compatible 2000, 2002 et 2003. La nouvelle se veut également compatible 2007 et 2010.

    ----------- 1er problème, NON bloquant, avec la commande Shell, dans le programme d'installation (écrit en VBA).  Le programme permet d'installer et désinstaller le pilote Amyuni (imprimante PDF programmable), en lançant son programme d'installation (Install.exe) et en lui passant les paramètres requis.

    Par exemple, la désinstallation se fait, sous toutes versions d'Access < 2007, avec :

    Shell Chr(34) & CurrentProject.Path & "\install.exe" & _
                            Chr(34) & " -u -s " & _
                            Chr(34) & PdfPrinterName & Chr(34)

    Sous Access 2007 et 2010, la même commande donne, à l'exécution, une erreur 5 Argument ou appel de procédure incorrect ?

    Elle fonctionne sans problème en remplaçant Shell par un ShellExec !

    Ceci pour info, mais le plus important est la seconde :

    ---------- 2ème problème, BLOQUANT :

    - Les 2 applications *.mdb (application principale + programme d'installation cité plus haut) utilisent une référence à une librairie VBA, compilée en *.mde.

    - l'installation compile et s'exécute sans problème.

    - le programme principal compile et s'exécute sans problème, si j'établis la référence vers le fichier *.mdb (NON compilé) de la librairie.

    - le même, refuse de compiler ou tourner, si je remets la référence vers la librairie compilée en mde ?

    J'obtiens l'erreur "Erreur de compilation.  Mécanisme de bibliothèque d'objets non géré."

    Le compilateur s'arrête, avec highlight sur ".HandleErr", dans :

    Catch:
        With flApp
            Select Case .Error.HandleErr
            Case vbAbort
                Resume Finally
            Case vbRetry
                If .Debugging Then Stop 'DEBUG ONLY
                Resume
            Case vbIgnore, flNone
                Resume Next
            End Select
        End With
    End Sub

    Ce code est mon code d'erreur standard, géré dans la bibliothèque, répété en pied de toutes les routines d'interface (modules de formulaires, d'état ou standards) de l'application (environ 190 fois dans cette application et dans plusieurs dizaines d'autres applis).

    Merci de toute lumière qui pourrait m'aider à mettre le doigt sur une solution viable (je ne souhaite pas distribuer cette librairie sans la compiler en mde) ?

    mardi 7 août 2012 18:00

Réponses

  • Trouvé :o)

    Après diverses tentatives, la suppression d'un paramètre optionnel fait que tout fonctionne et compile, quels que soient le choix d'application et l'état de la librairie (compilée ou non).

    L'ancienne méthode s'appelait :

    '''Public Function HandleErr(Optional ObjectError As ErrObject) As VbMsgBoxResult
    'remplacée par :
    Public Function HandleErr() As VbMsgBoxResult
    

    Je peux vivre sans le paramètre pour l'instant, donc je verrai les détails plus tard si besoin de le réutiliser...

    Tout cela reste bien mystérieux, mon cher Watson ! Un petit bug à vérifier dans le compilateur (VBA ? Access ?) de 2010, peut être ?


    • Marqué comme réponse Aurel Bera jeudi 27 septembre 2012 11:02
    vendredi 10 août 2012 16:40

Toutes les réponses

  • Sorry, j'ajoute un détail important au 2ème problème : contrairement au 1er, il ne se produit QUE sous 2010.

    Il n'y a aucun problème sous Access 2007.

    Merci de votre aide.

    mardi 7 août 2012 18:03
  • Trouvé :o)

    Après diverses tentatives, la suppression d'un paramètre optionnel fait que tout fonctionne et compile, quels que soient le choix d'application et l'état de la librairie (compilée ou non).

    L'ancienne méthode s'appelait :

    '''Public Function HandleErr(Optional ObjectError As ErrObject) As VbMsgBoxResult
    'remplacée par :
    Public Function HandleErr() As VbMsgBoxResult
    

    Je peux vivre sans le paramètre pour l'instant, donc je verrai les détails plus tard si besoin de le réutiliser...

    Tout cela reste bien mystérieux, mon cher Watson ! Un petit bug à vérifier dans le compilateur (VBA ? Access ?) de 2010, peut être ?


    • Marqué comme réponse Aurel Bera jeudi 27 septembre 2012 11:02
    vendredi 10 août 2012 16:40
  • Bonjour Mon Papy...

    Perso pour la référence de libraries au format Access, je travaille avec des MDA (construit d'abord), compilées en MDE et quelle que soit la version d'Access, ça tourne. Avec un AllowByPasskey en plus bien entendu.

    Mais ça n'explique pas ton problème.

    Toutefois, la méthode HandleErr d'où vient-elle ? Le type ErrObject existe toujours mais n'est pas documenté.

    Et j'ai du mal à savoir pourquoi tu procèdes (procédais) ainsi pour monter un gestionnaire d'erreur générique...


    Argy

    jeudi 23 août 2012 13:42
    Modérateur
  • Salut, J-P,

    D'abord, merci de ta réponse que je n'avais pas vue (je viens de réindiquer mon mail pour être notifié ! Tu sais, à mon âge, l'informatique, c'est compliqué :o(

    Sinon, je ne comprends rien à ton histoire de MDA. J'en utilise pour faire des add-ins, alias outils développeurs, sur mon poste, alors qu'il s'agit ici de ma librairie de base, que je livre avec toutes mes applications un peu 'sophistiquées'.  Et surtout, que vient faire AllowBypasskey ???

    HandleErr, avec tout un vaste foutoir de fonctions et d'objets divers, est ma routine de traitement d'erreurs non prévues.  Particulièrement utile en phase de débogage (chez moi) et beta (sur postes utilisateurs), elle va

    - afficher le message d'erreur de diverses manières (MsgBox simple pour l'utilisateur + boîte complète indépendante pour le développeur, s'il est là),

    - l'enregistrer dans le journal avec la pile des appels ou au milieu de la trace complète (si on a mis une trace complète), avec la réponse de l'utilisateur (Abort/Retry/Ignore),

    - le journal partira chez moi par mail, pour un débogage rapide, à la fermeture ou à la réouverture de l'appli

    Ça te va ?

    Porte toi bien, et @+

    Etienne

    mercredi 10 octobre 2012 17:35
  • Merci Etienne,

    Oui, ça me va ;o)

    Je me doutais que c'était un "own error handler"...

    ++


    Argy

    jeudi 11 octobre 2012 08:46
    Modérateur