VB-Bibliotheken unter VBA benutzen
 

Hi Leute

ICh hbae folgendes Problem.


Ich habe etwas in VBA auf einem Rechner programmiert wo VB auch installiert war und greife jetzt im Code auf 2 ocx-Bibliotheken von VB zu.

Jetzt möchte ich das aber auf einem Rechner laufen lassen der kein VB hat. Ich habe zwar die 2 ocx-Dateien zu den anderen von Access dazukopiert aber Access kann nicht auf die Bibliotheken zugreifen.


HELP

Ich nehme an, die Fehlermeldung besagt in etwa folgendes:

Component 'NameDerDatei.ocx' or one of its dependencies not correctly registered: a file is missing or invalid

Falls dem so ist, unter 'Start/Ausführen' folgendes eingeben:

regsvr32 c:\PfadZurDatei\NameDerDatei.ocx

nein is es nicht.. fehlermeldung hätte er dazuschreiben sollen =)

"objekterstellung durch activex-komponente nicht möglich"

das ganze meldet er beim commondialog..

Set mydialog = New commonDialog

also hier im prinzip..


wir haben jedoch die datei: comdlg32.ocx im verzeichnis winnt\system32 welche benötigt wird für den commondialog aktiviert bei den verweisen!

hoffe hab das ganze einigermaßen verständlich beschrieben.. liegts an dem oder is der fehler überhaupt wo anders?

Sorry. Da kann ich leider auch nicht weiterhelfen da ich das Problem (glücklicherweise ;)) nicht nachvollziehen kann. Ich habe mir testweise auf meiner XP-Maschine eine kleine OCX erstellt die im initialize ShowOpen ausführt. Die habe ich dann in einmal in einer VB-EXE und einmal in einem Word-UserForm verwendet.
Danach habe ich auf einem NT-System das 100%-ig noch nie mit VB in Berührung gekommen ist, die comdlg32.ocx und meine eigene ocx ins winnt\system32\ gelegt und beide registriert. Danach sind sowohl die VB-EXE als auch das Word-UserForm anstandslos gelaufen.

Mir fällt nur noch eine letzte Möglichkeit ein. Es kann vorkommen, dass lizensierte Komponenten nicht in eigenen OCX laufen wollen wenn in diesen die Option "Require License Key" nicht aktiviert ist. Wenn das auch nicht hilft bin ich mit meinem Latein am Ende.

so, jetzt mal eine antwort darauf..

wir haben folgendes festgestellt!

diese fehlermeldung, welche ich im obigen beitrag geschrieben habe, bekommen wir nur, wenn wir den commondialog in einem modul aufrufen..

wenn der code hinter einem formular liegt, und da der common dialog aufgerufen wird, dann kommt dieser fehler nicht, und es funktioniert!

kannst du dir jetzt vielleicht mehr darunter vorstellen seidl?

naja, hoffe dir ist vielleicht sowas bekannt, bzw hast ratschläge was wir da probieren könnten..

achja, das pic das du im letzten beitrag gehabt hast..
wo kann man das einstellen? hab ne weile gesucht, aber hab nirgends diese einstellung gefunden..

also das häckchen..
wenns geht sag mir/uns bitte wo man das einstellt ;) thx im voraus!

Die Option 'Require License Key' kann man einstellen wenn man unter dem Menüpunkt 'Project' ganz unten auf 'Projektname Properties' klickt, wobei Projektname natürlich der Name des aktuellen Projekts ist. Diese Option ist übrigens nur für ActiveX-Komponenten verfügbar.´

Was den Fehler verursacht weiss ich im Moment auch nicht. Da ich im Augenblick aber recht knapp mit der Zeit bin, werde ich nicht so bald dazu kommen weiter damit herumzuprobieren. Ich nehme aber an, dass sich in der VB-Dokumentation im MSDN sicher finden lässt wie die Sache richtig zu lösen wäre.

Ein guter Ausgangspunkt wäre wahrscheinlich hier.

k, thx für die antwort, werd mir die seite mal reinziehn :D

also bei mir gibts die ganzen checkboxen dort garned.. hmm...

hab pic mitgeschickt wie das bei mir aussieht..

sieht irgendwie nach dem richtigen aus, aber irgendwie auch wieder nicht.. aber das is das eigenschaften fenster von meiner datenbank..

Du liebe Zeit! Da war ich ja auf dem völlig falschen Dampfer!

