Vous cherchez peut-être au mauvais endroit pour l'erreur. Lorsque vous modifiez la propriété Text d'un ComboBox, l'événement Change de ComboBox se déclenchera, si le nouveau texte est différent du texte précédent. Les événements LostFocus et/ou Validate peuvent également se déclencher, en fonction de l'action de votre code et de la configuration de votre formulaire.
Si une erreur se produit dans le gestionnaire d'événements Change (ou dans les LostFocus ou Validate gestionnaires d'événements, si vous faites quoi que ce soit avec eux), le code de gestion des erreurs dans le code qui modifie le texte combobox sera jamais get appelé (cela a à voir avec comment la gestion des erreurs et les événements fonctionnent dans VB6). En règle générale, vous devez toujours mettre un gestionnaire d'erreurs dans chaque routine (Sub, Function ou Property) dans votre code VB6, car vous ne pouvez jamais être sûr que vous allez attraper toutes les erreurs dans le cas contraire.
Voici un exemple rapide qui montre que la gestion des erreurs peut ne pas toujours fonctionner comme vous le pensez dans VB6.
Créer un nouveau projet EXE standard et ajoutez un bouton de commande (Command1) et une zone de liste déroulante (Combo1) à la forme par défaut, et ajoutez le code suivant au formulaire:
Private Sub Combo1_Change()
Dim a As Long
a = 1/0 '<-- this will cause a divide-by-zero runtime error'
End Sub
Private Sub Command1_Click()
On Error GoTo MyErrorHandler
'Change the combobox text.'
'This will cause the Change event to fire'
Combo1.Text = "test"
Exit Sub
MyErrorHandler:
'This code will not be executed if an error occurs in Combo1_Change...'
MsgBox "My error-handler called."
End Sub
Si vous compilez le projet et exécutez l'EXE résultant, vous obtiendrez une erreur d'exécution chaque fois que vous cliquez sur Command1 et le programme se terminera. Cela est dû au fait que le code de gestion des erreurs qui a été ajouté (MyErrorHandler dans l'exemple) n'est pas appelé. Toutefois, si vous ajoutez un code de gestion des erreurs au gestionnaire d'événements Combo1_Change, vous pouvez intercepter l'erreur et essayer de la traiter (à tout le moins, vous pouvez empêcher le programme de se bloquer). Par conséquent, je m'assurerais que chaque procédure événementielle comporte un code de gestion des erreurs, et je l'ajouterai si elle est manquante. Cela devrait faciliter la localisation de l'erreur. Par exemple, si vous avez du code dans la procédure événementielle cmbAIDFile_Change, assurez-vous qu'il comporte une gestion des erreurs. J'ajouterais aussi des numéros de ligne à votre code (si vous ne les avez pas déjà): de cette façon, vous pouvez utiliser Erl dans votre code de gestion des erreurs pour obtenir le numéro de ligne où l'erreur s'est produite. Voir le code suivant pour un exemple de la façon d'enregistrer les numéros de ligne dans vos messages d'erreur.
En utilisant Erl signaler les numéros de ligne dans les messages d'erreur
Private Sub cmbAIDFile_Change()
1000 On Error Goto ErrorHandler
1010 DoSomething
1020 DoSomethingElse
ErrorHandler:
1030 Dim sErrMsg As String
sErrMsg = "A fatal error occurred." & vbCrLf & vbCrLf & _
"Method: cmbAIDFile_Change" & vbCrLf & _
"Line: " & Erl & vbCrLf & _
"Err.Number: " & Err.Number & vbCrLf & _
"Err.Description: " & Err.Description
1040 MsgBox sErrMsg, vbCritical+vbOKOnly, "Fatal error"
End Sub
Une fois que vous avez une erreur de manipulation plus fine en place, vous pouvez commencer à comprendre pourquoi vous voyez un problème sur une seule machine , parce que vous devriez avoir beaucoup plus d'informations fiables sur l'erreur qui se produit, et être dans une meilleure position pour comprendre quelle est la cause première.
Je l'ai découvert il le fait avec une zone de texte aussi, mais juste cette machine. – Tony
Etes-vous certain que le problème ne se trouve pas dans GetSettings? Vous pouvez essayer d'ajouter le résultat de la fonction à une variable temporaire à findout qui provoque le problème. –
Oui, essayé cela. GetSettings va bien. – Tony