Live-Forum - Die aktuellen Beiträge
Datum
Titel
28.03.2024 21:12:36
28.03.2024 18:31:49
Anzeige
Archiv - Navigation
1192to1196
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Makro per VBA ändern

Makro per VBA ändern
Dietmar
Hallo zusammen,
ich komme trotz umfangreicher Recherchen nicht wirklich weiter.
Ich betreue ein kleines Abrechnungsprogramm, das von ein paar Leuten genutzt wird.
Es zeigt sich immer wieder mal, dass ich einen VBA-Code inhaltlich ändern muss.
Die Einzeländerung bei den Anwendern ist umständlich und zeitintensiv.
Ich möchte das nun im Rahmen eines Updates tun, indem ich den Anwendern eine Datei zuschicke, die
den ÄnderungsCode per Button-Klick ausführt.
(Für die Änderung von Inhalten der Tabellenblätter nutze ich diese Vorgehensweise bereits; geht gut).
Wer kann mir weiterhelfen?
Nachfolgend der Code, der die Zieldatei aufruft.
Was ich nun benötige ist der Aufruf des inhahtlich zu ändernden Moduls und den Befehl zur Ä _
nderung.
Herzlichen Dank vorab!
Viele Grüße
Dietmar aus Aachen

Option Explicit
Sub VBACode_Aendern()
'Nach Aufruf der Datei "Testdatei01" soll im Modul "Datenübertrag" Text geändert werden
'Die aufzurufende Datei UND die VBA Ebene sind passwort geschützt
'>>> Aufrufen der Datei in der das Modul inhaltlich geändert werden soll >> Hier soll der Code zur Änderung des Moduls "Datenuebertrag" folgen >> Schließen der "Testdatei01" mit dem geänderten Code >> Schliessen der Datei die die Änderungen veranlasst hat OHNE sichern 

AW: Makro per VBA ändern
06.01.2011 10:12:56
Hajo_Zi
Hallo Dietmar,
Dir ist schon klar das der Zugriff auf das VBA Projekt erlaubt sein muss?

AW: Makro per VBA ändern
06.01.2011 10:32:53
Dietmar
Hallo Hajo,
herzlichen Dank für die schnelle Rückmeldung!
Ja, das ist mir klar.
Da ich das Rechenprogramm aber selbst gemacht habe (wobei ich sagen darf: Dank der tollen Unterstützung hier bei herber.de), kenne auch nur ich den ZugriffsCode auf die VBA-Ebene.
Diesbezüglich ist also alles im Lot.
Ich bin sehr gespannt, wie das geht :-)
Liebe Grüße
Dietmar
Zugriff VBA-PW
06.01.2011 11:48:39
Rudi
Hallo,
geht nur mit SendKeys.
Für XL5-10 (XP) so:
Sub VBA_Kennwort(strPW)
SendKeys ("%{F11}"), True
If Application.VBE.activevbproject.Protection Then
Select Case Val(Application.Version)
Case 5 To 8
SendKeys ("%xs" & strPW & "{ENTER}{ENTER}"), True
Case 9 To 10
SendKeys ("%xi" & strPW & "{ENTER}{ENTER}"), True
SendKeys ("%q"), True
End Select
End If
End Sub

