Office: (Office 2016) Ribbonleiste aktualisiert sich nur manchmal

Hallo,

ich habe ein Problem mit benutzerdefinierten Ribbon-Leisten in meiner Access-Datenbank 2016 und beiße mir schon seit Tagen die Zähne aus.

Ich habe in einem Formular unter Eigenschaften --> Name des Menübandes ein benutzerdefiniertes Ribbon zugewiesen.
Zusätzlich habe ich in dem dazugehörigen Unterformular ebenfalls ein anderes benutzerdefiniertes Ribbon zugewiesen.

Beide Ribbons enthalten ein Drop-Downfeld, welches sich aus einer Tabelle Werte holt.

Beim Öffnen des Formulars wird auch alles richtig angezeigt. Wenn mein Fokus auf dem Hauptformular steht, wird das entsprechende Ribbon mit dem richtigen Datensatz im Drop-Downfeld angezeigt. Wenn ich einen Wert im Drop-Downfeld ändere und auf das Unterformular wechsle, erscheint das zugeordnete Ribbon des Uforms mit dem entsprechend ausgewählten Datensatz im Drop-Downfeld.

Wenn ich nun zwischen Haupt- und Unterformular hin und her springe und den Wert im Drop-Downfeld ändere, funktioniert das auch 2 mal ohne Probleme.

Wenn ich beim 3. mal den Wert im Drop-Down-Feld des Unterformulars ändere, dann übernimmt er diese Änderung nach einem Wechsel auf das Hauptformular plötzlich nicht mehr. Ich habe daher mal zum Testen eine Msg-Box im Callback "GetSelectedItemIndexDropDown" eingefügt. Wenn ich die Datenbank dann neu starte, dann kommt beim Wechsel zwischen Hform und Uform 2 mal die eingefügte Meldung der Msg-Box und beim 3. mal nichts mehr. Das heißt, das Callback wird ab dem 3. mal nicht mehr ausgeführt.

Ich vermute mal, es liegt am Cache des Ribbons. Ich habe daher auch schon mit gobjRibbon.InvalidateControl "dropdown_1" versucht, das Ribbon beim Wechsel auf das Hauptformular gezielt zu aktualisieren, jedoch ohne Erfolg. Auch gobjRibbon.Invalidate habe ich schon versucht.

Hat von euch noch Jemand eine Idee, woran es liegen könnte bzw. ob es eine Einstellung hierzu gibt oder ein XML-Eintrag in der USysRibbons.

Vorab besten Dank.

Grüße TOKO

:)

 

Hallo,

ich habe zwar unter Access noch keine Ribbon gebaut, aber von Excel weiß ich, dass z.B. nach aufgetreten Fehlern der Verweis auf den Ribbon weg sein kann.
Ist das eingetreten, funktionieren die Callbacks nicht mehr...
Und auch alle ..Invalidates scheitern fortan, weil die z.B. gobjRibbon leer ist.

Unter Excel rette ich deshalb den Verweis z.B. auf einem Blatt oder in einem Namen und kann ihn später bei Bedarf wiederherstellen.

Alle Invaidates schicke ich deshalb über eine Function, die feststellt, ob der Verweis noch da ist und diesen bei Bedarf wiederherstellt.

Da ich Deinen Code hierzu nicht sehe, weiß ich nicht wie Du das machst aber vielleicht kannst Du ja Erkenntnisse aus u.a. Beispiel ziehen und für Access anpassen..

Code:

____________________
viele Grüße aus Freigericht
Karl-Heinz

 

\@volti,
so einen Code halte ich grundsätzlich für problematisch.
Du setzt einfach einen Pointer ohne den Reference-Counter zu ändern.

Das ist eine optimale Vorgehensweise für unerklärliche Abstürze einer Anwendung, da dieser nicht unmittelbar auf den Code folgt.
Vielleicht fängt Access/Excel das auch irgendwie ab, empfehlenswert erscheint es mir aber nicht.

 

