Deine Office 2010 Suite: Professional / Professional plus
Add Ins und/oder Zusatz-Programme installiert: Nein
Version: 32bit

Betriebssystem Version: Windows 7 Pro 32 Bit
Welches Virenschutz-Programm hast Du installiert? Avast

Was hast Du gemacht, bevor das Problem aufgetreten ist?


Was hast Du bereits versucht um das Problem zu lösen?


Fehlerbeschreibung und Nachricht
Moin!

Erst mal vielen Dank für dieses Forum und die Seiten von Gunther - damit habe ich fast alles hinbekommen, was ich mit Ribbons hinbekommen wollte.

Auch die Aufnahme von zwei Ribbons, eines für die Forms, und ein eigenes, kleines für die Reports, hat prima funktioniert. Die Ribbons haben einen Button zum Aufruf von Docmd.Printout (für den unter "Seite einrichten" zugeordneten Drucker), einen für Docmd.Runcommand accmdPrint (um einen anderen Drucker auswählen zu können), und einen zum Schließen.

Ribbon-XML:
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="CallbackOnReportLoad">
<ribbon startFromScratch="true">
<tabs>
<tab id="tabBericht" label="Bericht">
<group id="grpDrucke" label="Drucken">
<button id="btnSelect" size="large" label="Auswählen" imageMso="PrintDialogAccess" onAction="=BerichtDrucken(true)" />
<separator id="DruckeSeparator" />
<labelControl id="lblAnzahlDrucke1" label="Sofortdruck" />
<labelControl id="lblAnzahlDrucke2" label="Ausdrucke:" />
<labelControl id="lblAnzahlDrucke" getLabel="GetAnzahlDrucke" />
<button id="btnDrucke" size="large" getLabel="GetMyPrinter" imageMso="PrintDialogAccess" onAction="=BerichtDrucken(false)" />
</group>
<group id="grpSchliessen" label = " ">
<button id="btnSchließen" size="large" label="Schließen" imageMso="CancelRequest" onAction="=BerichtSchliessen()" />
</group>
</tab>
</tabs>
</ribbon>
</customUI>

Codeschnipsel:
Sub CallbackOnReportLoad(ribbon As IRibbonUI)
' Eine Kopie von RibbonUI cachen.
If gobjReportRibbon Is Nothing Then Set gobjReportRibbon = ribbon
gobjReportRibbon.Invalidate
End Sub

Public Sub GetMyPrinter(control As IRibbonControl, ByRef label)
label = Screen.ActiveReport.Printer.DeviceName
If label Is Null Then label = "Unbekannt"
End Sub

Public Sub GetAnzahlDrucke(control As IRibbonControl, ByRef label)
label = " " & Nz(AnzahlDrucke, 1)
End Sub

Public Function BerichtDrucken(selectDrucker As Boolean)
Dim RepName As String
On Error GoTo FunctionExit
If selectDrucker Then DoCmd.RunCommand acCmdPrint Else DoCmd.PrintOut acPrintAll, , , , AnzahlDrucke
[..., in der Datenquelle wird das Druckdatum eingetragen u.a.]
end function]

Das Haupt-Ribbon für das Programm ist in den Access-Optionen zur Datenbank festgelegt. Das Report-Ribbon ist in allen Report-Eigenschaften als zuständiges Menuband eingetragen.

Die Berichte öffnen mit Code für das Open-Ereignis wie diesem:
Private Sub Report_open(Cancel As Integer)
AnzahlDrucke = 1
gobjReportRibbon.InvalidateControl ("btnDrucke")
gobjReportRibbon.InvalidateControl ("lblAnzahlDrucke")
Me.RecordSource = "SELECT tblRezepte_In_Belegung.*, tblRezepte.Name, tblBelegung.Kunden, tblBelegung.RechnungsNr " & _
"FROM (tblRezepte INNER JOIN tblRezepte_In_Belegung ON tblRezepte.IdNr = tblRezepte_In_Belegung.RezeptNr) " & _
"INNER JOIN tblBelegung ON tblBelegung.IdNr = tblRezepte_In_Belegung.BelegungNr " & _
"WHERE (tblRezepte_In_Belegung.BelegungNr = " & getmarkedId & ") AND (tblRezepte_In_Belegung.LevelNr > 0);"
End Sub