Ob das auch in 2003 (11) so geht, weiß ich nicht. Musst du testen (9 To 10 in 9 To 11 ändern)
Gruß
Rudi
Anzeige
AW: Zugriff VBA-PW
06.01.2011 13:06:58
Dietmar
Hallo Rudi,
vielen Dank für Deine Mühe.
Die Überbrückung des PW im VBA-Code ist ja nur die eine Hürde.
Mit ging es ja insbesondere auch darum, ein VBA-Modul inhaltlich zu verändern.
Viele Grüße
Dietmar
AW: Makro per VBA ändern
06.01.2011 12:08:56
Luschi
Hallo Dietmar,
ich hatte mir zu diesem Zweck ein Excel-AddIn gebastelt, der diese von Dir beschriebenen Aufgabenstellungen durchführt. Auch das Aufheben des Vba-Kennwortschutzes und der Vba-Code-Austausch war/ist darin integriert.
Aber leider nur bis Windows XP. Ja Du liest richtig - n i c h t MS-Office macht die Probleme, sondern das Betriebssystem. Ab Vista/Windows7 wird der dazu notwendige Befehl 'Application.Sendkeys' auf Vba/Vbe-Ebene nicht mehr korrekt ausgeführt. Habe dazu z.Z. leider keine Lösung parat.
Und es nützt das AddIn nichts, wenn Du mit WinXP arbeitest und die Kunden längst auf Vista/Win7 umgestiegen sind.
Ich suche z.Z. eine Lösung per API-Funktionen, um den SendKeys-Befehl sauber zu imitieren.
Gruß von Luschi
aus klein-Paris
Anzeige
AW: Makro per VBA ändern
06.01.2011 13:11:19
Dietmar
Hallo Luschi aus kl. Paris,
vielen Dank für die Info!
Die Aufgabe scheint ja komplexer zu sein als ich dachte.
Und wenn ich bedenke, dass meine Kunden durch die Bank unterschiedliche Betriebssysteme haben (von XP bis Windows7 ist alles dabei) dann kann ich das wohl vergessen.
Oder kann ich noch hoffen?
Liebe Grüße
Dietmar aus Aachen
Da wird es wohl am einfachsten sein,...
06.01.2011 14:18:27
Luc:-?
…Dietmar,
1. generell unterschiedl Versionen (Vss) für unterschiedl BS (OS) u.Xl-Vss anzubieten und …
2. als Update eine komplette neue Vs zuzusenden, die die alte ersetzt.
Das machen andere Hersteller gelegentlich auch so, besonders, wenn es sich um keine originäre Software, sondern (nur) spezifische Anwendungen einer solchen handelt.
Gruß Luc :-?
Anzeige
AW: ja, aber ...
06.01.2011 14:32:15
Dietmar
Hallo Luc,
vielen Dank für Deinen Beitrag.
Das Probem ist, dass ich meine Kunden mit einer neuen Anwendung ziemlich vergraulen würden, weil es in meiner Anwendung Tabellenblätter mit Daten gibt, die Seitens der Kunden einzutragen waren (Produktbestände) und eine Statistikseite, die zurückliegende Buchungen notiert.
Ich hatte bei Bernd Held dazu mal ein Beispiel gesehen, das mit
Const SuchText = "ZuÄndernderText"
Const ErsetzText = "GeÄnderterText"
und dann mit
Set VBCodeMod = ThisWorkbook.VBProjekt.VBComponents ("Modul_XY".CodeModul
gearbeitet hat und hatte gehofft, dass ich es damit hinbekommen kann ...
Nur verstehe ich davon leider zu wenig.
Ich hoffe sehr, dass es irgendeinen schlauen Weg gibt :-)
Viele Grüße
Dietmar
Anzeige
das Kind ist wohl ....
06.01.2011 14:43:57
Rudi
Hallo,
...im Brunnen gelandet ;-)
dass es irgendeinen schlauen Weg gibt 

Der schlaue Weg wäre gewesen, Daten und Programm zu trennen. Daten in einer Mappe und Prog in einem Addin, das von der Mappe aufgerufen wird. Dann bräuchtest du nur das Addin zu verteilen.
Ist jetzt aber zu spät.
Gruß
Rudi
AW: stimmt leider
06.01.2011 14:59:18
Dietmar
Hallo Rudi,
das ist mir nun auch klar geworden.
Das werde ich zukünftig ganz sicher anders machen !
Danke und viele Grüße
Dietmar
AW: das Kind ist wohl ....
06.01.2011 15:52:48
Luschi
Hallo Rudi,
so ganz stimmt diese Theorie leider auch nicht, denn wie willst Du die Ereignisroutinen der Arbeits-Tabellen in dem AddIn abbilden. Bestimmte Eingaben des Users müssen schon auf Plausibilität geprüft werden, um den Datenkollaps zu verhindern. Und wenn sich da etwas ändert, steht man genau wieder vor dem selben Problem wie jetzt.
Man kann die Möglichkeiten bei Access (klare Trennune von Daten und Programmlogik) nicht in Excel 1:1 umsetzen. Da es in Excel auch keine Unterformulare gibt, ist die Dateneingabe über AddIn-Formulare doch sehr eingeschränkt/programmieraufwändig.
Gruß von Luschi
aus klein-Paris
Anzeige
AW: das Kind ist wohl ....
06.01.2011 16:29:08
Rudi
Hallo,
Ereignisroutinen der Arbeits-Tabellen in dem AddIn abbilden

