Systemdatei für TreeView-Element für Access 64Bit

[micmen]

Das entscheidende an meiner Schilderung sollte sein, daß eine mit 32Bit-Office installierte OCX in der ActiveX-Auflistung genau das Element anbietet, das einem zur Verwendung unter 64Bit-Office ausdrücklich empfohlen wird, während das System mit 64Bit-Office trotz sowohl höherer Office-Version (2016 gegenüber 2010), als auch höherer Windows-Version (Win10 gegenüber Win7), dieses empfohlene Element nicht anbietet. Auf diesem System sollte doch diese OCX mindestens auf dem gleichen Stand sein, wie auf dem Jahre älteren System mit 32Bit-Office?

Nein, eben nicht! Die Common Controls (inkl. TreeView) waren lange Zeit für 64Bit gar nicht verfügbar.

Ich verstehe da ehrlich gesagt nicht die Logik... Wie paßt das denn zu dem, was ich darüber geschrieben hatte? ("mindestens"?)

1.) Ein 32Bit Office wird dir niemals eine Komponente für 64Bit anbieten!

ja, davon bin auch ich immer fest ausgegangen... wüßte nicht, welche meiner Worte einen anderen Eindruck erweckt haben...

2.) Die "Versionsnummern" in den Produktnamen (z.B. "2016") sind für neuere Office/Access Versionen nicht mehr relevant und werden deshalb von Microsoft auch immer weniger verwendet. - Die aktuelle Version von Access "2016" aus Office 365 ist neuer als Access 2019! - Deine Angabe von "Office-Version 2016" ist somit ungenügend.

Ok, hatte mit Office365 noch nicht zu tun, ich arbeite nur mit 97, 2000, (...), 2010, 2013, 2016, 2019 (wobei mit denen vor 2010 inzwischen nicht mehr). Der Win7/Office2010-Rechner wurde vor x Jahren aufgesetzt inkl. der Office-Installation und der andere vor weniger als einem Jahr. Daraus zog ich die Schlußfolgerung, daß die Komponenten des Systems mit 64Bit-Office mindestens auf dem gleichen Stand sein sollten wie die des alten Systems (und das wäre unabhängig davon, ob es ein Office365 gibt, oder nicht).

3.) Google hilft! Die Common Controls für 64Bit sind in der Office (365) Version 1707 (Build 8326.2058) des Monthly Channels enthalten. Siehe: Version 1707: July 27 - Office suite: Non-security updates
Im Semi-Annual Channel entsprechend später und sicherlich ebenso in der Retail-Version von Office 2019.

ah, danke, das ist so ein erster Lichtblick am mscomctl.ocx-Firmament! 
Jetzt stellen sich mir 2 Fragen:
Warum kriegen legale Nutzer eines solchen 64Bit-Systems nicht über MS-Updates die zum System gehörigen (64Bit) Komponenten und wo/wie kann man sich die in Eigenregie besorgen?
Hier im Thread hieß es, noch nie hätte jemand eine Downloadquelle genannt, sinngemäß "keiner weiß, wo man die Datei herbekommt". In der verlinkten Seite steht dieser Text ja explizit außerhalb des Bereichs "Office perpetual" im Bereich "Office 365 ProPlus" mit der Info, der ganze Text würde sich auf verschiedene Office365-Produkte beziehen.

Ich kenne leider auch keinen, der Office365 64Bit benutzt, von dessen System man sich die Datei kopieren könnte...

danke

[PhilS]

1.) Ein 32Bit Office wird dir niemals eine Komponente für 64Bit anbieten!

ja, davon bin auch ich immer fest ausgegangen... wüßte nicht, welche meiner Worte einen anderen Eindruck erweckt haben...

Diese Worte: "daß eine mit 32Bit-Office installierte OCX in der ActiveX-Auflistung genau das Element anbietet, das einem zur Verwendung unter 64Bit-Office ausdrücklich empfohlen wird,"

Die Auflistung der Steuerelemente im 32-bit-Office enthält keine Elemente für 64-bit-Office, egal ob empfohlen oder nicht.

Der Win7/Office2010-Rechner wurde vor x Jahren aufgesetzt inkl. der Office-Installation und der andere vor weniger als einem Jahr. Daraus zog ich die Schlußfolgerung, daß die Komponenten des Systems mit 64Bit-Office mindestens auf dem gleichen Stand sein sollten wie die des alten Systems (und das wäre unabhängig davon, ob es ein Office365 gibt, oder nicht).

Und genau das ist nicht so. Die 32bit-Version der Common Controls in ihrer aktuellen Fassung (von kleineren Updates abgesehen) gibt es seit dem Jahr 2000 und seitdem werden sie auch mit Office mitgeliefert.
Die 64bit-Version der Common Controls gibt es erst seit Juli 2017, daher werden sie erst in den danach folgenden Office Versionen mitgeliefert. Außerhalb von Office 365 ist das bisher nur Office 2019 (dies habe ich nicht verifiziert).

Jetzt stellen sich mir 2 Fragen:
Warum kriegen legale Nutzer eines solchen 64Bit-Systems nicht über MS-Updates die zum System gehörigen (64Bit) Komponenten und wo/wie kann man sich die in Eigenregie besorgen?[...]
Ich kenne leider auch keinen, der Office365 64Bit benutzt, von dessen System man sich die Datei kopieren könnte...

Für die "Einmal-Kauf-Versionen" von Office gibt es nur Sicherheitsupdates, aber keine Funktionsupdates.
Siehe: What's the difference between Office 365 and Office 2019?

Du schriebst oben, du hast Office 2019. - Dort sollte die 64bit-Version der Common Controls mitgeliefert werden. - Sie werden aber vermutlich nur installiert, wenn man auch die 64bit-Versionvon Office installiert.

Vielleicht kann ich in den nächsten Wochen mal ein "Beispiel" für die Verwendung der 64Bit-Controls erstellen und als Download, inkl. der Common Controls, veröffentlichen. - Vorausgesetzt, die EULA lässt dies zu.

[micmen]

Hi,
damit das jetzt nicht kilometerlang wird... 

Beim ersten Punkt hast Du, so scheint es, das, was ich geschrieben habe, genau verkehrt herum verstanden und verstehst es noch immer verkehrt herum...
Ich weiß aber gar nicht, wie ich das noch anders/deutlicher schreiben soll - vielleicht kann wer anderes zu Hilfe eilen und das Mißverständnis aufklären.

Beim zweiten Punkt habe ich doch nur "mindestens" geschrieben und das widerspricht doch auch in dem Post jetzt gar nicht dem, was Du jeweils geschrieben hast?

Du schriebst oben, du hast Office 2019. - Dort sollte die 64bit-Version der Common Controls mitgeliefert werden. - Sie werden aber vermutlich nur installiert, wenn man auch die 64bit-Versionvon Office installiert.

Vielleicht kann ich in den nächsten Wochen mal ein "Beispiel" für die Verwendung der 64Bit-Controls erstellen und als Download, inkl. der Common Controls, veröffentlichen. - Vorausgesetzt, die EULA lässt dies zu.

Ja, da habe ich mich nicht präzise genug ausgedrückt - die 2019er Version ist zwar bereits angeschafft, aber noch nirgendwo installiert, weil es noch keinen Bedarf gab. Aber kein Problem, kann ich natürlich nachholen und das prüfen.

danke !

Die Info könnte auch anderen hier mitlesenden hilfreich sein wg. Quelle für eine 64Bit-Version der mscomctl.ocx.

[markusxy]

3.) Google hilft! Die Common Controls für 64Bit sind in der Office (365) Version 1707 (Build 8326.2058) des Monthly Channels enthalten. Siehe: Version 1707: July 27 - Office suite: Non-security updates

Danke für die Info. Endlich mal eine sinnvolle Erklärung zu diesem Punkt.

[micmen]

Hat ne Weile gedauert, vorhin bin ich wieder an den Rechner gekommen. Also das ist ja ganz verrückt:
Funzt zwar unter Ac2019, das richtige TreeView-Element wird angeboten und der ganze alte Code läuft damit, nachem man das alte Steuerelement aus dem Formular gelöscht und das neue mit dem gleichen Namen reingenommen hat. Aber auch dort ist die mscomctl.ocx im SysWOW64 und nicht im System32, also sollte sie ja auch dort eine 32Bit-Datei sein?

Das bringt halt auch ein Problem: Was mache ich denn bei einem Zielsystem, das 64Bit-Office, aber die alte mscomctl.ocx hat? Ich kann dort ja nicht so einfach die Datei überschreiben - die ist ja wohl nicht abwärtskompatibel?
Ich dachte, ich kann die einfach zusätzlich in System32 kopieren, der Verweis ist auf dem Produktionsrechner ja ebenfalls auf diesen Pfad eingerichtet.

[markusxy]

Aber auch dort ist die mscomctl.ocx im SysWOW64 und nicht im System32

Was steht denn im Objektkatalog bzw. in den Verweisen für ein Pfad?

[PhilS]

Funzt zwar unter Ac2019, [...]

Nur der Sicherheit halber mal nachgefragt: Du hast überprüft, dass die 64Bit-Version von Access 2019 installiert wurde?

[Josef P.]

Aber auch dort ist die mscomctl.ocx im SysWOW64 und nicht im System32

Was steht denn im Objektkatalog bzw. in den Verweisen für ein Pfad?

Aus meiner Erinnerung (kann gerade nicht prüfen):
Die verwendendete 64-bit-Datei ist nicht im Windows-Pfad sondern in der Office-Struktur (irgendwo unter root) untergebracht.
In den References sieht es dann (glaube ich mich zu erinnern) aber so aus, als wäre sie im Windows-Verzeichnis.
Ich vermute, dass hier vom Office-Entwicklungsteam etwas getrickst wurde.

LG
Josef

[Josef P.]

Nachtrag:

Ein paar Daten aus meiner Access-64-Bit-Installation:
Unter Verweise (bzw. Application.References(...).FullPath) steht:
C:\Windows\system32\MSCOMCTL.OCX

Verwendet wird die MSCOMCTL.OCX aus C:\Program Files\Microsoft Office\root\vfs\System

mfg
Josef

[markusxy]

Nachtrag:

Ein paar Daten aus meiner Access-64-Bit-Installation:
Unter Verweise (bzw. Application.References(...).FullPath) steht:
C:\Windows\system32\MSCOMCTL.OCX

Verwendet wird die MSCOMCTL.OCX aus C:\Program Files\Microsoft Office\root\vfs\System

Und ich nehme jetzt an, dass in System32 nichts vorhanden ist.
Wie kann man feststellen, wo die Datei nun wirklich liegt?

[Josef P.]

Und ich nehme jetzt an, dass in System32 nichts vorhanden ist.

Genau. Weder in %windir%\System32 noch in sysWOW64 gibt es die MSCOMCTL.OCX.

Wenn ich die Datei in ..\root\vfs\System\ umbenenne, ist gibt es einen Fehler beim Öffnen eines Formulars mit einem Treeview. Daher gehe ich davon aus, dass diese dll verwendet wird.

Die MSCOMCTL.OCX im Office-Verzeichnis hat bei mir die Produktversions 7.0.52-Acc-.....
Dateiversion 7.0.52.6282
Produktname: Office Controls

Auch bei meiner Office365 32-Bit-Version ist die MSCOMCTL.OCX unter root\vfs\SystemX86 und nicht im Windows-Verzeichnis zu finden.

mfg
Josef

[micmen]

Hallo,
ich habe noch immer keine funktionierende Lösung finden können, die betroffenen Systeme haben nach wie vor diese Funktionsstörung - die leider von den Konsequenzen sehr schwerwiegend ist, das TreeView-Objekt hat eine sehr zentrale Funktion.

Meine originale Aussage "Die MSCOMCTL.OCX ist auf dem Rechner vorhanden" will ich mal zurücknehmen:
Ich denke inzwischen eher, daß ich A) die selbst auf das System kopiert hatte in der Annahme, die Datei wäre dann in zwei verschiedenen Verzeichnissen doppelt vorhanden und ich registriere die "funktionierende neue" statt der originalen, nicht funktionierenden.
Und denke, daß B) die MSCOMCTL.OCX auf Rechnern mit Windows10 prof/64bit und Office2016/64bit gar nicht vorhanden ist.

Und inzwischen habe ich mehrfach die Info bekommen, daß es bei der MSCOMCTL.OCX gar nicht 32bit und 64bit geben soll, sondern nur allgemein zum System kompatible und nicht kompatible Versionen.
Das wird in meinen Augen ein wenig unterstützt von der Tatsache, daß unter Access 2019/64bit das TreeView-Element sehr wohl funktioniert, es aber unter 2016/64bit nichts bringt, diese OCX des 2019er Systems draufzukopieren und zu registrieren.


Meine Frage lautet im Prinzip noch immer:
Weiß inzwischen wer, was man tun muß, um unter dieser Version das TreeViw-Element benutzen zu können, das man über die "Toolbox" (so heißt das, meiner Erinnerung nach), "AktiveX-Steuerelemente" in ein Formular nehmen kann?


Access 2016 ist ja inzwischen schon jahrelang draußen und von dem Problem müssen sämtliche Anwender betroffen sein, die diese Version benutzen (bzw. benutzt haben). Unter 2019/64bit funktionierte das ja wieder.

danke

[markusxy]

Hallo,
ich habe noch immer keine funktionierende Lösung finden können, die betroffenen Systeme haben nach wie vor diese Funktionsstörung - die leider von den Konsequenzen sehr schwerwiegend ist, das TreeView-Objekt hat eine sehr zentrale Funktion.

Wenn der Druck so gering ist, dass du dich nach 6 Monaten wieder meldest und uns erzählst wer aller was gemeint hat,
dann kann das nicht so schlimm sein. Jedenfalls scheinst du die Infos hier eher zu ignorieren.

Schau einfach in 12 Monaten wieder vorbei und erzähl uns die Neuigkeiten.

[micmen]

Wenn der Druck so gering ist, dass du dich nach 6 Monaten wieder meldest und uns erzählst wer aller was gemeint hat,
dann kann das nicht so schlimm sein. Jedenfalls scheinst du die Infos hier eher zu ignorieren.

Schau einfach in 12 Monaten wieder vorbei und erzähl uns die Neuigkeiten.

• Der Hellseher-Kurs, den Du da besucht hast, scheint nix getaugt zu haben. Guter Ratschlag von mir: Laß Dir die Kursgebühren zurückerstatten...    Glücklicherweise gibt es nach wie vor nur einen einzigen Anwender, der eine solche Systemkonfiguration hat - und der hat jemand anderen zur Seite, der ein von diesem Fehler nicht betroffenes System benutzt. Darum ist diese Problematik für mich zwar grundsätzlich dramatisch und entspr. auch der Druck sehr groß, mit viel Glück aber bis jetzt noch nicht aktuell geworden.
• Ich habe die Infos hier nicht ignoriert, sondern bis auf eine haben sie für mich zu keiner Lösung geführt und diese eine wäre der Rat, die ganze TreeView-Funktionalität auf einer anderen Basis nochmal komplett neu zu bauen. Das würde aber extrem zeitaufwendig und wenn irgend möglich, will ich das vermeiden. Zum als letztes gegebenen Tipp noch: Ein Verzeichnis root, in dem dann vfs\System liegen könnte, finde ich weder unter C:\Program Files\Microsoft Office, noch unter C:\Program Files (x86)\Microsoft Office, noch unter den Unterverzeichnissen "Office"nn dieser beiden Ordner (weder auf dem betr. System, noch auf einem System mit Win64bit/Office32bit), vielleicht gibt es das nur bei Office365?
• Wenn das der Anspruch dieses Forums wäre, alle 12 Monate evtl. mal ein Update zu bekommen, wäre es schon längst tot...

Ich kann es halt nicht recht glauben, daß MS in den betroffenen Versionen (64bit-Varianten von Office 2016 und 365, getestet ausschließlich unter Win10prof) zwar das TreeView-Element noch in seiner angebotenen Liste für zu benutzende Formular-Steuerelemente führt, das dann aber auf keine Art benutzbar zu bekommen ist. Und das nach mehreren Jahren, die das Problem jetzt schon existiert.
(man erkennt direkt beim Zufügen in den Formularentwurf schon, daß etwas nicht stimmt, weil die Beispielknoten nicht angezeigt werden, sondern das TV-Rechteck völlig leer bleibt)

Klar kann man zur Not die ganze Arbeit wegwerfen, die in die TV-Funktionalitäten gesteckt wurde, und im Prinzip wieder bei Null anfangen, aber ich halte das doch schon für nachvollziehbar, daß ich DAS nicht als die Lösung erster Wahl ansehe...?

Diese TreeView-Funktionalität wurde bereits zweimal gebaut, und so weiß ich, daß von der ersten kaum etwas für die zweite Variante zu gebrauchen war, sondern die zweite Variante im Grunde von Null an neu geschaffen werden mußte.
Das erwarte ich auch, wenn ich auf eine dritte Variante (diesmal eine aus Bordmitteln bestehende) wechseln würde.


danke

[PhilS]

Und inzwischen habe ich mehrfach die Info bekommen, daß es bei der MSCOMCTL.OCX gar nicht 32bit und 64bit geben soll, sondern nur allgemein zum System kompatible und nicht kompatible Versionen.

"allgemein zum System kompatibel" klingt sehr nebulös. Bei solchen Aussagen entsteht bei mir der Eindruck, die ungenannte Quelle dieser Information weiß nicht wirklich wovon sie redet.

Ich kann es halt nicht recht glauben, daß MS in den betroffenen Versionen (64bit-Varianten von Office 2016 und 365, getestet ausschließlich unter Win10prof) zwar das TreeView-Element noch in seiner angebotenen Liste für zu benutzende Formular-Steuerelemente führt, das dann aber auf keine Art benutzbar zu bekommen ist. Und das nach mehreren Jahren, die das Problem jetzt schon existiert.

Das Microsoft TreeView Control wird nur dann in der Liste der ActiveX-Steuerelemente angezeigt, wenn es auch eingefügt werden kann und funktioniert.
Allerdings wurde wohl bei der Ur-64bit-Version von Access 2010 eine 32bit Version der Common Controls mitgelieferte, die natürlich nicht funktioniert hat. Wenn du diese Version von Access 2010 installiert hast/hattest, könnte es evtl. auch in späteren Version zu dem Phänomen kommen.

In der aktuellen Version von Office 365x64 werden die Controls mitgeliefert, in Access 2016 (Retail) nicht.

Ich habe gerade einen Text zum Microsoft TreeView Control in 64bit Access veröffentlicht. Der sollte eigentlich die meisten deiner Fragen beantworten.