Mehrdeutiger Name Fehler Unterbinden

  • Excel

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von petaod.

    Mehrdeutiger Name Fehler Unterbinden

    Hallo Ihr wissenden,

    Ich habe mir einen Code geschrieben, der beim Öffnen der Excel Datei spezielle Module durch die aktuellste Version die auf dem Server liegt ersetzen.
    Dies mache ich indem ich dem Modul einen neuen Namen gebe, das neue Modul importiere und anschließend das alte Modul lösche.

    Der Code funktioniert wie er es soll jedoch wirft er natürlich aus, dass die selben Prozedurnamen verwendet werden. Also Fehlermeldung: Mehrdeutiger Name.

    Wie kann ich diese Fehlermeldung kurzzeitig unterbinden, den die überscheidung existiert ja nur für wenige zentel Sekunden.

    Vielen Dank für die Hilfe.

    Hier der Code:

    VB.NET-Quellcode

    1. Public Function Update_Start()
    2. On Error GoTo Ende
    3. Dim objVBComponents As Object
    4. Dim iModul As String
    5. For Each objVBComponents In .VBComponents
    6. Select Case objVBComponents.Type
    7. Case 1, 2, 3
    8. Select Case objVBComponents.Name
    9. Case "A_System", "A_Funktionen", "A_Charts_Style"
    10. iModul = objVBComponents.Name
    11. objVBComponents.Name = objVBComponents.Name & "999"
    12. ThisWorkbook.VBProject.VBComponents.Remove ThisWorkbook.VBProject.VBComponents(iModul & "999")
    13. ThisWorkbook.VBProject.VBComponents.Import (Sys_Pfad & "\" & iModul & ".bas")
    14. End Select
    15. End Select
    16. Next
    18. End With
    20. Ende:
    21. End Function


    Edit:
    Wie ich merke tritt der Fehler nur bei einem Modul auf, indem sich ein Public Enum befindet, auf das übergreifend zugriffen wird. Kommentiere ich dieses Enum aus, funktioniert der Code wie gewünscht.

    Vielen Dank für die Hilfe.

    LG
    Chris

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Hotdogxxxx“ ()

    Wenn das funktioniert, dann habt ihr wohl alle Excel-Sicherheitsfunktionen ausgeschaltet.
    Aber das kann mir egal sein.

    "self modifying code" ist hässlich.
    Ich würde eher den Weg eines zentral verwalteten Excel-AddIns gehen.
    msdn.microsoft.com/en-us/libra…g597509(v=office.14).aspx
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    @petaod: Ich glaube ich muss mich erstmal Entschuldigen. Ich habe dein erstes Posting wohl zu ungenau gelesen und den eigentlichen Inhalt komplett missverstanden. Ich war mir nicht bewusst das ich auch mit Addins arbeiten kann da ich das bisher nie in Erwägung gezogen habe.

    Ich glaube ein Addin stellt genau das dar, was ich eigentlich brauche kenne mich damit aber noch nicht wirklich aus und muss mich erstmal einlesen. Im Grunde geht es darum, dass das selbe Modul in mehreren Exceltabellen in der gesamten Firma eingebunden ist. Das Modul beinhaltet eine Code Sammlung mit der per VBA Grafiken bearbeitet bzw ergänzt werden können. So kann eine Grafik z.B. mit einer Linie für den Durchschnitt erweitert werden oder Labels mit Berechnungen werden automatisch hinzugefügt.

    Diese Code Sammlung wird stetig erweitert und soll entsprechend durch das Updaten des Moduls in allen Excel Arbeitsblätter zur Verfügung stehen. Abgerufen wird diese Codesammlung wieder durch VBA Codes.

    Wenn ich dieses Modul nun in ein Addin einbinde wie greife ich dann auf diesen Code zu? Wie müsste der Code in der eigentlichen Exceldatei aussehen, dass ich auf das Addin zugreifen kann?

    Letztendlich ist ein AddIn eine ganz normale Excel-Datei, deren (Public) Module und Klassen mit Code gefüllt sind.
    Das speicherst du ab an einer firmenweit zugänglichen Stelle mit der Extension .xlam. (z.B. CompanyVbaLibrary.xlam).

    In allen Excel-Dateien, wo du den Code benötigst, trägst du in der IDE als Verweis diese Datei ein.
    Dann kannst du die Methoden und Funktionen ganz normal aufrufen.
    Fertig.

    Ich würde das Projekt der xlam-Datei mit einem Passwort schützen, damit nicht jeder User die Bibliothek überschreiben kann.

    Das Instantiieren von Public Klassen ist etwas tricky und benötigt den Umweg über ein Modul.
    Aber wenn du dann soweit bist, meldest du dich einfach nochmals.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „petaod“ ()

    @petaod Also wie ich ein Addin erstelle und in Excel einbinde ist mir klar aber unklar ist wie ich dann im Modul A der Exceldatei auf das Modul B der Addin Datei zugeife.

    Anstelle von 'Call Modul' muss ich doch sicherlich 'Call Addin Modul' nutzen.

    Edit: Ich glaube ich habe es gefunden.

    VB.NET-Quellcode

    1. Application.run "Makroname" 'Makro muss Public gesetzt sein'


    Gibt es eine bessere/einfacherere Methode alle Public Makros zu importieren damit man die Beschreibung der Makros nutzen kann?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Hotdogxxxx“ ()

    Hotdogxxxx schrieb:

    Anstelle von 'Call Modul' muss ich doch sicherlich 'Call Addin Modul' nutzen.
    Call ist sowieso obsolet.
    Ein Methode ruft man einfach durch deren Namen auf.

    Du kannst die AddIn-Methoden wie lokale Methoden aufrufen.
    Du musst halt in deinem VBA-Projekt einen Verweis auf die xlam setzen.

    Du solltest dein Library-Codeprojekt halt nicht gerade VBAProject nennen, sonst beisst es sich mit dem Standard.
    Für einen eindeutigen Aufruf kannst du auch direkt adressieren:
    <libraryproject>.<module>.<method>
    also z.B.
    MyLib.TestModule.Test
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „petaod“ ()

Facebook
Telefonspende