Der Einfachheit halber mit einer Klasse der Application im Addin.
Aufwändig aber machbar.
Ein anderer Weg wäre, mit 2 Mappen zu arbeiten. Eine als Oberfläche+Progs, die andere (evtl. ausgeblendet) nur Tabellen.
Gruß
Rudi
Ja, Rudi! Wenn man will, geht (fast) alles.
06.01.2011 17:01:48
Luc:-?
Voraussetzung ist allerdings, vorher darüber nachzudenken, wie das Ganze am besten zu organisieren ist. Ich denke, das ist fast jedem mal passiert → drauflos programmiert und dann…! ? ;-)
Gruß Luc :-?
AW: ja, aber ...
06.01.2011 15:33:23
Luschi
Hallo Dietmar,
das 'A & O' ist das Aufhebeln des Vba-Kennwortschutzes, beim Rest tausche ich alle Klassenmodule(Tabellen- und sonstige Klassenmodule), Formulare und normale Module komplett aus und nicht einzelne Vba-Codezeilen. Bei ca. 8500 Vba-Code-Zeilen und 10-15 Formularen dauert dieser Prozeß weniger als 10 Sekunden. Da die Daten des Anwenders nicht angefaßt werden dürfen, ist dies die einzige Möglichkeit, Programmierfehler zu beseitigen und -neuerungen in die Kunden-Excel-Datei zu bekommen; vor allem auch neue Ereignisroutinen in den Tabellen.
Ich will mich am WE nochmals mit dem Vba-Kennwort-Schutz beschäftigen. Wenn das lösbar ist, stelle ich das AddIn hier zur Verfügung.
Gruß von Luschi
aus klein-Paris
Anzeige
AW: ... das ABER macht Hoffnung ...
06.01.2011 15:54:02
Dietmar
Hallo Luschi,
DANKE für den Funken Hoffnung!
Das wird mir jedenfalls nicht mehr passieren!
Ich werde zukünftig nur noch so arbeiten, dass Programm und Daten getrennt werden.
Da hat Rudi schlicht recht.
Dennoch wäre ich sehr froh, wenn es einen Weg gäbe, die nun auf dem Eis taumelde Kuh da runter zu holen :-)
Meine derzeit ausgelieferte Programm-Variante ist erst seit Dez. raus und ich muss das daher erst einmal so lassen.
Ein Rückruf ist undenkbar.
Daher wäre ich froh, wenn Du das Problem mit dem Kennwortschutz für die VBA-Ebene lösen könntest.
Mir ist auch bewusst, dass dieser Schutz bei Profis keine wirkliche Hürde ist, aber für meine User (auch die etwas VBA-Bedarften) hat es gelangt. Und da ich meine Arbeit so gut wie möblich schützen wollte, habe ich halt einen Zugriffs-Schutz eingebaut.
Ich bin gespannt obs klappt :-)
Viele hoffnungsvolle Grüße
Dietmar
Anzeige
AW: ... guck mal, meine Idee
06.01.2011 16:43:02
Dietmar
Hallo Luschi,
schau mal.
Ich hab da was gebastelt.
Das Makro läuft ohne zu haken durch (trotz PW-Schutz der VBA-Ebene) ... nur ändert es den Text im Modul 2 der Zieldatei nicht.
Wäre das ein Ansatz?
Viele Grüße
Dietmar
Option Explicit
Sub TextAustauschen()
'>>> Zieldatei öffnen >> Text in Modul 2 der Zieldatei ändern 