Das Programm startet über ein Autoexec-Makro (Verweise prüfen, Tabellen-Backend prüfen, Hauptformular laden).

Und nun zum einzigen, für mich sehr rätselhaften Phänomen:

Wenn ich über das Hauptribbon über openReport einen Bericht öffne, passiert beim ersten Mal nach dem Programmstart nichts außer einem kurzen flackern im Ribbon. Egal welchen Bericht ich öffne. Bei allen weiteren Öffnungen irgendeines Berichtes klappt alles wie gewünscht.

Das Problem tritt nur auf, wenn der Bericht ein eigenes Ribbon eingetragen hat, hängt also offensichtlich damit zusammen.

Nun stelle ich mir nach meinem noch bescheidenen Ideen von den Abläufen beim Ribbon-Laden vor, dass es vielleicht richtig wäre, die Ribbons vorher zu laden und nicht erst beim Öffnen des Reports. Das habe ich dann auch versucht, mit dem Code der Funktion "LoadRibbons" Gunthers Beispieldatenbank. Es funktioniert nicht, sondern bricht mit dem Fehler 32609 ab, der nach Gunthers Kommentar "Code schon geladen" bedeutet. Habe auch nachgeprüft, ob diese Meldung auch für beide Ribbons kommt, und ja, so ist es. Für das Hauptribbon hätte ich das verstanden, für das Berichtsribbon nicht.

Ich habe auch mal versucht, da es ja ohne dieses Extra-Laden beim Hauptformular klappt, einfach mal den Bericht vorweg in der Init-Routine hidden zu laden und wieder zu schließen. Da bricht das Autoexec-Makro dann mit einer Fehlermeldung ab, wenn ich die schließe, läuft das Programm trotzdem korrekt, und siehe: Die Berichte öffnen schon beim ersten Mal! So falsch ist die Idee also wohl nicht, aber warum der Fehler beim Report-Öffnen, und warum ist, obwohl das nicht klappt, dann das Ribbon offensichtlich initialisiert? Hab's auch mal sichtbar zum Öffnen aufgerufen: Es wird nicht geöffnet - genau die Zeile (openreport...) löst den Makro-Halt aus.

Was vielleicht nicht richtig ist, ist das invalidate innerhalb der OnLoad-Callbacks?
Bezüglich der Berichte ist es vermutlich einfach sinnlos, aber unschädlich?
Beim Hauptformular gibt es aber kein weiteres Invalidate, und mit dem im OnLoad klappts.
Das Hauptformular-Ribbon zickt ja aber beim ersten Öffnen des Formulares nicht.
Und die LoadRibbons-Routine funktioniert auch nicht, wenn ich die rausnehme.
Also scheint's daran nicht zu liegen.
Und die Berichte öffnen auch immer noch nur beim zweiten Mal.

Ich habe m.E. alle Möglichkeiten, die in meinem Verständnishorizont nicht völlig sinnlos erscheinen, durchgespielt. Die oben beschriebene ist die einzige Variante, die überhaupt funktioniert, bloß eben mit dem Phänomen, dass es zweier Berichtsöffnungen bedarf, bis es klappt.

Ich hätt's sooo gerne richtig richtig...

Hat jemand Vorschläge, wie ich das Problem ertappen und lösen könnte?

Danke schon mal,
Tschüs,
Knut

Korrektur 1: Das Ribbon "flackert" nicht beim ersten Öffnen, sondern es springt zurück auf den ersten meiner Tabs
Korrektur 1: Natürlich Gunter, nicht Gunther - pardon...

Hallo Knut,

