Office: (Office 2007) VBA-Projektschutz per VBA-Code aufheben

Moin,

ich habe ein VBA-Projekt mit Passwort geschützt und möchte nun mittels Update-Datei im Code etwas ändern (die Datei befindet sich auf einem Schiff).

Folgenden Code habe ich gefunden:

Code:

Da bekomme ich aber immer Laufzeitfehler 1004 "Anwendungs- oder objektdefinbierter Fehler".

Ich nehme mal an, dass das an Excel 2007 liegt, mit dem das nicht mehr geht?

Hat jemand vielleicht eine Idee, wie das mit Excel 2007 zu realisieren ist?

Ich weiß, dass das Passwort sowieso leicht zu knacken wäre, ich möchte das aber dennoch gern gesetzt lassen, um die User nicht zu verführen, mal was zu probieren, und hinterher war's keiner (so etwas habe ich zur Genüge an Bord *rolleyes.gif* )

Es wäre toll, wenn es hier eine Lösung gibt.

Viele Grüße
Hartmut

:)

 

Hallo Hartmut,

von VBA verstehe ich nun wirklich kaum etwas. Allerdings glaube ich zu wissen, und damit liegst du mit deiner Vermutung, dass es an deiner XL-Version liegt, richtig, dass es SendKeys seit der 2007er Version nicht mehr gibt.

 

Hallo Günter,

ich glaubte auch, so etwas schon mal gelesen zu haben, finde aber hierüber nichts mehr.

Irgendwie muss es aber dennoch mit diesem Befehl gehen, denn wenn ich diesen Befehl direkt unter Sub Workbook_Open in "Diese Arbeitsmappe" eingebe, wird das Projekt ungeschützt geöffnet.

Das hilft mir allerdings nicht wirklich weiter, denn wenn es da drinnen steht, kann ich das Passwort ja gleich weglassen *Smilie

Das sagt mir aber, dass der Befehl irgendwie doch noch funzt, nur eben nicht aus einer anderen Datei heraus *eek.gif*

Aber vielleicht weiß ja einer von den Profis noch etwas mehr darüber.

Viele Grüße
Hartmut

 

Hallo Hartmut,

ich stimme dem nicht zu.
Code:

 

Hallo Hartmut,

nur mal so am Rande gefragt: Warum muss der Passwortschutz überhaupt programmatisch aufgehoben werden? Auch wenn ich angestrengt darüber nachdenke fällt mir kein Grund dafür ein...

Und von Sendkeys halte ich absolut nichts - aber das darf jeder sehen, wie er will.

Nur so als Gedankenanstoß...

Grüße
EarlFred

 

Hallo Hajo,

leider bekomme ich noch immer den gleichen Fehler.

Zum Verständnis:
Deinen Code habe ich in der geschützten Datei in Modul1 hinterlegt. Ich habe es auch unter "Diese Arbeitsmappe" probiert.

Den Befehl, diesen Code anzusprechen mache ich über eine Schaltfläche der anderen Datei.

Wenn ich Deinen Code direkt in "Workbook_Open" der geschützten Datei unterbringe, ist das VBA-Projekt nach dem Öffnen ungeschützt.
Das bedeutet für mich, dass Excel 2007 den Befehl durchaus kennt, aber das Auslösen aus einer anderen Datei heraus funktioniert (noch) nicht.

Mache ich was falsch? *Smilie

Hallo EarlFred,
ich habe eine mit Makros bespickte Datei an Bord unserer Schiffe, die ständig per Updatedateien (xlsm) (welche ich per Email an Bord schicke) erweitert wird (Tabellen hinzufügen, austauschen, etc.). Um die Übersicht zu behalten, welche Version sich gerade auf welchem Schiff befindet, habe ich einen Splash-Start eingebaut, in dem auch die Versionsnummer enthalten ist. Diese möchte ich nun mit jedem Update gleichzeitig aktualisieren, indem ich im Code die alte Versionsnummer gegen die jeweils neue mittels des Updates austausche.
Einpflegen von neuen Tabellen geht ja auch ohne Passwortschutz aufheben, aber wenn ich gleichzeitig im Code etwas ändern will, komme ich nicht darum herum, den Schutz vorübergehend aufzuheben.

