Office: Microsoft Sicherheitsupdate tauscht MSCOMCTL.OCX

Ich bin dazu übergegangen die MSCOMCTL.OCX in mein Access-Programm Verzeichnis (wo die eigenen MDBs liegen, bei mir C:\Access\) zu kopieren und diese dann im Verweis Manager bekannt zu machen. So konnten auch die PCs die Access Programme öffnen, welche das OCX nicht vorinstalliert hatten. Bis dato hatte ich dadurch keine Schwierigkeiten mit den Windows-Updates...(?)

 

Das ist auch ein interessantes Vorgehen. Reicht es denn, das OCX zu verteilen?

 

Zumindest bei meinem letzten Projekt reichte es... dort waren es aber nur 5 PCs mit Windows 7 auf denen MSCOMCTL.OCX nicht vorinstalliert war. Ich weiß nicht wie es sich verhält, wenn sich bereits eine (registrierte?) Version auf dem PC befindet...

 

Gibt es hier Neuigkeiten?? In meinem WSUS sehe ich noch immer das alte Sicherheitsupdate ?!

Klaus

 

Gestern Nacht hat es unsere Terminal Server (Windows Server 2003) erwischt, heute Morgen musste ich erst einmal alle Anwendungen neu kompilieren. Also wird offenbar immer noch das Update mit Austausch des OCX installiert.

Grüße,
Stefan

 

Wir haben hier einen tollen Mix von Office 2002, 2003 und XP und Win7 und Terminalserver, dessen Version ich aber nicht weiss.

Unsere Mitarbeiter bekommen fast täglich eine neue Version von ihrer Access ADP. Ich kompiliere diese Datei dann mit meinem Win7 64-Bit System und unsere Anwender sollen das mit XP 32-Bit nutzen. Bisher funktionierte das ganz gut.

Nach dm MS-Update ging es bei einigen Rechnern nicht mehr! Wenn wir die alte Dateiversion der ADP aufgespielt haben war wieder alles ok. Nur leider hatten die dann nicht die neusten Formulare und Berichte.

Fehler war, das ich den 2.1 Schlüssel genutzt habe, aber unsere Anwender noch den 2.0 Schlüssel hatten. Den habe ich zwar auch, aber die ADP wollte wohl dann die neuste Version nutzen.

Wir sind jetzt dazu übergegangen, einfach beide Schlüssel in die Registrierung zu packen - schon läuft es wieder. So können wir mit alten ADP und neuen ADP arbeiten. Einen "leeren" 2.0 Schlüssel hatten wir allerdings noch nicht!

Danke an alle hier, die hier was berichtet haben. Hat uns nun endlich zu der Lösung geführt!

Gruss, rastrans

 

Hallo Forum,

habe die neue Version MSCOMCTL.ocx auf einem System.
Durch manuelle neuregistrierung der Datei funktioniert das Treeview dann wieder korrekt:
RegSvr32.exe -u c:\Windows\System32\MSCOMCTL.ocx
RegSvr32.exe c:\Windows\System32\MSCOMCTL.ocx

Nun zu meinen Fragen:
A. Wie kann ich per vba-Code erkennen, das die MSCOMCTL.ocx nicht "korrekt" registiert ist?
B. Wie kann ich per vba-Code diese Registrierung durchführen lassen (auch unter WIN64bit)?

Zu A, könnte ich prüfen ob der Registireungschlüssel HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1 vorhanden ist, aber das ist jedoch keine eindeutige Lösung nach meiner ansicht?!

Gruß
JPA

 

Ich mach das per Batch...

Code:

Code:

Daran hatte ich auch überlegt, aber was spricht dagegen egal ob alt oder neu - eine neue Registrierung der Komponente durchzuführen...?

 

Hi,

tauschst du vor jedem Anlassen vorsichtshalber den Motor aus? *boah

@JPA:
vielleicht wäre es ein Weg, z.B. einen "Test-Treeview" in einem "On Error ..."-Block zu bestücken. Wenn das klappt, klingt das ganz gut. Wenn nicht, ist mglw. was faul.

 

vielen dank für deine Batch-Lösung.
Ich benötige noch eine allgemeinere Lösung, z.B. könnte ja der Ordner Windows auch anders heissen...

Bei jedem Programmstart die neuregistrierung zu machen finde ich nicht optimal.
Dennoch danke für die Rückmeldung.

 

\@JPA:
Kommt man an die Systemordner nicht auch über Platzhalter (IIRC %windir%) ran? Dann brauchst du die nicht hartverdrahten.

 

Daran habe ich auch schon gedacht, nur wie kann der code es testen?
Den das treeview erzeugt keine fehler, nur die Ereignisse werden einfach nicht angezogen (ein bekanntes problem wegen der neue mscomctl.ocx).

 

ja stimmt, den Batch kann man durchaus noch optimieren, es ist auf jedenfall ein Lösungsansatz.

Die Version von mscomctl.ocx kann ich auch auslesen, den Reg Ast 2.1 kann ich auch prüfen.
Also wenn Version=6.1.98.34 und kein 2.1Ast dann registrierung
Also wenn Version=6.1.98.34 und 2.1Ast vorhanden dann nicht registrieren, oder vieleicht doch???

Besser wäre es eindeutig feststellen zu können ob die Datei "korrekt" registriet ist!

 

Über diese Überlegung würde ich nochmals nachdenken !!! *wink.gif*

 

Erkenne gerade nicht meinen angeblichen denkfehler *depressed