Mit VB: Com-AddIn ActiveX-Dll

Computer: Software & Programmierung Visual Basic
#1

Hallo Wissende,

kann man mit VB6 ein Com-AddIn oder/und ein ActiveX-Dll erstellen?

Mir geht es darum, meinen Excel-Vba-Code zu schützen und das geht mit beidem soweit ich weiß.

VB6 steht auf meinem Wunschzettel an den Weihnachtsmann z.B. wegen ocx-Erstellung, derzeit habe ich VB5, kann ich damit ein Add-In kompilieren oder so eine Dll erstellen?

In Excel kann ich ein normales Add-In erstellen, das ist aber nicht kompiliert. Ich weiß grad garnicht ob VB überhaupt Add-Ins kennt und falls ja, auch Excel-Add-Ins kennt.

Ich habe eine Anfrage zum Thema auch woanders gestellt, ist aber kein Crossposting, was bei w-w-w eh egal ist, aber mir wichtig, jedenfalls habe ich dort gefragt wie man die Dinger erstellt, hier frage ich ob VB das kann, ein Himmelweiter Unterschied *find* :smile:

Bislang bekam ich als Antwort darauf von Tino dieses:

http://www.herber.de/forum/archiv/1000to1004/t100055…

und er schreibt ja da „habe ich mal eine *.dll unter VB6 erstellt.“, insofern weiß ich daß dies mit VB6 geht, aber geht das auch mit VB5 und wie?

Als Info wegen Filesearch, alle Versionen von Excel-Vba kannten Filesearch, damit konnte/kann man Verzeichnisstrukturen nach Dateien absuchen. Neben einigen anderen Dingen gibt es das in Excel2007 nicht mehr, d.h. alle Codes die jahrelang liefen und Filesearch beinhalten kannste in die Tonne kloppen, außer du programmierst Filesearch selbst neu als Funktion.

Danke^ Gruß
Reinhard

#2

Hallo Reinhard,

kann man mit VB6 ein Com-AddIn oder/und ein ActiveX-Dll
erstellen?

ja, aber erst ab der Pro-Edition. Mit VB6.0 Standard nicht.

VB6.0 Professional bietet:

Standard-Exe
ActiveX-Exe
ActiveX-DLL
ActiveX-Steuerelement (OCX)
VB-Anwendungs-Assistent
VB-Assistenten-Manager
ActiveX-Dokument-Dll
ActiveX-Dokument-Exe
Addin
Datenprojekt
DHTML-Anwendung
IIS-Anwendung
VB Pro Edition-Steuerelemente

Frag jetzt aber bitte nicht, was sich jeweils im Detail dahinter verbirgt, außer Standard, VB Pro und den Steuerelementen habe ich noch nichts davon genutzt. :smile:

Gruß Rainer

#3

kann man mit VB6 ein Com-AddIn oder/und ein ActiveX-Dll
erstellen?

ja, aber erst ab der Pro-Edition. Mit VB6.0 Standard nicht.

VB6.0 Professional bietet:
…
ActiveX-DLL
Addin
…

Frag jetzt aber bitte nicht, was sich jeweils im Detail
dahinter verbirgt, außer Standard, VB Pro und den
Steuerelementen habe ich noch nichts davon genutzt. :smile:

ich habe nur aufgeschnappt, um seinen Excel Vba-Code zu schützen soll man entweder ActiveX-Dll oder Com-Add-In benutzen.

So wie es mir erscheint kann also Vb6.0 ActiveX-Dll erstellen, ob mir das weiterhilft weiß ich nicht. eher nicht, wie soll VB aus meinem Excel-Vba-Code mit Funktionen die VB6.0 gar nicht kennt da eine ActiveX-Dll erstellen?

Dann dürfte ich ja da nur Befehle benutzen die VB auch kennt, wenn nicht müßte ich immer mit CreateObject(„Excel-Application“) o.ä. „arbeiten“.
Irgednwie nicht das Wahre.

In Excel sind Add-Ins letztlich nur normale Exceldateien, lassen wir mal unwichtige Kleinigkeiten weg.

Ein Com-Add-In soll etwas anderes sein und zwar ein vorkompiliertes Add-In.

Denn ein normales Excel-Add-In ist genauso lächerlich geschützt gegen Auslesen wie eine mit Passwort geschützte Exceldatei.

Natürlich ist letztlich sehr wenig „sicher“. Du kannst als Beispiel eine exe mit Vb basteln die beim Start immer abprüft, ob sie schon länger als 30 tage benutzt wird usw.

Wenn ich viel Zeit und Mühe aufwende, Disassembler-Tools benutze, so kann ich mehr oder minder leicht die entsprechenden Bytes in der Exe finden und neutralisieren.

Einen Schutz dagegen brauche ich ja gar nicht, will ja meinen Code nicht gegen den CIA schützen, sondern nur dagegen daß ein Normaluser mit ein bißchen Googlesuche meine Passwörter in Excel, z.B. das für den Vba-Code aushebelt und den Code liest.

Wenn der Vba-Code in so einer dll oder so einem Com-Add-In steckt, hat „er“ es nicht so leicht.

Sorry, daß ich dir die Ohren äh Augen zumülle :smile:, ich wollte nur mal verständlicher machen warum ich an ActiveX-dll und einem Com-Add-In, genauer wie ich die aus Excel-Vba-Code erstelle, interessiert bin.

