Access 2003 VBA - Problem mit .OCX

Computer: Software & Programmierung Visual Basic
#1

Hallo,

ich habe mit VB6 ein .OCX geschrieben, um es mit Access 2003 zu verwenden.

Verwende ich das .OCX in einem Beispielprogramm in VB6 gibt es keine Probleme.

In AccessVBA wir der erste Afruf des OCX mit der Fehlermeldung:
‚Obejekterstellung durch ActiveX-Komponente nicht möglich‘ kommentiert. Danach kann das Programm aber fortgesetzt werden und arbeitet wie gewünscht.

Beim Schließen von Access kommt dann allerdings der nächste Fehler:
‚Objekt oder Whith-Block Variable nicht festgelegt‘

In VB6 tauchen beide Fehler nicht auf.
Kann es sein, daß die beiden Fehler zusammenhängen? Welches Problem hat Access?

Bei Bedarf kann ich auch Code zeigen, aber das wird recht viel. So viel, daß das kein Mensch mehr lesen wird. :frowning:

Gruß Rainer

#2

Hallo Rainer,

kannste nicht mal was in Excel fragen? *schelt* *hihi*

ich habe mit VB6 ein .OCX geschrieben, um es mit Access 2003
zu verwenden.
Verwende ich das .OCX in einem Beispielprogramm in VB6 gibt es
keine Probleme.

In AccessVBA wir der erste Afruf des OCX mit der
Fehlermeldung:
‚Obejekterstellung durch ActiveX-Komponente nicht möglich‘
kommentiert. Danach kann das Programm aber fortgesetzt werden
und arbeitet wie gewünscht.

Meine Unkenntnis zu dem problem läßt mich da schonmal fragen,
Du hast mir ja netterweise ein Ocx gebastelt. Den konnte ich dann in einer Form einbauen.

Kommt dann diese Fehlermeldung dann wenn du erstmalig dieses Objekt in der Form „betätigst“, oder wann?

Beim Schließen von Access kommt dann allerdings der nächste
Fehler:
‚Objekt oder Whith-Block Variable nicht festgelegt‘

*hmmh*, garantiert hast du schon nach beiden Meldungen im Inet gesucht. Also halfen dir da die Treffer nicht weiter :frowning:

Bei Bedarf kann ich auch Code zeigen, aber das wird recht
viel. So viel, daß das kein Mensch mehr lesen wird. :frowning:

Ich verstehe nicht was du damit meinst. Sicher, den Code in der ocx verstehe ich sicher nicht.

Meinst du Access-Code?

Was passiert denn wenn du den wegläßt bzw. nur noch Kleincode hast um auf das ocx zu reagieren?

Irgendwie werde ich grad unsicher was so ein ocx, ist das nicht so ein Steuerelement wie der Schieber den du mir mal gebaut hast?
Ich mußte damals die ocx nur im Programm bekanntmachen und konnte im Editor diesen Schieber wie andere Steuerelemente benutzen.

Natürlich darfste mir gerne diese ocx schicken, ich hab nur Access2000, mein Office2007 hat kein Access.
Ob dir das weiterhilft also ich als blindes Huhn finde da ein Korn, da würde ich mich aber nicht darauf verlassen.

Bei der ocx Erstellung, hattest du doch Verweise in Vb6.0 aktiviert.
Hast du in Access schon geschaut ob da alle Verweise dort ohne Fehlerhinweis aufgelistet werden und auch ob es in Access nicht aktivierte Verweise gibt, die denen in VB6.0 ähneln?

Ich gehe sehr davon aus, du hast alles was mir so einfällt auch schon getestet.

Ich kenne leider auch nix in Access, also z.B. ein sehr gutes Accessforum was sich mit Vba beschäftigt.

Sehr sorry :frowning:

Gruß
Reinhard

#3

Hallo reinhard,

kannste nicht mal was in Excel fragen? *schelt* *hihi*

nö, dann ist es ja zu leicht für Dich. :smile:

ich habe mit VB6 ein .OCX geschrieben, um es mit Access 2003
zu verwenden.
Verwende ich das .OCX in einem Beispielprogramm in VB6 gibt es
keine Probleme.