Ein Weg wäre natürlich, einfach auf das Passwort zu verzichten, aber wir haben an Bord immer wieder Leute, die meinen, sie müssten in den Dateien herumspielen. Das führt dann immer unweigerlich zu Problemen, mit denen dann aber ich mich auseinandersetzen muss, das Besatzungsmitglied sagt natürlich nichts, und fährt einfach irgendwann nach Hause *rolleyes.gif*


Das möchte ich mit dem Passwort vermeiden, soweit es eben geht. Knacken kann man das natürlich, das ist mir klar, aber wer diese Energie aufbringt, wird dann auch irgendwann entlarvt und gefeuert, so einfach ist das.

Ich lese immer wieder, dass Profis von SendKeys nichts halten. Warum eigentlich nicht?
Ist es nicht für die Ausführung eines Befehles egal, ob die Zeichenfolge nun "SendKey" genannt, oder ein anderer Befehl hierfür verwendet wird? Ich frage das mal ganz doof, weil sich mir noch erschließt, was gegen SendKeys spricht.

Viele Grüße
Hartmut



Viele Grüße
Hartmut

 

Hallo Hartmut,

Siehe Deine einleitenden Sätze - Du hast ein Problem damit. Ein prima Beispiel.

Sendkeys "drückt eine Taste" - und ein Tastendruck erfordert einen genau definierten Zustand. Es kann ausreichen, dass die Methode versagt oder tut etwas unerwünschtes tut, wenn schon allein eine andere Mappe im Vordergrund ist. Aber das nur ein wild herausgegriffenes Beispiel. Es gibt umgekehrt kaum klar definierbare Zustände, in denen Sendkeys zuverlässig funktioniert. Allein schon ein emsig auf der Tastatur klappernder User kann die Abläufe nachhaltig stören.

Aktualisierbarer Code wäre bei meinem Projekt in einem Add-In. Das ist eine separate Datei (Endung .xla (ab 2007 mit zusätzlichem "m")), die man versenden kann und die die alte Version einfach komplett ersetzt. Damit kannst Du Codemodule einfach austauschen, ohne die Produktivtabellen überhaupt nur zu berühren.
Freilich muss man dann das eine oder andere anpassen, aber wenn man weiß was, ist so ziemlich alles möglich.

Grüße
EarlFred

 

Hallo Hartmut,

hier mal Hajos Beispiel in die Praxis umgesetzt.
Entpacke die zip-Datei in 1 leeres Verzeichnis und starte die x.xlsm.
In diesem Beispiel wir die zu entsperrende Datei 'Y_KW_1.xlsm' geöffnet und ein Makro in dieser Datei aufgerufen, das den vba-Kennwortschutz aufhebt.
Die Datei entsperrt sich also von innerheraus selbst.
Will man daß aus der x.xlsm-Datei machen (oder aus einem AddIn) mit Parameterübergabe für das Kennwort - wird es wesentlich komplizierter
Nur als Stichworte: SendKeys - Windows Vista ff.
Meine Testumgebung: Windows7-32bit, Excel 2010 bzw. 2013

Gruß von luschi
aus klein-Paris

 

Moin Hajo, Fred und Luschi,

irgendwie funzt das alles nicht. (Langsam verstehe ich, was Fred meinte *Smilie )

Ich habe die Dateien entpackt, wie Luschi geschrieben hat, und es läuft.

Dann habe ich Hajos Code wieder in meine Datei gepackt, Luschis Code der X-... auf den Dateinamen angepasst und siehe da..., das Projekt wurde umbenannt, aber das Passwort war nicht zurückgesetzt *frown.gif*

Komisch, nicht wahr?

Ich tüftele nun an einer anderen Variante. Ich versuche gerade, das Aufheben des Passwortschutzes in den Sub "Worbook_Open" mit einzubauen, allerdings abhängig von der Bedingung, ob die Updatedatei geöffnet ist.
Mal schauen, ob's dauerhaft klappt, ich melde mich hierzu wieder.

Gibt es denn wirklich keinen ordentlichen Befehl hierfür? Ich mag's kaum glauben.

Viele Grüße
Hartmut

 

Hallo Hartmut,

verrat uns doch mal, was im 'Workbook_Open'-Ereignis so alles passiert.
Solltest Du hier noch andere Excel-Dateien dazu öffnen, dann kannst Du das mit dem Entsperren total vergessen, weil dann im Vba-Explorer
der Focus auf eine dieser Dateien liegt und somit die Sendkeys-Befehle ins Leere laufen.
Andere Exceldateien können in dieser Instanz schon geöffnet sein, nur im oben genannten Ereignis darf keine weitere Datei zusätzlich geöffnet werden.
Stell doch mal eine Demodatei zur Verfügung, damit wir mal reinschauen können.