Mir ist schon sehr klar, hätte ich gefragt wie ich ein ActiveX-Dll in Vb6.0 erstelle hättest du sagen können wie das geht, zur Not Step by Step. Leider habe ich meine Zweifel daß ich dies dann auch mit Excel-Vba umsetzen könnte und vor allem wie.

Gruß
Reinhard

#4

Hallo Reinhard,

nicht alles in Deinem Code ist doch Excel spezifisch.
Was allgemein VB ist wie z.B. eine Funktion, lässt sich problemlos auslagern.

Mal ein dummes Beispiel:

Private Sub Command1\_Click()
 Label1.Caption = Fakultaet(Text1.Text)
End Sub

Private Function Fakultaet(ByVal Wert As Integer) As Double
 Dim i As Integer
 Fakultaet = 1
 For i = 1 To Wert
 Fakultaet = Fakultaet \* i
 Next
End Function

die Funktion könnte man natürlich ohne Problem auch in ein OCX oder eine DLL packen, dann ist der Quellcode nicht mehr sichtbar. Ich habe mir das Beispielprogramm mal oberflächlich angesehen, wie eine ActiveX-DLL zu verwenden ist … Und nicht auf Anhieb alles verstanden oder mir gar gemerkt. :smile: Kannst Du nicht auch eigene Steuerelemente in Excel verwenden? In VB6 ist das die einfachste Lösung. OCX kompilieren, zum Projekt hinzufügen und danach würde im obigen Beispiel einfach so …

Private Sub Command1\_Click()
 Label1.Caption = Fakultaet(Text1.Text)
End Sub

… funktionieren, ohne Deklaration oder irgendwelches anderes Brimborium im Code. Die Funktion würde im OCX als Public deklariert, fertig, geht.

Was dann die ‚Sicherheit‘ angeht, wenn der Code etwas umfangreicher ist und Daten verschlüsselt werden, ist der Aufwand das in Assembler zu lesen, zu analysieren die zu verändernden Bytes zu finden und herauszufinden, wie die verändert werden müssen um das gewünschte Ergebnis zu erzielen ein paar hundert mal so hoch, wie das Programm selbst zu schreiben. :smile:

Gruß Rainer

#5

Hallo Rainer,

nicht alles in Deinem Code ist doch Excel spezifisch.

richtig, was mache ich, dein VB, aber mit den Excel-spezifischen Anweisungen, oder grundsätzlich, mit Vba typischen Anweisungen?

Was macht die Umwandlung in ocx mit Worksheets(Excel), Document(Word),Inspector(Outlook) ?

*grins* was Inspector in Outlook-Vba bedeutet, darauf kommt kein Mensch.

Was allgemein VB ist wie z.B. eine Funktion, lässt sich
problemlos auslagern.

Ja, das nehme ich an.

auf Anhieb alles verstanden oder mir gar gemerkt. :smile: Kannst
Du nicht auch eigene Steuerelemente in Excel verwenden? In VB6
ist das die einfachste Lösung. OCX kompilieren, zum Projekt
hinzufügen und danach würde im obigen Beispiel einfach so …

Private Sub Command1_Click()
Label1.Caption = Fakultaet(Text1.Text)
End Sub

… funktionieren, ohne Deklaration oder irgendwelches anderes
Brimborium im Code. Die Funktion würde im OCX als Public
deklariert, fertig, geht.

Sowas suche ich ja, daß der benutzer mein Add-In, meine dll oder mein ocx einbinden muß und dann z.B. die Funktion „Fakultaet“ benutzen kann/darf, aber halt nicht in Excel mit einfachen Mittln rausfinden kann wie der Code von „Fakultaet“ aussieht.

Was dann die ‚Sicherheit‘ angeht, wenn der Code etwas
umfangreicher ist und Daten verschlüsselt werden, ist der
Aufwand das in Assembler zu lesen, zu analysieren die zu
verändernden Bytes zu finden und herauszufinden, wie die
verändert werden müssen um das gewünschte Ergebnis zu erzielen
ein paar hundert mal so hoch, wie das Programm selbst zu
schreiben. :smile:

Leider ist das so, sonst hätte ich schon längst paar Bytes in Windows/Excel verbessert :smile:

Gruß
Reinhard

#6

Hallo Reinhard,

Was macht die Umwandlung in ocx mit Worksheets(Excel),
Document(Word),Inspector(Outlook) ?

VB6 weigert sich, den Code zu kompilieren, was sonst? *fg*

Sowas suche ich ja, daß der benutzer mein Add-In, meine dll
oder mein ocx einbinden muß und dann z.B. die Funktion
„Fakultaet“ benutzen kann/darf, aber halt nicht in Excel mit
einfachen Mittln rausfinden kann wie der Code von „Fakultaet“
aussieht.

Wenn Du Dich dabei auf solche Teile beschränkst geht das doch ohne jedes Problem. In dem Beispiel könnte der Anwender nicht sehen, was in ‚Fakultät‘ passiert. Speziell Teile mit API Aufrufen sind so leicht zu verpacken und die ganze API-Deklaration ist weg.

Du könntest aber auch aus so einem OCX ‚nach Hause telefonieren‘, der Anwender muss Dir schon ausreichend vertrauen, daß Du da nicht ein Pferdchen einschleust, das wäre nämlich auch kein Problem.

Gruß Rainer