In AccessVBA wir der erste Afruf des OCX mit der
Fehlermeldung:
‚Obejekterstellung durch ActiveX-Komponente nicht möglich‘
kommentiert. Danach kann das Programm aber fortgesetzt werden
und arbeitet wie gewünscht.

Meine Unkenntnis zu dem problem läßt mich da schonmal fragen,
Du hast mir ja netterweise ein Ocx gebastelt. Den konnte ich
dann in einer Form einbauen.

Kommt dann diese Fehlermeldung dann wenn du erstmalig dieses
Objekt in der Form „betätigst“, oder wann?

Das OCX baut eine Telnesession auf. Der Fehler kommt, wenn Socket doie Verbindung zum Server aufbauen soll.

Beim Schließen von Access kommt dann allerdings der nächste
Fehler:
‚Objekt oder Whith-Block Variable nicht festgelegt‘

*hmmh*, garantiert hast du schon nach beiden Meldungen im Inet
gesucht. Also halfen dir da die Treffer nicht weiter :frowning:

Nein, die zeigen scheinbar in die falsche Richtung.

Bei Bedarf kann ich auch Code zeigen, aber das wird recht
viel. So viel, daß das kein Mensch mehr lesen wird. :frowning:

Ich verstehe nicht was du damit meinst. Sicher, den Code in
der ocx verstehe ich sicher nicht.

Meinst du Access-Code?

ich meine das OCX. Da muss der Fehler stecken, in Access passiert nichts ungewöhnliches. Das arbeitet nur mit seiner Datenbank und ruft zwei OCXe auf. nur eins davon ist von mir.

Was passiert denn wenn du den wegläßt bzw. nur noch Kleincode
hast um auf das ocx zu reagieren?

Nicht getestet, aber vermutlich das Selbe.

Das VBA-Programm ist auch nicht von mir, das hat mein Kollege gebaut. Du weißt ja, daß ich mit VBA nicht so fit bin.

Irgendwie werde ich grad unsicher was so ein ocx, ist das
nicht so ein Steuerelement wie der Schieber den du mir mal
gebaut hast?

Ja, auch. Ein Steuerelement halt.
Das hier ist äußerlich ganz einfach, hat keine Eigenschaften und ist unsichtbar. Es gibt nur eine Function As Public. Der wird ein String übergeben und sie gibt einen String zurück.

Nebenbei wird eine Datenbank versorgt, per FTP Daten gesendet, geladen, ein Programm auf einem anderen Computer gestartet und gesteuert … Alles unsichtbar.

Ich mußte damals die ocx nur im Programm bekanntmachen und
konnte im Editor diesen Schieber wie andere Steuerelemente
benutzen.

Ja. :smile: So einfach soll das hier auch sein.

Natürlich darfste mir gerne diese ocx schicken, ich hab nur
Access2000, mein Office2007 hat kein Access.

Das nützt Dir nicht viel. Was dieses OCX tut, kann es nur bei mir in der Firma tun. Das arbeitet nur an dieser einen Stelle. Gekapselt als OCX, weil der Code inn Access-VBA nicht realisierbar ist.

Ob dir das weiterhilft also ich als blindes Huhn finde da ein
Korn, da würde ich mich aber nicht darauf verlassen.

Bei der ocx Erstellung, hattest du doch Verweise in Vb6.0
aktiviert.
Hast du in Access schon geschaut ob da alle Verweise dort ohne
Fehlerhinweis aufgelistet werden und auch ob es in Access
nicht aktivierte Verweise gibt, die denen in VB6.0 ähneln?

In Access müssen keine Verweise gesetzt sein, das OCX ist ja praktisch eine .exe Grundsätzlich läuftz es ja auch, nur beim Schließen der Form kommt ein Fehler. Wird Access dann beendet, passiert nichts weiter … Glaube und hoffe ich. Ich sehe auf der Unix-Maschine, die angesprochen wird jedenfalls keine hängenden Prozesse.

Ich gehe sehr davon aus, du hast alles was mir so einfällt
auch schon getestet.

