Access-o-Mania

Hallo,
ich kriege mein TreeView-Formular unter 64Bit-Access (aktuell 2016) nicht zum Laufen...

Das originale TreeView-Element, das bisher benutzt wurde und unter allen 32Bit-Versionen funktionierte, bringt in dieser Zeile den Fehler 2683, "In diesem Steuerelement befindet sich kein Objekt.":
Set TrVObj = Me.TrVElement.Object
wobei TrVElement der Name des TreeView-Steuerelements ist und TrVObj deklariert wurde:
Private TrVObj As MSComctlLib.TreeView

Wenn ich das TreeView-Element lösche und neu einfüge, wird mir nur "CTreeView Control" angeboten, das aber bringt in der gleichen Zeile und mit den gleichen Bedingungen wie vorher/oben statt 2683 den Fehler 13, "Typen unverträglich".
Das in Ratschlägen empfohlene "Microsoft TreeView Control, version 6.0" fehlt in meiner Auflistung.

Das alte TreeView hat als Klasse "MSComctlLib.TreeCtrl.2" eingetragen, das neue "CTREEVIEW.CTreeViewCtrl.1".

Muß ich die Deklaration statt mit "MSComctlLib.TreeView" evtl. anders machen?

Die MSCOMCTL.OCX ist auf dem Rechner vorhanden und in den Verweisen hatte ich eingetragen "Microsoft Windows Common Controls 6.0 (SP6)" und "Microsoft ActiveX Data Objects 2.1 Library".
Letzteres hatte ich testhalber mal gegen das in der Liste verfügbare "Microsoft ActiveX Data Objects 6.1 Library" ausgetauscht und zusätzlich das "Microsoft ActiveX Data Objects (Multi-dimensional) 6.0 Library" mit reingenommen, aber ohne irgendwelche Auswirkungen auf das Problem.

Wer kann mir da einen Tipp geben?
Muß ich auf dem 64Bit-System eine Systemdatei dazunehmen und sie registrieren?

danke

Hallo,

du benötigst eine 64bit-Version des Controls.

Siehe hier :  http://www.access-im-unternehmen.de/1136

Hi & vielen Dank,
diesen Thread kannte ich, aber

• sehe ich dort keinen Download-Link oder ähnliches
• ist diese Datei auf diesem 64Bit-System bereits vorhanden gewesen - wie kommt denn da eine 32Bit-Version drauf?

danke nochmal

Hast du nachgesehen ob die 64Bit Version installiert ist?
Wo man die Daten runterladen kann, scheint irgendwie niemand beantworten zu können.

Zumindest schweigen da alle in den diversen Threads.
Ich hab auch nur 32Bit.
Generell können aber beide Versionen darauf sein.
Weiß aber nicht, ob beide Versionen in der Registry den gleichen Schlüssel verwenden.

Hallo,

Im besagten Link gibt es unter "Experimente" die Auswahl eines "Microsoft Treeview Control ".

Sollte der unter Access 2016 (365)  64bit vorhanden sein, dann ist die 64bit-Version installiert.

Zitat von: micmen am September 20, 2019, 16:31:32(...)
Wenn ich das TreeView-Element lösche und neu einfüge, wird mir nur "CTreeView Control" angeboten, (...)
Das in Ratschlägen empfohlene "Microsoft TreeView Control, version 6.0" fehlt in meiner Auflistung.

so sieht es bei diesem System aus...

Zitat von: markus888 am September 23, 2019, 14:33:30Hast du nachgesehen ob die 64Bit Version installiert ist?
(...)

Ich habe den Rechner zur Zeit nicht bei mir - kannst Du mir beschreiben, wie man das rauskriegt, so daß ich jemanden per mail/Telefon anleiten kann, nachzusehen?


danke

Zitat von: micmen am September 23, 2019, 20:02:20kannst Du mir beschreiben, wie man das rauskriegt, so daß ich jemanden per mail/Telefon anleiten kann, nachzusehen?

Vielleicht liest du mich mal kurz in die Grundlagen etwas ein, damit du ein Grundverständis der Thematik hast.
Ich hatte mal einen guten Artikel dazu. Leider existiert der Link zwischenzeitlich nicht mehr.

https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/