Gruß von luschi
aus klein-paris

PS: Der SendKeys-Befehl muß der allerletzte Befehl sein. Wenn das nicht so ist, funktioniert das Entsperren auch nicht!!!

 

Hallo!

Der Code funktioniert nur wenn er aus der Datei heraus ausgelöst wird in der er sich befindet. Möchte man das VBA-Kennwort aus einer anderen Datei heraus aufheben muss man den Code anders aufbauen. Zuerst einmal musst Du solange im Projektexplorer "suchen" lassen bis die gewünschte Datei (ThisWorkbook.Name) markiert/ausgewählt ist. Erst dann das Kennwort senden.

Versuch es mit folgendem Makro. Das muss in der Datei stehen in der der Projektschutz aufgehoben werden soll. Einen Verweis auf die "Microsoft Visual Basic for Applications Extensibility 5.3" setzen. Das Makro dann aus der anderen Datei heraus mit "Application.Run" aufrufen.

BTW:
"die Datei befindet sich auf einem Schiff" kommt mir bekannt vor. Hatten wir nicht mal vor langer Zeit ein ähnliches Problem diesbezüglich? Da ging es um den Zugriff auf die Datei "aus der Ferne"!? Da hat auch etwas nicht so funktioniert wie es sollte.

Gruß, René

 

Siehe "mein" Code. Damit kann man das "Fokus-Problem" umgehen".

 

Hallo Mumpel, Hallo Luschi,

ich fange mal "von hinten" an:

Das mit dem Verweis wollte ich gerade posten, das habe ich nämlich auch gerade gemerkt.
Aber Mumpel, Dein Code gefällt mir auch, ich hatte noch gar nicht daran gedacht, das Öffnen vom Computernamen abhängig zu machen. Ist irgendwie "sexy" und werde ich wohl einpflegen *Smilie

Du hast recht, ich arbeite schon eine ganze Weile an diesem Projekt (mache ich ja so nebenbei). Mittlerweile läuft es auch auf unseren Schiffen, ich möchte es aber natürlich kontinuierlich erweitern und da ich nur alle paar Monate mal um die Welt düse, um die Schiffe zu besuchen, soll das per Update gehen.

Code:

Sieht jemand eine Möglichkeit, wie ich es vermeide, dass der Editor sichtbar wird, wenn ich entsperre, oder sich wenigstens gleich wieder verabschiedet (ohne dass der Schutz wieder gesetzt wird)?

Viele Grüße
Hartmut

 

Du musst doch nur wieder "Alt+F11" senden, damit schließt Du den VBE wieder. Den Schutz setzen kannst Du ohnehin nicht, da der Schutz erst wieder nach erneutem Öffnen der Datei aktiv wird.


Unter Windows 7 hat "mein" Code jedoch eine kleine Fehlfunktion (bei mir). Numlock wird dadurch ein- und ausgeschaltet (liegt wohl an "%{F11}^r{Tab}").

 

Hallo Mumpel,

Dein geposteter vba-Code funktioniert in Win7 so nicht mehr. Die Focus-Schleife ist wirkungslos. Das kann du so testen:
Workbooks.Open "c:\...\...\meineDatei.xlsm"
Call VBAProjektSchutzAufheben

Und schon hast Du die schönste Endlosschleife, denn die Do While-Schleife tut nicht das was sie soll. Der Fokus im Vba-Editor bleibt auf die gerade geöffnete Datei stehen. Durfte nun schon das 3. mal mit der Reset-Taste den PC neu starten. Hier hat MS den internen Sendkeys-Befehl entschärft und wechselt nicht den Fokus im Vba-Editor-Fenster.
Außerdem macht die If-Abfrage nach diesem Befehl alles wieder zunichte und der Vba-Schutz bleibt bestehen:
SendKeys ("%xi" & "VBA-Kennwort" & "{ENTER}{ENTER}"), True

Es darf keinen nächsten Befehl geben nach diesem SendKeys-Befehl.
Morgen teste ich das mal unter Windows 8 & 8.1.

Gruß von Luschi
aus klein-Paris