Das weiß ich nicht. Ich vermute inzwischen, daß das Socket-Modul, das ich mir von PlanetSourcecode geladen habe fehlerhaft ist. Morgen geht es erst mal so in die Produktion, nächste woche versuche ich mal das Telnet-Modul mit Winsock statt dem Socket-Modul zum laufen zu bekommen. Port 23 wird Winsock ja auch auf bekommen. :smile:

Ich kenne leider auch nix in Access, also z.B. ein sehr gutes
Accessforum was sich mit Vba beschäftigt.

Sehr sorry :frowning:

Ach, das ist schon OK so. Du weißt doch, daß wir immer die besten Ideen haben, wenn wir mit den Tasten denken. :smile: Vorhin habe ich nur mit den Schultern gezuckt, jetzt weiß ich schon, wo ich morgen suchen werde.

Danke!

Gruß Rainer

#4

Hallo Rainer,

ich hab mir nicht alles durchgelesen. Aber ich habe gelesen, das dies unsichtbar sein soll und du nur eine Funktion aufrufst, dir dir dann einen String zurueckliefert. Sollte das der Fall sein, bastel doch halt mal schnell eine DLL daraus und binde dies mal ein.

Wie verhaelt sich dann VBA ?

MfG Alex

#5

Hi Alex,

ich hab mir nicht alles durchgelesen. Aber ich habe gelesen,
das dies unsichtbar sein soll und du nur eine Funktion
aufrufst, dir dir dann einen String zurueckliefert.

richtig. Zwischendurch passiert noch einiges mehr, aber nichts, was der Anwender sehen soll.

Sollte das
der Fall sein, bastel doch halt mal schnell eine DLL daraus
und binde dies mal ein.

Wie verhaelt sich dann VBA ?

Das ist ein Tipp, werde ich mal versuchen.

Gruß Rainer

#6

Hallo Rainer,

richtig. Zwischendurch passiert noch einiges mehr, aber
nichts, was der Anwender sehen soll.

Wieso hast du da eigentlich ein OCX gebastelt und nicht gleich eine Dll? OCX würde ich nur basteln, wenn ich da was einstellen kann *grins* Ansonsten halt immer DLL Dateien. OK, Eigenschaften kann man auch in einer DLL mit ein wenig tricksen (Murksen:s) verwalten.

Sollte das
der Fall sein, bastel doch halt mal schnell eine DLL daraus
und binde dies mal ein.

Wie verhaelt sich dann VBA ?

Das ist ein Tipp, werde ich mal versuchen.

Sag mal bescheid, was daraus geworden ist und wo der Fehler genau auf tritt. Das Pferd bekommen wir sicher schon geschaukelt *grins*

Aber was mir noch einfaellt. Ist auf dem Zielrechner das gleiche OS installiert? Kann es vielleicht sein das Access, da irgendwo ne Einstellung hat, alla… " Lasse keine OCX zu…" Oder das die Firewall, Das Virenproggi dir da ein Strich durch die Rechnung macht?

Alternativ könntest du noch probieren. Das OCX in eine simple EXE einbinden und dann mal die EXE auf dem Zielrechner installieren und ausführen. Läuft es dann? Danach mal Access starten und dann das Script welches das OCX lädt. Geht es dann?

Mit diesen Infos könnte man schon einiges ausschliessen :wink:

MfG Alex

Gruß Rainer

#7

Hi Alex,

Wieso hast du da eigentlich ein OCX gebastelt und nicht gleich
eine Dll?

Weil ich nicht auf Dll gekommen bin. Eine ActiveX-Dll habe ich noch nicht geschrieben und auch noch keine verwendet. Das ist Neuland.

OCX würde ich nur basteln, wenn ich da was
einstellen kann *grins* Ansonsten halt immer DLL Dateien. OK,
Eigenschaften kann man auch in einer DLL mit ein wenig
tricksen (Murksen:s) verwalten.

Sollte das
der Fall sein, bastel doch halt mal schnell eine DLL daraus
und binde dies mal ein.

Wie verhaelt sich dann VBA ?

Das ist ein Tipp, werde ich mal versuchen.