Hallo Markus,

ich weiß nicht, was an der Vorgehensweise, sich die Referenz zum Ribbon irgendwo zu speichern und bei Bedarf wiederherzustellen, problematisch sein sollte.

Diese Vorgehensweise wende ich (und auch andere) (unter Excel) seit 10 Jahren in 'zig Dateien an und da hat es noch nie einen Absturz deswegen gegeben.

Und was das jetzt mit Änderung des Referenzcounters zu tun hat erschließt sich mir nicht. Fehlt mir da eine Erkenntnis oder ist es ein Access-Problem?
Möglicherweise liege ich ja auch falsch, denn der code IgobjRibbon.InvalidateControl ließ mich annehmen, dass es ein benutzerdefinierter Ribbon ist.

Aber es war ja nur ein Vorschlag...

viele Grüße
Karl-Heinz

 

Markus meint den COM Referenzzähler; also ein eher allgemeines Problem, dass ebenso in Excel (theoretisch) besteht.

Im Zusammenhang mit dem Ribbon sehe ich da allerdings kein echtes Problem. Das RibbonObjekt an sich (nicht ein Variable die darauf zeigt) besteht sowieso für die Laufzeit der Host-Anwendung (Access/Excel), wenn es eliminiert wird, würde ich nicht damit rechnen, dass noch irgendwelcher VBA Code ausgeführt wird, der wegen dem falschen RefCounter-Stand auf das nicht mehr existierende Objekt zugreifen will.

 

Gar nichts.
Besser ist aus meiner Sicht eine saubere Programmierung mit einem sinnvollen Error Handling anzustreben, dann braucht man das ja eh nicht - und auch alle anderen Variablen und Objekte die man so verwendet bleiben erhalten. *wink.gif*

Referencecountig ist ein fundamentales Konzept bei VBA.
Wie das funktioniert ist im Prinzip nicht interessant, außer man beginnt Dinge zu tun die nicht vorgesehen sind - dann ist es gut das Konzept zu verstehen.

@sonic8, das Problem müsste ja spätestens dann entstehen, wenn die globale Variable beim zweiten mal freigegeben wird.
Es muss also einen Grund geben, warum das Objekt nicht freigegeben wird.
Ich habe mich da nicht vertieft.
Aber z.B. bei der Standard Instanz eines Formulares wird in so einem Fall ja auch nicht freigegeben.
Würde man aber ein Formular mittels new erzeugen, würde die sich das Formular schließen und bei Freigabe der letzten Referenz knallt es dann vermutlich - müsste ich aber testen.

Möglicherweise ist das Verhalten auf das Predeclared Attribut zurückzuführen.

Hier ein simples Beispiel, wie Ref Counting berücksichtigt wird:

Code:

Das Set erhöht den Counter.
Die Adresse wird dann einfach aus Obj wieder gelöscht und alles ist im Butter.
Dann klappt das dann mit jedem Objekt.
Natürlich sollte man auch sauber prüfen, ob der Objekttyp passt und der Pointer auch valide ist.

LG Markus

 

Das Set erhöht den Counter.
Die Adresse wird dann einfach aus Obj wieder gelöscht und alles ist im Butter.
Dann klappt das dann mit jedem Objekt.

Das finde ich eine ziemlich gute Lösung!
Ich hatte daran gedacht direkt IUnknown.AddRef aufzurufen, um den Zähler explizit heraufzusetzen, aber das ist wesentlich komplizierter und erfordert zusätzliche APIs.

 

Vielen Dank für eure Antworten. Den Code habe ich wie folgt auf Access angepasst:
Code:

Wenn ich zwischen Form und UForm hin und her wechsle, aktualisiere ich jedesmal das Ribbon mit der o.g. Sub "Ribbon_aktualisieren".

Allerdings hat sich nichts geändert, das Problem mit dem Drop-Down-Feld besteht immer noch.