Hi & danke,
es geht, wie geschrieben, jetzt ein paar Tage nicht um mich, der Rechner ist gerade bei jemand anderem, der schon intensiv mit TreeView's gearbeitet hat (ich noch nicht). Dem müßte ich, wie halt geschrieben, solche Dinge jetzt aus der Ferne erklären, per mail oder Telefon.
Der wird von mir aber keine Grundsatz-Monologe vorgesetzt bekommen wollen, sondern knackig wissen, was ganz konkret er tun soll.  :)

In Deinem verlinkten Text habe ich nix dazu gefunden, wie man so eine Datei zuverlässig darauf prüft, ob es eine 32- oder 64Bit-Version ist. Da steht quasi, das Unterscheidungsmerkmal wäre der Ordner, und klar, die Datei liegt in SysWOW64, sonst wäre ich ja stutzig geworden...

Also soll ich jetzt blind annehmen, daß das die 64Bit-Version ist, weil irgendein (vermutlich Microsoft-)Setup die Datei dorthin installiert hat? Oder soll er doch im Notepad mal reinschauen o.ä.?

danke

Zitat von: micmen am September 24, 2019, 11:33:49
...die Datei liegt in SysWOW64,

Nur mal kurz angemerkt: In SysWow64 liegen die Dateien des 32-bit Subsystems!

oha...!

entweder bringe ich da jetzt in der Erinnerung was durcheinander, oder da ist dann tatsächlich die 32'er Datei drauf...

danke, ich lasse das checken!

Zitat von: micmen am September 24, 2019, 15:34:38
oha...!

Irgendwie hätte ich angenommen, dass du den Sinn des Artikel erkennen könntest.
Die wichtigsten Grundlagen sollte man kennen...

Also ich weiß nicht, ich finde keine Hinweise darauf, daß es von dieser MSCOMCTL.ocx überhaupt 2 Versionen gibt, 32Bit und 64Bit? Ich finde nur Hinweise auf eine Version, die für VB 6 vorgesehen war.

Auch hier TreeView 64bit ist da – Anwendungen umrüsten (http://"http://www.access-im-unternehmen.de/1136") ist lediglich von einer "passenden Version" die Rede, nicht von einer 64Bit-Version, außerdem wird dort keine Quelle angegeben, daß man selbst prüfen könnte, woher die das haben, und sie schreiben Null darüber, wie sie sich diese Version besorgt haben - die haben einfach ein 64Bit-System genommen und losgelegt.

Und auf einem anderen System, das ich hier gerade benutze, habe ich (schon immer) die Kombination Windows64 und Office32 und dort liegt die Datei im SysWOW64-Verzeichnis, trotzdem wird mir aber in Access das "Microsoft TreeView Control, version 6.0" angeboten, das auf dem System mit Office64 fehlt...

• Also ist das sichergestellt, daß es von der MSCOMCTL.ocx eine 64Bit-Version gibt?
• Und was macht man, wenn einem die 32Bit-Version auf das System installiert wurde?

danke

Hallo,

ja, es ist ein Krux.

Evtl. gibt es das 64bit Control nur in der Office 365 64bit Version.   Auf meiner Win10 64bit/Office 64bit -Installation finde ich das Treeview Control auch nicht.

Hier eine Alternative, kostet aber:

https://www.picoware.de/info/treeview.htm

Zitatdort liegt die Datei im SysWOW64-Verzeichnis, trotzdem wird mir aber in Access das "Microsoft TreeView Control, version 6.0" angeboten,

Das ist ja auch richtig, weil das "SysWoW64"-Verzeichnis die 32bit-dll (ocx)-Versionen der einzelnen installierten (auch Windows) DLL-Dateien enthält (unter anderem auch eine 32bit-Version der Regsvr32.exe, was u. U. zu beachten ist.)

SysWOW64  ---> Windows(32) On Windows64 


1)  "sichergestellt" ist das von niemanden

2) wenn die Office32bit-Version (egal, ob unter Win10-32bit oder Win10-64bit) installiert ist, dann brauchst Du gar nichts zu machen, sofern nicht ein Klotz durch irgendein Update zwischen  die Beine geworfen wurde und die richtige MSCOMCTL.OCX-Version (nochmal) registriert werden muss.  Oder verstehe ich die Frage falsch?

Zitat von: DF6GL am September 24, 2019, 19:42:01Evtl. gibt es das 64bit Control nur in der Office 365 64bit Version.   Auf meiner Win10 64bit/Office 64bit -Installation finde ich das Treeview Control auch nicht.