Sag mal bescheid, was daraus geworden ist und wo der Fehler
genau auf tritt. Das Pferd bekommen wir sicher schon
geschaukelt *grins*

Aber was mir noch einfaellt. Ist auf dem Zielrechner das
gleiche OS installiert?

Ja, beide XP-Pro.

Kann es vielleicht sein das Access, da
irgendwo ne Einstellung hat, alla… " Lasse keine OCX zu…"

Dann würde es nicht laufen. Es geht ja alles, nur das Beenden von Access sieht mit dem Fehler unschön aus und macht keinen Vertrauenserweckenden Eindruck. Grundsättzlich kann man so damit arbeiten, es ist nur nicht richtig ‚rund‘. Das lässt befürchten, daß irgendwann noch andere Probleme auftauchen.

Oder das die Firewall, Das Virenproggi dir da ein Strich durch
die Rechnung macht?

OfficeScan ist recht gut, macht da selten Probleme.

Alternativ könntest du noch probieren. Das OCX in eine simple
EXE einbinden und dann mal die EXE auf dem Zielrechner
installieren und ausführen. Läuft es dann?

Nicht getestet, aber mit 99% Wahrscheinlichkeit läuft das ohne Problem. Nur kann ich dann nicht so einfach einen Wert zurückgeben. Dann müsste ich wieder extra ein File schreiben, Verzeichnis überwachen, dort lesen … Die Bastelei sieht noch übler aus.

Danach mal Access
starten und dann das Script welches das OCX lädt. Geht es
dann?

Auch noch nicht getestet, aber 99% … Das wird keine Fehler verursachen.

Mit diesen Infos könnte man schon einiges ausschliessen :wink:

Der Fehler scheint eingegrenzt zu sein. Die Klasse ‚CSocket.cls‘, die ich von PlaneSourcecode habe, scheint ein paar nicht dokumentierte Schweinereien zu veranstalten. VB6 lässt sich das gefallen, Access nicht.

Ich muss mein Telnet umschreiben, versuchen Telnet VT100 mit Winsock zum Laufen zu bringen. Dann widr das Problem wohl behoben sein.

Gruß Rainer

#8

Hi Alex,

das Problem ist erledigt, läuft jetzt ohne Fehler.

Ich hatte für Telnet einen Code von PlanetSourcecode der ein paar Module und Klassen enthalten hat. Wenn man mit Google nach Telnet und VT100 sucht findet man immer wieder den selben Code, der die selben Module und Klassen verwendet.

Aber ganau da lag das Problem, die Klasse CSocket.cls, die da überall verwendet wird, erzeugt den Fehler. Da steht kein Option Explicit drin, hab’ ich dann mal hineingeschrieben um Fehler zu suchen … Dann stürzt sofort die IDE ab.

Ich habe jetzt gefunden, wie man Telnet unter Verwendung des Winsock-Steuerelements realisieren kann, läuft! Ohne jedes Problem! Der Code ist nun deutlich kürzer, leicht verständlich und auch noch schneller. :smile:

Gruß Rainer

#9

Hallo Rainer,

das Problem ist erledigt, läuft jetzt ohne Fehler.

Na das ist doch super. Und das auch noch, ohne das ich mir grosse Gedanken machen musste *grins*

Ich hatte für Telnet einen Code von PlanetSourcecode der ein
paar Module und Klassen enthalten hat. Wenn man mit Google
nach Telnet und VT100 sucht findet man immer wieder den selben
Code, der die selben Module und Klassen verwendet.

Ok, das habe ich nicht gemacht. Im naechsten Post haette ich Dich dann schon nach der Klasse gefragt!

Aber ganau da lag das Problem, die Klasse CSocket.cls, die da
überall verwendet wird, erzeugt den Fehler. Da steht kein
Option Explicit drin, hab’ ich dann mal hineingeschrieben um
Fehler zu suchen … Dann stürzt sofort die IDE ab.