AW: Noch `n Idee alternativ
07.01.2011 11:52:38
Franz
Hallo Freunde,
darf ich mich "reinmischen"?
Falls die Namensbereiche und die Tabellenmamen immer konstant bleiben, kann es auch so gehen:
1.- Eine Arbeitsmappe als UPDATER deklarieren wo sämtliche neuen VBA-Module stehen. Diese Mappe sollte Dummywerte beinhalten und die gleichen Namensvariablen wie bisher.
2. Mit folgenden (Teil)codezeilen als Beispiel die Bereiche einzeln übertragen:
Option Explicit
Global wbSource As Workbook
Global wbTarget As Workbook
Global sSheet As String
Global rngError As String
Private Sub Cop(rng As String)
rngError = rng
'Workbooks("OldSheet.xls").Worksheets("SheetNameXYZ").Range("cellXYZ").Copy Workbooks(" _
Updater_is_new_Sheet.xls").Worksheets("SheetNameXYZ").Range("cellXYZ")
wbSource.Worksheets(sSheet).Range(rng).Copy wbTarget.Worksheets(sSheet).Range(rng)
End Sub

Set Befehle wbSource und wbTarget vornehmen
…..
sSheet = "Einstellungen"
Call Cop("cellPerBegin")
Call Cop("cellPerEnd")
Call Cop("cellStatus")
Call Cop("lboxYNCheck")
sSheet = "Journal Kopf"
Call Cop("A1:N1")
Call Cop("cellTxtLimAcc")
Call Cop("cellTxtLimCat")
Eine ERRORHANDLER Routine muss noch ergänzt werden.
3.- UPDATER.XLS umbenennen in ZIELDATEI.XLS wenn „erfolgreich“ attestiert.
Bei mir funktioniert so etwas ganz stabil.
Tschüss!
Franz D.
Anzeige
AW: danke für's einmischen :-)
08.01.2011 08:59:27
Dietmar
Hallo Franz,
herzlichen Dank für Dein "Einmischen".
Es zeigt mir, dass es zur Thematik wahrscheinlich eine Lösung geben wird.
Da ich von VBA nicht genug verstehe, um Deine Idee in meinen Code einzubrauen, werde ich aber auf das Feedback von Luschi warten, der sich übers WE etwas ausdenken wollte.
Lieben Dank und ein schönes WE
Gruß
Dietmar
Na dann Prost! ;-) Gruß+schöWE! owT
08.01.2011 15:51:15
Luc:-?
:-?
AW: danke für's einmischen :-)
11.01.2011 11:43:07
Luschi
Hallo Dietmar,
habe das Problem mit dem Aufheben des Vba-Kennwort-Schutzes für WinXP, WinVista & Win7 gelöst.
Habe aber die Vermutung, daß Du diese Lösung nicht in die aktuelle Aufgabenstellung einarbeiten kannst.
Wie soll es jetzt weitergehen?
fragt sich Luschi
aus klein-Paris
PS: für jeden Interessierten zeige ich die Lösung in 3 Tagen; brauche noch ein paar Tests!
Anzeige
AW: Danke, brennend interessiert
11.01.2011 13:06:39
Dietmar
Hallo Luschi,
estmal ein dickes DANKE! für Deine Mühe.
Ich kann zu Deiner Vermutung so erst einmal nichts sagen, da ich gar keine Ahnung habe, wie Du die Problematik gelöst hast.
Ich bin aber in jedem Fall an Deiner Problemlösung brennend interessiert !
antwortet
Dietmar aus Aachen :-)
Wozu bloß die ganze Mühe oder hat MS inzwischen...
12.01.2011 04:05:08
Luc:-?
…was für „normales“ VBA und gg die „offene“ Konkurrenz unternommen? Für MS sind wir in C#- und DotNet-Zeiten mit unserer „Vorliebe“ für „klassisches“ VBA eh nur „IT-Hinterwäldler“, Leute…
Gruß Luc :-?
AW: ok, das hilft aber auch nicht wirklich weiter
12.01.2011 14:35:35
Dietmar
Hallo Luc,
Du magst ja recht haben - aus objetkiver, übergeordneter oder einfach nur subjektiver Sichtweise.
Die Frage ist doch aber, welche Möglichkeiten habe ich, was kann ich und was will ich.
Dass ich nur ein kleiner "Bastler" bin, ist schwerlich zu erkennen, aber als Hobby reicht es mir und fasziniert mich immer wieder.
Wenn ich mehr gewollt hätte, hätte ich die Thematik studiert und würde heute vielleicht auch über die Welt der Endanwender von MS-Massenprodukten milde lächeln.
Solltest Du mit Deinem Einwand eine Ausschließlichkeits-Feststellung getroffen haben, frage ich mich, ob dieses Forum noch sinnvoll wäre.
Hinterwälderler hin oder her ... das Glück liegt nicht alleine bei denen, die meinen, es nicht zu sein :-)
Ich jedenfalls genieße mein Hobby und freue mich über die zahlreichen Hilfen, die ich hier erhalten habe. In meinem Kollegenkreis weiß jeder, dass dieses Forum kompetent, freundlich und engagiert ist. Wäre schade, wenn es eines Tages nur von Nicht-Hinterwäldlern genutzt würde ...
... wollte ich nur mal so gesagt haben.
Viele Grüße
Dietmar aus Aachen

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige