|
Anzeige
|
MSCOMCTL.OCX unter W11Habe hier ein 32bit Windows Programm, das einst mit dem Studio unter VB6 erstellt wurde. Es läuft seither auf XP prima, aber die Hardware hat jetzt schlapp gemacht. Die Anwendung könnte man wohl als 64 bit compilieren, aber sie bleibt trotzdem MFC und mit dot net ist nix. Über mscomctl.ocx wird auf eine Access Datenbank mdb zugegriffen. Kriegt man sowas unter W11 registriert?
Die letzte Aussage von M$ die ich dazu kenne, allerdings noch W10, lautet VB6 betreffend sinngemäss: "Its fully supported." Mit einem eigenen Installer kann man VB6 sogar noch installieren. ☺ Der Weg über 64 bit wird voraussichtlich erst recht scheitern. Versuch doch mal, einen 32 bit CMD.EXE zu starten, und die dll/ocx mit regsvr32 zu registrieren. Eventuell könnte auch eine Installation von VB6 helfen. Die bringt nämlich auch die komplette Runtime mit.
Sollte prinzipiell funktionieren. Ich habe zwar nicht VB6, sondern nutze VBA unter Office. Wichtig: es ist die 32-Bit-Version von Office. Damit bekomme ich die Makros zum Laufen. Registriert ist die MSCOMCTL.OCX im Ordner C:\Windows/System32 in Windows 11 (natürlich 64 Bit-Version). Per KI nach Python übersetzen... 😉
Office habe ich zuletzt Professional 2010 installiert was ich ja bereits wegen der Access Datenbank als Basis brauche. VB6 habe ich mal unter W10 probiert und nichts hingekriegt. W7 ging noch aber W10 ist ja auch Geschichte. KI wird kräftig schief gehen. Neben der Access Datenbank ist nämlich auch noch List&Label von Combit für Auswertungen als PDF sowie SuperCom von Addontec für ein serielles 3964 Protokoll in der Anwendung. Daran hängt dann ein handgeschnitzter ATmega der die Schnittstelle zu einer Analysenwaage bedient und eine ebenso handgeschnitzte Mechanik ansteuert. SuperCom sowie List und Label gibt es ja als neuere Versionen wo man eben den Runtime Schlüssel neu compilieren müsste. Alles neu zu schreiben möchte ich mir nicht antun weil das in Stückzahl 2 niemand bezahlen wird. :
Bearbeitet durch User
Dagegen spricht ja auch nichts, aber ...
Das funktioniert nicht, weil das OCX eine 32-Bit-Komponente ist. Allerdings enthält mscomctl.ocx nur Code für die "Common Controls" und hat mit Datenbank gar nichts zu tun. Eine MFC-Anwendung braucht dieses OCX überhaupt nicht, und mit einer Access-Datenbank kann man auch über einen ODBC-Treiber kommunizieren. Und auch dafür braucht man kein OCX; nur muss die "Bittigkeit" des Programmes zum Access-ODBC-Treiber passen. Wenn also ein 32-Bit-Office installiert ist, muss das Programm den 32-Bit-ODBC-Treiber nutzen, und das tut es, wenn es selbst ein 32-Bit-Programm ist. Es spricht rein gar nichts dagegen, 32-Bit-Programme unter 64-Bit-Windows zu verwenden.
Wenn das API irgendwo dokumentiert ist oder Beispielcode dafür existiert kommen die Sprachmodelle auch mit solchen exotischen APIs klar. Da das .net APIs sind sollte man wohl auf eine .net Sprache portieren.
Ein Protokoll/Datenformat von einer Sprache in die andere zu übersetzen ist so ziemlich der ideale Use Case für LLMs
So ist es. Danke für den ergänzenden Hinweis mit dem ODBC-Treiber. Genau diesen benutze ich (32 Bit) mit dem 32-Bit-Office auf 64-Bit Windows 11. Momentan bin ich zwangsläufig einen Schritt auf W10 zurück. Alle 32 bit OCX scheinen mit regsvr32 manell korrekt eingebucht und erzeugen keine Fehlermeldungen mehr. Probleme gibt es mit der mdb Datenbank bzw. mit ODBC. Auf dem 64bit W10 ist eine 32bit Version von Office10 installiert. Ich nehme an, daß der mdb Treiber aus diesem Paket stammt? Mit Access kann ich dann das mdb file manuell öffnen. Die Inhalte erscheinen korrekt. Unter WindowsVerwaltungsprogramme finde ich sowohl ODBC Datenquellen (64-bit) wie auch ODBC DataSources (32-bit) in dtsch bzw. Englisch. Ich rufe die 32 bit Version als Administrator auf. Dort trage ich in System-DSN (weil es für alle Benutzer gelten soll) meine Datenbank.mdb ein. "Hinzufügen" wählt zuerst einen passenden Treiber aus. Es werden auch hier zwei scheinbar passende Treiber in zwei Sprachen angeboten. Die Sprache sollte hier eigentlich egal sein. Driver do Microsoft Access (.mdb) Microsoft Access Driver (.mdb) Danach werde ich aufgefordert, das Datenbankfile auszuwählen. Die ausgewählte Datenbank wird zunächst mit vollem Pfad angezeigt, aber die ok Taste ist weiter ausgegraut. Als Datenbankquelle kann ich den Dateinamen ohne Pfad aber manuell eingeben. Danach kann die OK Taste betätigt werden und die Datenbank erscheint in der Liste eingebuchter ODBC Quellen. Allerdings erscheint sie automatisch gleichermaßen im 64 bit Fenster. Sie hat in beiden Tools die Platform 32bit vermerkt. Die VB6 Anwendung kann auf die Datenbank aber nicht zugreifen was ich an einem Runtime Error 13 - type mismatch an dieser Stelle festellen kann. Könnte es sich um dieses Problem handeln? https://learn.microsoft.com/de-de/troubleshoot/sql/connect/odbc-tool-displays-32-bit-64-bit :
Bearbeitet durch User
Du wirst in die beiden leeren Eingabefelder auch etwas eingeben müssen, mindestens "Datenquellenname" darf nicht leer sein.
Das ist normal und richtig so. Früher musste man /wissen/, mit welcher Variante man es zu tun hat, optisch unterschieden die sich nicht (d.h. den in Klammern stehenden Zusatz "32 Bit" oder "64 Bit" gab es nicht, ebensowenig wie passende Startmenüeinträge). Man musste /wissen/, ob man c:\windows\system32\odbcad32.exe oder c:\windows\syswow64\odbcad32.exe aufgerufen hatte. Und --vollkommen logisch-- die Variante im system32-Verzeichnis war (und ist) die 64-Bit-Variante, während die Variante im syswow64-Verzeichnis die 32-Bit-Variante ist.
habe ich eingentlich gemacht. Dort habe ich den Dateinamen Brillant.mdb ohne Pfad eingegeben obwohl er bei "Datenbank:" schon mit dem vollen Pfad steht. Er wird dort beim grafischen Auswählen der Datei nicht automatisch übernommen was ich meine daß es beim ODBC Registrieren von XP noch gemacht wird. Ohne diesen manuellen Eintrag steht dann auch in der 32 und 64 bit Tabelle nichts drin. D.h. der Dateiname Brillant.mdb wird direkt dorthin übernommen. :
Bearbeitet durch User
Windows 11 genau das gleiche Verhalten. Hier der Screendump von meinen Einstellungen. Weis nicht wie ich da weiter komme. Angeblich sollen 32bit ODBC Treiber funktionieren.
Angehängte Dateien:
Welches? Den ausgegrauten Button im ODBC-Dialog kannst Du nicht meinen.
Du könntest mit irgendeiner beliebigen 32-Bit-Anwendung wie z.B. Excel versuchen, auf die 32-Bit-ODBC-Quelle zuzugreifen.
Falsch! Der Datenquellenname darf in vielen Fällen keinen Punkt enthalten. Übrigens auch etliche andere Zeichen nicht. Das hängt allerdings stark von der Anwendung ab, die letztlich auf die Datenquelle zugreift. Die kann beliebig beschissen programmiert sein... Auf der sicheren Seite bist du, wenn du nur Buchstaben, Ziffern und maximal noch den Unterstrich verwendest. Also im vorliegenden Fall würde ich die Datenquelle einfach "brilliant" nennen und gut isses.
Richtig! Das wars schon. Die Anwendung sieht jetzt die Rezepte aus der Datenbank. Der Datenbankname schreibt sich im Übrigen fälschlicherweise auch noch brillant ohne i nach dem Doppel-L was man auch noch richtig machen muß. Es kommt jetzt dafür der nächste Fehler, daß das Gerät an der Schnittstelle nicht verfügbar ist. Das liegt jetzt aber daran, daß der Supercom Treiber für das 3964 Protokoll auf die Fresse fliegt, weil er auf dem W11 PC keine einzige COM Schnittstelle findet. Derweil vielen Dank an @observer
"Fälschlicherweise"?
Die 64-bit-Version von MSO nimmt man ohnehin nur wenn man zwingend muss. Die 32-bit-Version genügt vollkommen, wenn man nicht gerade Dateien größer 1GB bearbeiten muss.
Es gibt Leute, die das anders sehen und meinen, sie müssten ihren Rechner von "überflüssigem" und "veralteten" 32-Bit-Zeug "freihalten". Die bekommen dann halt irgendwann lustige Probleme. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