ah, ok...
das klang hier in diesem Thread für mich bisher ganz anders...

Zitat von: DF6GL am September 24, 2019, 19:42:01

Zitatdort liegt die Datei im SysWOW64-Verzeichnis, trotzdem wird mir aber in Access das "Microsoft TreeView Control, version 6.0" angeboten,

Das ist ja auch richtig, weil das "SysWoW64"-Verzeichnis die 32bit-dll (ocx)-Versionen der einzelnen installierten (auch Windows) DLL-Dateien enthält (unter anderem auch eine 32bit-Version der Regsvr32.exe, was u. U. zu beachten ist.)

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?
Ich habe es auch mal testen lassen, auf dem mir zur Zeit vorliegenden System mit 32Bit-Office ein TreeView "Microsoft TreeView Control, version 6.0" in ein Formular (einer ansonsten leeren Datenbank-Datei) zu holen, die Datei zu mailen, und das Formular auf besagtem System mit 64Bit-Office importieren zu lassen. Wäre zu schön gewesen...  ;D Das System mosert, akzeptiert dieses TreeView genauso wenig wie das, das original in den ganzen 32Bit-Varianten von Office benutzt wurde und immer und überall funktionierte.

Zitat von: DF6GL am September 24, 2019, 19:42:01Oder verstehe ich die Frage falsch?

leider ja...  ;D ;D
Siehe oben ging es darum, daß mit einer 32Bit-Version der OCX auf einem älteren System mit 32Bit-Office eine Komponente verfügbar ist, die mit einer 32Bit-Version der OCX auf einem neueren System mit 64Bit-Office nicht verfügbar ist (was mir unlogisch erscheint, deswegen aber noch lange nicht unlogisch sein muß  ;D ).


danke !

Zitat von: micmen am September 25, 2019, 11:09:31
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.

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

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.

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 (https://docs.microsoft.com/en-us/officeupdates/monthly-channel-2017#office-suite-non-security-updates-7)
Im Semi-Annual Channel entsprechend später und sicherlich ebenso in der Retail-Version von Office 2019.

Zitat von: PhilS am September 25, 2019, 13:06:30

Zitat von: micmen am September 25, 2019, 11:09:31
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"?)

Zitat von: PhilS am September 25, 2019, 13:06:301.) 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...

Zitat von: PhilS am September 25, 2019, 13:06:302.) 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).

Zitat von: PhilS am September 25, 2019, 13:06:303.) 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 (https://docs.microsoft.com/en-us/officeupdates/monthly-channel-2017#office-suite-non-security-updates-7)
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!  ;D
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

Zitat von: micmen am September 25, 2019, 14:38:16

Zitat von: PhilS am September 25, 2019, 13:06:301.) 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.

Zitat von: micmen am September 25, 2019, 14:38:16Der 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).

Zitat von: micmen am September 25, 2019, 14:38:16
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? (https://support.office.com/en-us/article/what-s-the-difference-between-office-365-and-office-2019-ed447ebf-6060-46f9-9e90-a239bd27eb96)

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.

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?

Zitat von: PhilS am September 25, 2019, 15:13:59
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.

Zitat von: PhilS am September 25, 2019, 13:06:30
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 (https://docs.microsoft.com/en-us/officeupdates/monthly-channel-2017#office-suite-non-security-updates-7)

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

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.

Zitat von: micmen am Oktober 01, 2019, 01:03:30Aber 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?

Zitat von: micmen am Oktober 01, 2019, 01:03:30
Funzt zwar unter Ac2019, [...]

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

Zitat von: markus888 am Oktober 02, 2019, 07:35:20

Zitat von: micmen am Oktober 01, 2019, 01:03:30Aber 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

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

Zitat von: Josef P. am Oktober 05, 2019, 23:10:38
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?

ZitatUnd 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

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

Zitat von: micmen am April 20, 2020, 17:57:56
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. ;D ;D

Zitat von: markus888 am April 20, 2020, 19:09:33Wenn 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. ;D ;D

• 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

Zitat von: micmen am April 20, 2020, 17:57:56
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.

Zitat von: micmen am April 21, 2020, 11:36:23
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 (https://codekabinett.com/rdumps.php?Lang=2&targetDoc=mscomctl-treeview-x64-access) veröffentlicht. Der sollte eigentlich die meisten deiner Fragen beantworten.