2017-10-04 8 views
1

J'ai une application Access 2016 qui est distribuée à de nombreux utilisateurs qui ne sont pas des utilisateurs sophistiqués. Ils doivent généralement installer MS Runtime for Access. Malgré des instructions claires, trop d'utilisateurs trouvent toujours que l'application ne s'ouvre pas. Il semble que les objets liés au début ne sont pas présents sur le système. Avec les objets liés non présents, aucun code ne se charge ou ne s'exécute, il n'est même pas possible de donner un bon message d'erreur.Comment détecter la présence d'objets en utilisant VBA dans Access 2016?

Je tente maintenant d'écrire un petit programme dans lequel tous les objets nécessaires à l'application sont liés en retard, ce qui permet de dire quels modules manquent, le cas échéant. Ce que je trouve cependant est que ma méthode de détection échoue même quand je sais que l'objet est présent. Le code ci-dessous est un exemple d'un test pour un objet requis. Ce test échoue toujours et je n'arrive pas à comprendre pourquoi. J'ai environ 7 d'entre eux. Trois semblent fonctionner correctement, mais pas les autres. Existe-t-il une façon différente de coder le "CreateObject"?

Private Sub btnOffice_Click() 
    'Office FileDialog MSO.DLL  Microsoft Office 16.0 Object Library 
    Dim obj As Object 

    On Error GoTo xyzzy 
    Set obj = CreateObject("Office.FileDialog") 
    lblOffice.Caption = "Office module present" 
    Exit Sub 
xyzzy: 
    lblOffice.Caption = officeWarning 
    MsgBox Err.Description 
End Sub 
+0

[erreur 429] (https://msdn.microsoft.com/fr-fr/library/aa231060 (v = vs.60) .aspx) – SeanC

+0

Que signifie 'échoue' - message d'erreur, mauvais résultats, rien arrive? Consultez https://support.office.com/fr-fr/article/FileDialog-Property-8510B02D-E455-44A9-BF38-3787E6D5C8C1. Peut-être 'Set obj = Application.FileDialog (msoFileDialogFilePicker)' – June7

+0

@SeanC J'ai été sur cette liste. Cela ne semble pas s'appliquer. Tous les objets que je teste sont présents et fonctionnent dans mon application principale, où ils sont liés tôt. Pourquoi le CreateObject échouerait-il dans ce contexte? – LostInTheTrees

Répondre

0

Vous essayez de détecter des références rompues. Voici une procédure pour vérifier et signaler les références cassés:

Sub CheckReferences() 
    Dim ref As Reference 

    For Each ref In References 
     If ref.IsBroken Then 
      MsgBox "Broken reference detected: " & vbCrLf & ref.Name & vbCrLf & ref.FullPath, vbOKOnly + vbCritical, "Broken Reference" 
     End If 
    Next ref 
End Sub 
+0

Si un programme ne peut pas démarrer lorsqu'il a brisé des références, comment ce code peut-il être exécuté? – LostInTheTrees

+0

Autrement dit, s'il y a des références brisées, le programme échoue-t-il parce que les références ne peuvent pas être satisfaites ou la première fois qu'une référence brisée est utilisée? – LostInTheTrees

+0

Je ne pense pas que le code fonctionne avec des liaisons tardives (et en cas de problèmes avec des références, il est souvent une bonne idée d'utiliser des liaisons tardives pour se lier à une version d'un objet spécifique). –

0

Le problème ici est que la boîte de dialogue de fichier n'est pas disponible sous forme d'un objet COM séparé, et donc vous ne pouvez pas utiliser pour créer une telle instance CreateObject() .

Toutefois, si vous prévoyez de distribuer votre application sans référence de bureau (et je pense que vous sûr de le faire - même avec l'exécution), vous pouvez modifier le code FileDialog à la liaison tardive:

Par exemple ceci:

Dim f As FileDialog 
Set f = Application.FileDialog(msoFileDialogFilePicker) 
f.Show 
MsgBox "file choose was " & f.SelectedItems(1) 

Devient ceci:

Dim f As Object 
Set f = Application.FileDialog(3) 
f.AllowMultiSelect = True 
f.Show 
MsgBox "file choosen was " & f.SelectedItems(1) 

donc, dans votre cas, le filedialog n'est pas disponible sous forme d'objet COM séparé, mais vous pouvez toujours comme ci-dessus montre ad Optez pour une liaison tardive de toute façon. Cependant, dans mon expérience, il est sûr de distribuer le runtime avec une référence de bureau et donc au moins pour la boîte de dialogue de bureau que vous n'avez pas besoin de liaison tardive. Pour la fiabilité, puisque dans le cas de FileDialog le code de liaison tardive n'est pas une grosse affaire, alors je continuerais la distribution sans la référence de bureau pour le FileDialog et utiliserais la liaison tardive ci-dessus.