Office: Microsoft Sicherheitsupdate tauscht MSCOMCTL.OCX

In den Fällen mit der fehlerhaften Registrierung hat Late Binding natürlich in der Tat nix genützt ;-) Es gab in meinem Umfeld aber auch einige Rechner, auf denen die neue Steuerelement-Version - warum auch immer - korrekt installiert wurde. Und da hat´s schon geholfen, denn alles läuft mit der 2.1-Version. Hab aber bislang sowieso keine Ahnung, ob die am Interface überhaupt irgendwas geändert haben. Vielleicht war das nur ein Versehen? Weiß der Teufel was da abgeht ...

 

Late binding geht aber nicht wenn du ereigniss-prozeduren hast wo MsComtlLib als parameter-übergabe drin steht ;-)

 

Wie meinst´n das? Gib mal ein Beispiel.

 

Code:

 

Reden wir aneinander vorbei? Diesen Code produziert das gute alte VB, aber Access erzeugt bei Events quasi automatisch LateBinding, nämlich dies:
Code:

 

yo, sorry, in access ist es so wie du sagst.
ich habe es mit excel verwechselt, da ist es leider nicht so.

 

Ich hab zwar die Reg bereinigt und auch neine De- und Neuregistierung der Mscomctl.ocx vorgenommen – jetzt werden meine Listviews ja immerhin schon mal wieder angezeigt – aber sobald ich mit der Maus drübergehe, kommt wie zuvor der ActiveX-MouseOver-Fehler.
Verweise im Access sind auch alle gesetzt und gefunden, Reg wie gesagt um 2.0 bereinigt, 2.1 steht mit Unterpunkten drin.

Vielleicht hat ja noch einer ne Idee.
Danke für die Infos bisher – wirklich interessant

 

\@ ohne123

Im Netz hatte ich gelesen, daß einer diesen Fehler weg bekam, indem er das Control löschte und neu hinzufügte.

http://intellipoint.wordpress.com/20...cx/#comment-41

 

Hallo zusammen,
wir setzen die Common Controls nur mit Late Binding in unseren Anwendungen ein und löschen jetzt nur noch den leeren 2.0-Schlüssel programmgesteuert, und es läuft alles tadellos. (Ohne Neuregistrierung oder so).

 

Hallo Access-Fans,

weiß jemand von Euch, ob M$ das in diesem Thread diskutierte Registrierungsprobem mit 'MSCOMCTL.OCX' an einem der letzten Patch-Dienstage von alleine behoben hat, oder muß man immer noch selbst handeln?
Habe nämlich die Möglichtkeit, eine selbstentwicklte kombinierte Access/Excel-Anwendung an eine deutschlandweit agierende Firma zu verkaufen.
Doch bei dem gravierenden Problem bin ich ja nur auf Achse, um Installationsunstimmigkeiten zu beseitigen.

Gruß von Luschi
aus klein-Paris

 

Auf Achse? Nutzt du keine Fernwartungssoftware (Teamviewer, Vnc und Co)? Fährst du wirklich für einen Mausklick durch die ganze Republik? Tewamviewer ist inzwischen sogar fürs Smartphone erhältlich, was bedeutet, dass du deine Kunden auch vom Sonnendeck aus fernsteuern kannst...

 

Hallo Atrus,

hatte eigentlich auch gedacht, daß in Zeiten von iPhone/Smartphone & Co. die Dienstreisen sich erheblich reduzieren.
Aber gerade im Bankenumfeld, ist man da als externer Zulieferer ein Eindringling, der auf das Schärfste kontrolliert werden muß.
Da muß ich mit meinem USB-Stick zum Administrator bringen, der prüft und prüft und ...dann wird die Software jedem User bereitgestellt und ich darf dann an jedem Rechner die Veränderungen demonstrieren.
Deshalb bin ich sehr daran interessiert zu wissen, ob M$ hier den Fehler von selbst bereinigt hat.

Gruß von Luschi
aus klein-Paris

PS: schließlich muß ich ja die Reisespesen auch in Rechnung stellen!

 

Hallo,

aktuell habe ich den Fall, dass mein Entwicklungs-PC ausgestattet ist mit Windows 7 (32bit), Access XP, VB6 und Rest Office 2010. Dort wurde das Update installiert und nach Deregistrierung sowie Neuregistrierung funktionieren die Controlls wie TreeView und ListView einwandfrei ohne Codeänderung.

Nur wenn ich die Anwendungen auf unseren produktiven Terminalserver mit Windows Server 2003, Office XP, Excel 2010 ausrolle, erhalte ich dort eine Fehlermeldung: "Verweis NICHT VORHANDEN: Microsoft Windows Common Controls 6.0 (SP6)".

Dies hängt vermutlich mit der neuen Version des OCX zusammen. Wie geht ihr in solch einem Fall vor? Neues OCX einfach händisch auf dem Produktivsystem registrieren? Update manuell einspielen? Welches?

Grüße,
Stefan

 

Hallo Stefan,

als erstes solltest Du auf diesem Sytem Access öffnen ein Formular einfügen und dort ein Treeview erstellen. Dann schau Dir mal den Vba-Verweis darauf an.
Ich hatte z.B.: vor 4 Wochen den Fall, daß der Verweis auf: Microsoft Windows Common Controls 6.0 (SP4)
Ich dachte, ich seh nicht richtig. Da hatte ich erst mal das Vergnügen, den Admin zu überzeugen, hier ein Update surchzuführen.

Gruß von Luschi
aus klein-Paris

 

Hallo,

wenn ich auf dem Server ein TreeView einfüge steht in den Verweisen auch "Microsoft Windows Common Controls 6.0 (SP6)". Ich vermute, dass es an der geänderten internen Versionsnummer liegt, dass Access/VBA die beiden OCXs als nicht identisch ansieht.

Ich bin unsicher, wie ich nun vorgehen sollte? Update auch auf dem Server einspielen? Das könnte ja auch unerwünschte Seiteneffekte haben.

Grüße,
Stefan