Ich war durch die Fehlermeldung "objekterstellung durch activex-komponente nicht möglich" der Meinung du hättest selbst eine OCX erstellt in der die COMDLG32 verwendet wird. Dementsprechend war meine Antwort darauf ausgerichtet eine eigene OCX, welche die COMDLG32.ocx verwendet, unter MS-Visual Studio VB6.0 zu kompilieren.

Da das ganze Problem nur in einer Datenbank auftritt sieht die Sache natürlich wieder ganz anders aus. Das Doofe an der Sache ist nur, dass ich das Problem noch immer nicht nachvollziehen kann. Bei mir funktioniert der Code:

Public Sub test()
Set dlg = New CommonDialog
dlg.ShowOpen
End Sub

ohne jegliche Probleme.
Besonders ratlos macht mich, dass die Sache in Formularen funktioniert und in Modulen nicht. Das ergibt nicht viel Sinn für mich. Hier auf jeden Fall noch ein paar Fragen die mir jetzt noch so einfallen:

- Sind auf dem Rechner sowohl COMDLG32.OCX als auch COMDLG32.OCA und COMDLG32.DLL vorhanden?
- Waren die Dateien schon vorhanden oder habt Ihr sie nachträglich auf den Rechner kopiert?
- Sind die Dateien sicher registriert?
- Habt Ihr schon versucht einfach die VB-Runtime zu installieren?

Jetzt komm ich auch mal wieder dazu... ;)

Hört sich interessant an. Die *.OCA und *.DLL sind sicher nicht dabei. Nur die OCX hamma kopiert (das könnt schon mal ein Grund sein)

Die OCX haben wir mittels regsvr32 registriert. Wenn man sich jetzt die anderen Dateien mit kopiert, muss man die auch registrieren(die DLL nehm ich mal an), aber was ist mit der OCA?

so nochmal ne kleine änderung, es geht nicht wirklich in formularen, sondern es geht dann in formularen, wenn aus den activeX-steuerelementen in der toolbox den common dialog auswählt, dadurch wird im formular ein button erzeugt, der den aufruft..

also in diesem fall funktioniert das ganze dann..
wenn man direkt im programmcode aufruft, dann gehts nicht.. egal ob es sich um ein formular oder modul handelt..

jetzt is mal klar gestellt das es nicht an modul oder forumlar liegt..

haben die oben genannten dateien jetzt raufkopiert, und versucht sie zu registrieren, sprich die dll und oca geht aber ned..

also zusammenfassend auf deine fragen:
die dll war anscheinend schon vorhanden, die ocx und oca nicht und wurden kopiert!
ocx konnten wir registrieren, den rest nicht..


vb-runtime haben wir noch nicht probiert..

ich hab noch ne ne comdlg32.dep gefunden.. was mit der datei? braucht man die? registrieren?

noch etwas, was ich vergessen habe..

wir haben im formularcode, wo das activexsteuerelement commondialog im forumlar eingefügt worden ist, dann den commondialog ganz normal wie auch bei den modulen verwendet..

also wäre eine lösung, dieses steuerelement auch irgendwie in den modulen zu beziehen... was ich nicht ganz verstehe ist, wie das funktioniert.. warum funktioniert es, wenn das steuerelement im formular ist, aber nicht speziell angesprochen wird im code..

und gibts ne möglichkeit sowas in ein modul einzubeziehn? also dieses steuerelement?

Ist fast ein bischen peinlich aber ich musste mich nie wirklich ausgiebig damit beschäftigen, Abhänigkeiten meiner Projekte händisch auf anderen Rechnern zu erstellen. Deshalb war ich bislang immer zufrieden wenn die Sache erst mal bei mir gelaufen ist. Um die Verteilung durchzuführen starte ich dann nur mehr den Verpackungs-Assistenten der Office-Developer-Version. Der sucht sich selbst alle Abhänigkeiten zusammen, weiss welche Dateien ein anderer Rechner benötigen wird, wo diese Dateien hinkopiert werden müssen und was alles zu registrieren ist. Als Resultat bekommt man dann ein Installations-Package das alles nötige erledigt. Sind zwar noch keine MSI-Files aber immerhin.

War schon immer so. Je besser das Tool, desto weniger muss der Anwender können. :D

Bin gerade bei einer Lösungssuche für ein anderes Problem durch Zufall über folgende Seite gestolpert:

http://members.rogers.com/douglas.j....nceErrors.html

Darin findet sich ein Link auf folgende Seite:

http://support.microsoft.com/default...;EN-US;q244264

Dort wird beschrieben was man checken muss wenn der betreffende Fehler auftritt.

thx für die antworten und link, habs mir durchgeschaut, aber leider nix für unser problem gefunden..