Ok, Option Explicit sollte man eh immer setzen. Wer weiss warum sie dies nicht gemacht haben! Aber interessant wäre es doch die Klasse so umzugestalten das es läuft oder?
Ich mein, einfach die Klasse nehmen, eine Allgemeingültige Fehlerbehandlung rein, die Dir besagt welche Sub /Function und welche Zeile da, den Fehler versursacht und schon kommt man ihm auf die schliche und kann den Fehler beheben!

Ich habe jetzt gefunden, wie man Telnet unter Verwendung des
Winsock-Steuerelements realisieren kann, läuft! Ohne jedes
Problem! Der Code ist nun deutlich kürzer, leicht verständlich
und auch noch schneller. :smile:

Ok, das ist die Hauptsache. Aber hast du wieder ein OCX gebastelt oder diesmal gleich eine DLL? Was ich mich aber frage. Was macht man zum Teufel mit Telnet?
Ok, ich bin ja mittlerweile auf der Schiene von VB10, aber ein Grund warum ich Telnet nutzen sollte, bleibt mir fremd :s

Gruß Rainer

MfG Alex

#10

Hi Alex,

Ok, Option Explicit sollte man eh immer setzen. Wer weiss
warum sie dies nicht gemacht haben! Aber interessant wäre es
doch die Klasse so umzugestalten das es läuft oder?
Ich mein, einfach die Klasse nehmen, eine Allgemeingültige
Fehlerbehandlung rein, die Dir besagt welche Sub /Function und
welche Zeile da, den Fehler versursacht und schon kommt man
ihm auf die schliche und kann den Fehler beheben!

ja, wäre nett, aber das Ding arbeitet mit Subclassing und stürzt immer gleich komplett ab, reißt die IDE mit. Da geht debuggen nur über ein Logfile. Sehr umständlich Zeitaufwändig … Mit Winsock ist mir das ohnehin lieber. :smile:

Ich habe jetzt gefunden, wie man Telnet unter Verwendung des
Winsock-Steuerelements realisieren kann, läuft! Ohne jedes
Problem! Der Code ist nun deutlich kürzer, leicht verständlich
und auch noch schneller. :smile:

Ok, das ist die Hauptsache. Aber hast du wieder ein OCX
gebastelt oder diesmal gleich eine DLL?

Ich habe das vorhandene OCX umgebaut. :smile: Zeitdruck. Ab Montag läuft das in der Produktion.

Was ich mich aber
frage. Was macht man zum Teufel mit Telnet?

Programme auf einem Unix-Server starten.

Ich beschreib’s mal:

Alter Zustand:

  • Material wird auf die Waage gestellt, abgewogen, die Waage druckt das Gewicht auf einen Bon-Streifen.
  • der Verwieger geht mit dem Zettel zum Computer und tippt in eine Terminalemulation Daten ein. Die werden in eine antike Informix-datenbank geschrieben.
  • Ein VB-Programm überwacht die Veränderung auf dem Unix-Server, holt die Daten und druckt ein Barcodeetikett nach VDA-Norm (Verband Der Automobilindustrie)

Nachteil: Es gibt immer mal Tippfehler.

Neuer Zustand ab Montag:

  • Auftragsdaten werden aus der Informix-Datenbank gelesen und in eine MDB geschrieben.
  • Beim verwiegen wird die Auftragsnummer mit einem Barcodescanner gelesen, die restlichen Daten aus der MDB geholt. Das Gewicht wird von der Waage geholt. (Auch ein OCX)
  • Die Daten für die Informix-Datenbank werden im passenden Format (ein langer String) zusammengeschraubt und auf den Unix-Server geschrieben.
  • Per Telnet wird auf dem Unix-Server ein Programm gestartet, das die Daten lies und in die Informix-Datenbank schreibt. (Einen ODBC-Treiber gibt es nicht)
    Das Programm stellt die Daten für das Barcodeetikett zusammen und schreibt sie für VB lesbar in eine Datei. Dann gibt es Daten an das OCX zurück. Das OCX holt die Daten für das Etikett und druckt. Dann werden die zurückgegebenen Daten an das VBA-Programm zurückgegeben und in die Datenbank eingetragen.

Der Weg ist etwas umständlich, geht aber nicht anders. Die Anwender sehen nichts davon und es läuft stabil.

Gruß Rainer