Ich bin mir allerdings auch nicht sicher, ob die Zeile "CLngPtr(Get_Property("Ribbon"))" richtig ist.

Das hatte ich beim Stöbern im Netz gefunden.

Muss denn anstatt "Ribbon" der Name des jeweiligen Ribbons eingesetzt werden?

 

Diese Frage erstaunt. Du musst doch wissen, was in der Funktion Get_Property() passiert.

Du musst in der Prozedur 'RibbonInit' den Objekt-Pointer auf das RibbonUI ausfallsicher speichern.
Entweder in einer Tabelle oder vlt. besser als TempVar. Wenn du ihn dann später benötigst, holst du ihn von dort ab.

Code:

 

Hab ich auch vor ewigen Zeiten aus dem Netz.
Die Gesamtproblematik ist aber, dass ich nicht feststellen kann, ob es sich um eine gültige Referenz handelt.
Falls nicht, verabschiedet sich Access.

Interessant wäre also eine Möglichkeit auf eine gültige Referenz zu prüfen.
VBA Error Handling ist ja nutzlos.

 

Es scheint ja zu funktionieren.
Die Benamsung lässt darauf schließen, dass der Wert als Database Property gespeichert wird.

 

Da bleibt wohl nur die COM-API. D.h. für das vermeintliche Objekt QueryInterface für IUnknown oder IDispatch aufrufen. Dabei wird automatisch bei Erfolg auch der Referenzzähler erhöht.

Das ist nicht ganz trivial und ich würde bei dem konkreten Fall hier eher die Ungewissheit in kauf nehmen, als die schweren COM-Geschütze aufzufahren.
Wer in der Richtung trotzdem experimentieren möchte, könnte hier einen ersten Ansatzpunkt finden: Raw COM API with VBA

 

Gute Frage, ob man da in einen abfangbaren Fehler reinläuft, wenn die Referenz ungültig ist. Aber wie du sagst, man braucht das nicht unbedingt.

Bis jetzt bin ich aus Zeitgründen noch nicht in das Thema COM eingetaucht.
Da fehlt mir noch etwas das Gefühl für die Thematik. *Smilie

 

Nö, wenn Referenz kaputt, dann auch kein valider Funktionpointer mehr für Queryinterface. Man könnte jetzt ne Plausibilitätsprüfung erstellen ( ist der Datenbereich auf den der Pointer zeigt noch valid, sind die Daten in dem Datenbereich noch valid und zeigen die Funktionpointer auf Speicher der als execute gesetzt ist und entspricht die Anzahl dieser mindestens die dem Objekt. ), aber eigentlich braucht man sowas nicht, weil entweder man hat ein Objekt oder nicht und stellt dies auch während und mit der eigenen Programmierung sicher.

 

In meiner grenzenloses Naivität hatte ich erwartet, dass DispCallFunc beim Aufruf von QueryInterface schon prüfen wird, ob der Objektpointer gültig ist. - Tut sie nicht und ein ungültiger Pointer führt zum Absturz.

Nicht wirklich.
Meine Recherchen zum o.a. Absturz legen nur nah, dass er sich nicht sinnvoll verhindern lässt. Die eigentlich für sowas vorgesehenen IsBadReadPtr/IsBadCodePtr Funktionen in der Windows API sind als "obsolete and should not be used" markiert, weil sie diese Plausibilitätsprüfung nicht sicher leisten können. (Bei einem kurzen Test der Funktionen liefern sie nur dann zuverlässig das erwartete Ergebnis, wenn der Pointer gültig ist, andernfalls führen diese Funktionen selbst oft schon direkt zum Absturz, den sie eigentlich verhindern sollen.)

Raymon Chen erklärt warum diese Pointer-Plausibilitätsprüfung ein hoffnungsloses Unterfangen ist.

Ein Ansatz um die Abstürze bei ungültigen Pointern zu verhindern wäre in der Theorie wohl Structured Exception Handling, aber ob sich das in VBA implementieren ließe, ist noch eine ganz andere Frage.