Tja, wenn der zweite Link nicht passt, dann bin ich offengesagt auch überfragt. Bleibt uns nur der schwache Trost, dass wir uns nicht zu schämen brauchen. Wenn nicht mal die empfohlenen Fehlersuchschritte der Microsofties was bringen, dann kann man von uns auch keine Wunder erwarten. ;)

naja.. so gesehn stimmts..

aber trotzdem ein schass das ganze.. :(

thx für deine hilfe!
auch wenns am schluss dann doch nicht hat sein sollen..

naja, ganz unten steht ja man soll Office neu installieren... ;)

Vielleicht mach ma das ja auch mal...

Weil ich will schaun, dass ich einen Testrechner bekomme, wo man Win2k frisch installieren kann. Dann nehmen wir uns auch gleich ein Office dazu und Testen das ganze nochmals.

Sprich händisch die Elemente rüber kopieren und dann mit regsvr32 registrieren.

Naja, oder wir müssten uns eine Office 2k Developer Version besorgen. :lol: :ms:

hab noch eine möglichkeit gefunden, dateidialoge manuell einzubinden..

sprich wenn man die ocx ned hat, kann man sich das selbst schreiben.. werden wir morgen mal probieren, hab das in nem buch für access2002 programmierung gefunden, wo auch noch auf user mit 2000 rücksicht genommen wird.. weil anscheinend liegts am office 2000...

mal sehn ob das geht!

Falls du die Möglichkeit mit der 'Microsoft Office 10.0 Object Library' meinst muss dich der Vollständigkeit halber darauf hinweisen, dass damit unter Access 2002 der 'SaveAs'-Dialog nicht funktioniert. Im Augenblick wird dir das wahrscheinlich "vui blunz'n wuascht" sein aber es könnte sich nochmal als wesentlich erweisen wenn du umsteigen willst. Ich selbst habe durch dieses Problem nämlich schon mal einige Zeit damit verbracht mich zu wundern, was an an meinem Code plötzlich nicht stimmen könnte. ;)

UUUPs! Blödsinn.

Mein letztes Posting kannst du vergessen. Ich habe zu spät gesehen, dass du 'selber schreiben' erwähnt hast. Das macht die Sache mit der Library irgendwie doch sehr unwahrscheinlich. ;)

jop... ;)

Es geht darum die Windows-APIs selber im Code direkt aufzurufen.
Er hat ein Beispiel in einem Access Buch gefunden.

Ich habs gestern nochmals auf einem Notebook (Windows XP mit SP1 und Office 2k mit SR1a und SP2, welches noch nie Kontakt mit VB gehabt hat getestet: comdlg32.ocx, comdlg32.oca und comdlg32.dll rüber kopiert - die ocx und die dll registriert.

Das Formular mit dem Common Dialog Control drauf funkt wie schon erwähnt 1A, die Module die das Objekt während der Laufzeit erstellen nicht.

Jetzt werden wir das ganze morgen auf einem frischen Rechner probieren (wenn es sich von der Zeit her ausgeht) und eine andere Idee war auch, dass unser Access File schon ein wenig spinnt --> eine neue Access-DB erstellen, und unsere Formulare, Berichte und Tabellen dorthin kopieren.

Mal schaun was rauskommt. :)

danke für den hinweis mit der office 10 library, hab ich aber eh schon gewusst das der saveas nicht geht, deswegen sind wir auch auf commondialog umgestiegen..

aber unter office 2000 gabs die office 10 library glaub ich noch garnicht!

weil da erkennt der das ganze glaub ich überhaupt nicht.. bin mir jetzt aber ned ganz sicher..

der llr hatte zumindest ne zeitlang probleme mit der methode von der office 10 library

ich hatte nur das Problem, dass ich immer die Office 10 Libary aus den Verweisen nehmen musste und statt dessen die Office 9 anhakeln...
Das war mein einziges Problem.

Weil:
Office 9 = Office 2k
Office 10 = Office XP

und Office 11 wird dann glaub ich Office 2003 heißen...

aso.. hmm.. hab irgendwie in erinnerung das es mit der office 9 nicht gegangen is.. naja is ja wurscht..

so - heute der finale Test:

Win2k Maschine frisch aufgesetzt, nur Office 2k prof installiert.

Dann die comdlg.*-Dateien rüber kopiert und die ocx registriert.

Wieder mit dem Ergebnis, dass das ganze ohne Probleme auf Formularen funktioniert, aber nicht wenn das Objekt während der Laufzeit erstellt wird. :mad:

Die Klasse, die in dem Access buch zu finden ist, und die die API-Calls direkt macht, ist insofern wieder "supa", da man das ganze von einem Formular aufrufen muss. (Fehlermeldung, wenn die Klasse aus einem Modul aufgerufen wird)
(Die exportierte Klasse, hab ich als txt-file angehängt)

Jetzt werden wird das ganze wahrscheinlich ein wenig "dirty" (nicht quick and dirty, sondern nur dirty ;)) lösen, indem wir ein Formular mehr oder weniger im Hintergrund öffnen, damit das ganze dann geht.

Naja, bin schon gespannt ob das dann geht, da ich nächste Woche bei den Änderungen nicht dabei bin. :)

sieht bzw kennt jemand ne möglichkeit das in einem modul zum laufen zu bringen?

also den code, der im anhang beim vorigen post dabei ist..

bzw wenn jemand mit sicherheit sagen kann das es nicht klappen wird, wäre es auch gut zu wissen ;)

Spät aber doch ;)

Ich hab' euer letztes Posting erst jetzt gelesen und mir den Code daraufhin mal angesehen. Die Sache ist absolut kein Problem. Alles was Access am Code stört ist, dass versucht wird den Window-Handle des aktiven Formulars zu übergeben, was ohne Formular natürlich schlechterdings möglich ist. Als Abhilfe einfach nach der Zeile:

.hwndOwner = Screen.ActiveForm.Hwnd

suchen und auskommentieren. Schon funktioniert die Sache einwandfrei.

Falls sich durch den fehlenden Handle wieder Erwarten ein Problem ergibt, lässt sich auf dem Source-Code-Planeten sicher was finden um einen Handle auf das Fenster der Access-Application selbst zu bekommen. Bei Problemen bin ich selbst oft dort unterwegs. Natürlich ist auch Schrott dabei, aber es gibt immer wieder wahre Perlen unter den Fundstücken durch die man, wenn man ein wenig damit herumspielt, sehr schnell mehr lernt als man es mit jedem noch so guten Buch in beliebiger Zeit könnte.

hmm.. dann sag ich mal danke für die hilfe und danke für die tipps!

naja, da ich die seite nicht kenne, und nicht weiss, ob dort solche codes vorhanden sind, war das buch dann doch sehr hilfreich!

wir haben es im moment bissl russisch gelöst, nämlich einfach ein eigenes formular aufgefrufen, welches sich öffnet, bevor das modul ausgeführt wird! dort liegt dann der dialog und dann wird das modul ausgeführt..
jetzt könn ma das wieder wegmachen!

you're welcome!

Sollte auch übrigens auch kein Angriff gegen Bücher sein. Als Ausgangspunkt ist mir ein Buch meistens auch lieber. Schon allein deshalb, weil ich mich damit auch mal zum Schöckern auf den Balkon zurückziehen kann. Wenn ich dann aber beim Umsetzen des Erlernten auf grobe Probleme stosse, versuche ich erst mal im Internet nach einer Lösung zu suchen (was ihr ja auch gemacht habt ;) ), weil man in solchen Fällen meistens nicht der erste ist, der auf das Problem stösst.
Oft lässt sich irgend ein Code-Snippet finden in dem das Problem umgangen wird und mit dem Codeteil spiele ich dann herum bis ich mir sicher bin, die Lösung verstanden zu haben. Das dadurch erworbene Wissen lässt sich später fast immer auch auf andere Probleme anwenden.

Problem gelöst
 

Wir haben das PRoblem gelöst.
Die Lösung hat den Vorteil das wir die ocx-Files vom VB nicht mehr brauchen.

Man muss einfach das Klassenmodul das ich angefügt habe in Access reinpacken und es dann noch in einem Modul aufrufen:

Dim dialog As Object

Set dialog = New risq_dialog

strpfad = dialog.OpenFile("Access-Datenbanken (*.mdb)|*.mdb")

Wobei das was hier als risq_dialog steht der NAme des Klassenmoduls sein muss.

Trotzdem Danke für die Hilfe

Problem gelöst
 

Ich habe noch vergessen dazuzuschreiben das immer ein Formular offen sein muss wenn man dieses Klassenmodul in einem normalen Modul verwenden will. Sonst gehts leider nicht.

In Formularen gehts ohne Probleme.

also im prinzip stand das eh schon alles in den posts vorher..

aber egal..

wenn ich mich nicht täusche ist der aufruf des klassenmoduls aber im formular selbst und nicht im modul..

aber wie gesagt steht eh schon oben bzw auf der vorigen seite!