XL 2013 VBA : modification du code (VBE) du classeur qui exécute le code [tordu]

dionys0s

XLDnaute Impliqué
Bonjour le forum,
Bonne année à tous ! 🥳

Pardon d'avance, c'est un peu long, j'espère que je vais réussir à être clair et limpide.

J'utilise énormément les tableaux structurés (ListObject) pour mes projets. Je les trouve extrêmement pratiques. Bref. Et je passe mon temps à les modifier, déplacer les colonnes, insérer, supprimer et renommer des champs, etc. Et comme ça me fatigue de modifier les appels à ces noms de champ (je n'utilise jamais les index pour manipuler une colonne de ListObject), j'ai mis en place une sorte de mapping des mes tableaux structurés à l'aide de modules de classe :
Si j'ai un ListObject appelé "lsoMachins" (tous mes ListObjects sont préfixés par "lso"), et qu'il a deux colonnes, par exemple "Name" et "Index", j'aurai donc le module de classe nommé exactement comme le ListObject "lsoMachins" suivant :
VB:
Option Explicit

'Permet de pointer vers l'objet ListObject. Générique quel que soit l'objet mappé.
Public Property Get List(Optional ByRef Workbook As Workbook) As ListObject
  dim wks As Worksheet
  If Workbook Is Nothing Then Set Workbook = ThisWorkbook
  For Each wks In Workbook.Worksheets
    For Each List In wks.ListObjects
      If List.Name = TypeName(Me) Then Exit Function 'D'où le fait que je nomme exactement le ListObject comme la classe qui le map
  Next List, wks
End Property

'Noms des champs du ListObject
Public Property Get Name(): Let Name = "Name": End Property

Public Property Get Index(): Let Index = "Index": End Property

J'ai un module de code standard ("basMapping") qui regroupe toutes mes déclarations de classes de ListObject :
VB:
Option Explicit

Public lsoMachins As New lsoMachins
Public lsoChoses As New lsoChoses
Public lsoTrucs As New lsoTrucs
'[etc.]

Ce qui fait que quand je crée mon ListObject, je crée la classe associée et les propriétés qui décrivent les champs de mon ListObject, et quand je code dans un module standard, je n'écris pas
VB:
Set maColonne = Feuille.ListObjects("lsoMachins").ListColumns("Name")
mais
VB:
set maColonne = lsoMachins.List.ListColumns(lsoMachins.Name)

Ce que j'essaie de faire à présent, vu que ça me gonfle de modifier les classes à chaque fois que je fais une modif, c'est de créer une macro qui modifie les classes elle-même.

Le raisonnement est le suivant :
  1. Je parcours les ListObjects du classeur.
  2. Je créé le fichier cls correspondant que j'enregistre dans un répertoire temporaire.
  3. Je crée le Composant VB s'il n'existe pas, sinon je supprime son contenu.
  4. Je met le code dans la classe à partir du fichier créé (CodeModule.AddFromFile).
Le problème c'est qu'Excel crash à l'exécution du code, et je le Mode Arrêt n'est pas disponible, donc je ne peux pas voir pourquoi exactement. J'ai aussi essayé d'autres méthodes d'ajout de code sans création de fichier (CodeModule.AddFromString) mais ça crash tout autant.
J'ai l'intuition que c'est parce qu'on ne peut pas modifier du code d'un VBProject en cours d'exécution (ce dont je ne suis pas sûr), mais du coup j'essaie de trouver un moyen pour "simuler" le fait que ce soit un autre classeur qui exécute le code (alors que ce serait bien exécuté à partir de mon classeur).

J'ai essayé un truc tordu du genre faire une copie du classeur, ouvrir la copie, fermer le classeur, puis modifier le classeur, mais bien sûr ça ne marche pas et ça s'arrête à la fermeture du classeur. Si vous avez une idée, je suis preneur.

Merci de m'avoir lu jusque là.

Bon weekend
 

Discussions similaires

Statistiques des forums

Discussions
311 722
Messages
2 081 930
Membres
101 843
dernier inscrit
Thaly