MSCOMCTL.OCX unter W11

[J. V. (janvi)]

Habe 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?

[Cartman E. (cartmaneric)]

J. V. schrieb:

> 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.

[Rainer Z. (netzbeschmutzer)]

J. V. schrieb:
> Kriegt man sowas unter W11 registriert?

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).

[Niklas G. (erlkoenig)]

Per KI nach Python übersetzen... 😉

[J. V. (janvi)]

>Wichtig: es ist die 32-Bit-Version von Office.

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.

[Harald K. (kirnbichler)]

J. V. schrieb:
> Die Anwendung könnte man wohl als 64 bit compilieren, aber sie bleibt
> trotzdem MFC und mit dot net ist nix.

Dagegen spricht ja auch nichts, aber ...

> Über mscomctl.ocx wird auf eine
> Access Datenbank mdb zugegriffen.

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.

[Niklas G. (erlkoenig)]

J. V. schrieb:
> 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.

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.

J. V. schrieb:
> Daran hängt dann ein handgeschnitzter ATmega der

Ein Protokoll/Datenformat von einer Sprache in die andere zu übersetzen 
ist so ziemlich der ideale Use Case für LLMs

[Rainer Z. (netzbeschmutzer)]

Harald K. schrieb:
> 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.

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.

[J. V. (janvi)]

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

[Harald K. (kirnbichler)]

J. V. schrieb:
> Die
> ausgewählte Datenbank wird zunächst mit vollem Pfad angezeigt, aber die
> ok Taste ist weiter ausgegraut.

Du wirst in die beiden leeren Eingabefelder auch etwas eingeben müssen, 
mindestens "Datenquellenname" darf nicht leer sein.

J. V. schrieb:
> Allerdings erscheint sie automatisch gleichermaßen im 64 bit Fenster.
> Sie hat in beiden Tools die Platform 32bit vermerkt.

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.

[J. V. (janvi)]

Harald K. schrieb:
> Du wirst in die beiden leeren Eingabefelder auch etwas eingeben müssen,
> mindestens "Datenquellenname" darf nicht leer sein.

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.

[J. V. (janvi)]

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.