erstelle bitte eine Beispieldatenbank mit ein/zwei Reports und einen Formular, so das Dein Problem nachvollzogen werden kann und stelle dieses Besipiel Online (z.B.: bei http://www.file-upload.net/) und poste den Link mit einer kurzen Erklärung hier.

Hallo Gunter,

es kam wie es kommen musste... Ich habe meine Datenbank auf ein im startup öffnendes Hauptformular und einen Bericht reduziert, alles ohne Daten. Alle Ribbons gelassen, wie sie waren, und auch die Prozeduren beim Programmstart behalten. Und siehe - wenn ich einen Bericht öffne, ist er gleich zur Stelle, mit richtigem Ribbon und allem. Also niX mit erst beim zweiten Mal. Das macht das Rätsel leider nicht kleiner, und bedeutet vermutlich, dass Ihr im Forum mir nicht helfen könnt !?

Es verhalten sich alle Berichte gleich, es kann also nicht an anderen Fehlern einzelner Berichte liegen...

Schade, ich dachte, jemand schreibt "Schreib u statt x" und alles wird gut...

Vielleicht könntest Du aber noch kurz sagen, ob ein "invalidate" in "onload"-Prozeduren funktionieren kann? Danke!

Tschüs,
Knut

Hallo,

Vielleicht könntest Du aber noch kurz sagen, ob ein "invalidate" in "onload"-Prozeduren funktionieren kann? Danke!

An der Stelle macht es überhaupt keinen Sinn. Warum willst Du ein Ribbon was neu ist wieder aktualisieren?

Ja, stimmt. Bei meinen vielen Bemühungen war das wohl auch mal ein Versuch...
Und da es ja (bis auf das "Phänomen") gut funktionierte, hab ich's gelassen - never touch a running system...
Hab's jetzt rausgenommen, aber am Problem ändert das nichts.

Tschüs,
Knut

Hallo,

wie schon geschrieben, baue ein Beispiel in dem Dein Problem nachgestellt werden kann. Sobald ich Zeit habe werfe ich einen Blick darauf.

Hab ich ja versucht... Weg ist das Problem... Aber ich konnte es doch ein Stück eingrenzen:

Ich habe ja, siehe oben, im Open-Ereignis der Berichte auch gleich ein invalidate_Control drin. Und genau das löst den Fehler aus. Mittels Fehlerbehandlung weiß ich nun, dass die "Objektvariable nicht festgelegt" ist. Und dieses fehlende Objekt kann nur die gobjBerichtsRibbon sein. Es wird offensichtlich nicht am Anfang eines Open-Ereignisses initialisiert, sondern erst am Ende, deshalb klappt ein invalidate im Open-Ereignis noch nicht. Beim nächsten Öffnen irgendeinen Berichts ist dann die Initialisierung erledigt. Deshalb baust Du ja auch die LoadRibbons-Routine in Dein Beispielprogramm ein.

Also relativ klar und auch logisch, dass meine Fehler durch das Fehlen der LoadRibbons-Routine entsteht.

Aber hier beißt sich die Katze in den Schwanz: Wenn ich die einbaue, wird halt der von Dir dort erläuterte Fehler "Ribbon schon geladen" ausgelöst. Trotzdem funktioniert es danach mit den Berichten gleich, also hat die Initialisierung wohl trotzdem geklappt... Nun habe ich mit Hilfe von Resume Next in der Behandlung des "schon geladen"-Fehlers die Meldung ignoriert, und das Programm funktioniert ganz prima. Trotzdem will ich nun natürlich auch wissen, wieso das Ribbon einerseits schon geladen ist (wenn man LoadRibbons benutzt", andererseits aber wohl nicht (Wenn man Bericht öffnet ohne vorherige LoadRibbons)...

Ich habe in meine Testdatenbank die LoadRibbons-Routine eingebaut. Und prima: Dieser Fehler taucht auch auf! Hab' die Testdatei gerade hochgeladen... http://www.file-upload.net/download-371 ... accdb.html

Nun bin ich mal gespannt...

Brennt aber nicht, das Programm tut ja seinen Dienst, also keinen Stress machen. Danke schon mal!

Tschüs,
Knut

Korrektur: Auch nach dem - fehlerhaften - LoadRibbons bei Programmstart öffnen die Berichte NICHT beim ersten Mal ("Objektvariable nicht festgelegt").

Ist ja auch logischer als wenn es geklappt hätte. Bleibt um so mehr die Frage, warum LoadRibbons scheitert...

Tschüs
Knut

HAllo,

1. Fehler: Einträge aus UsysRibbons musst Du NICHT per Code laden.

... ich suche weiter