Office: Objekte ByRef an public sub übergeben

Hallo!

Innerhalb einer Excel-Arbeitsmappe existiert Folgendes:


a) Klassenmodul cBericht

b) Im VBA-Code eines Tabellenblattes zwei Subs, die wie folgt deklariert sind:
Public Sub SetBericht(ByRef Bericht As cBericht)
'...
End Sub
Public Sub GetBericht(ByRef Bericht As cBericht)
'...
End Sub

Ich habe auch schon folgende Variante probiert:
Public Sub SetBericht(ByVal Bericht As cBericht)
'...
End Sub
Public Function GetBericht() As cBericht
'...
End Function


Das führt zur Fehlermeldung:
"Private Objektmodule dürfen in öffentlichen Objektmodulen nicht als Parameter oder Rückgabetypen für öffentliche Prozeduren, als öffentliche Datenelemente, oder als Felder öffentlicher, benutzerdefinierter Typen verwendet werden."


Wie löse ich das Dilemma? Die Randbedingungen, die dabei einzuhalten sind:
- SetBericht/GetBericht müssen Public-Funktionen sein
- SetBericht/GetBericht müssen im VBA-Code des entsprechenden Tabellenblatts gespeichert sein



*** Zum Hintergrund ***

Ich habe ein Klassenmodul cBericht. Dazu habe ich eine ganze Reihe von Darstellungsmöglichkeiten, unter Anderem:

- Im Excel Eingabe- und Bearbeitungsformular
- Als Excel-Tabelle
- Als fertig formatierter Bericht in Word

Diese Darstellungsmöglichkeiten sind regelmäßigen Änderungen unterworfen und auch sehr zahlreich, während die cBericht-Klasse auch in Zukunft konstant bleiben wird.

Die Darstellung soll wg. Wartbarkeit&Co. *nicht* in cBericht implementiert werden, sondern "vor Ort", also z.B. im VBA-Code des jeweiligen Sheets bzw. im VBA-Code des Word-Basisdokuments.

Wie realisiere ich das ganze in VBA, und zwar *sauber*? (Es geht um ein größeres Projekt, das auch in Zukunft noch wachsen wird. Aus diesem Grund ist es nötig, dass dem Ganzen eine saubere und einfach wartbare Programmstruktur zugrunde liegt und *keine* Ansammlung von Hacks oder dergleichen.)

:)

 

Hallo!

Ich habe mir mittlerweile folgenden Workaround überlegt:

Mein Klassenmodul cBericht hat eine Funktion GetAV und SetAV. GetAV überträgt alle Inhalte in einen Datenfeld aus Variants und SetAV nimmt ein Datenfeld aus Variants und füllt die Inhalte in die Variablen des Objekts. Das funktioniert auch mit Versions- und Objektkontrolle, also im Prinzip genauso wie ich Objektdaten in einen Stream schreiben bzw. daraus lesen würde.

Damit kann ich meine oben geplante Programmstruktur realisieren, wenn auch etwas umständlicher in der Implementierung.

An einer Möglichkeit, eine Objektreferenz direkt zu übergeben, wie oben im Anfangsposting dargelegt, wäre ich aber nach wie vor interessiert. Wenn also jemand eine Idee hat...

 

Hi,

Warum denn? Tu die in ein normales Modul, dann sollte das funktionieren.

cu, Bernd

 

Hi,

wie Bernd schon gesagt hat würde ich den Code auch in ein Modul auslagern.
Den Subs kannst du dann ja das Tabellenblatt als 2ten Parameter übergeben.

 

Ziel ist eigentlich die feste und auch für den Anwender transparent handhabbare Verknüpfung zwischen Sheet und VBA-Code. Wenn die Darstellungsfunktionen Bestandteil der Sheets sind, werden sie automatisch mitkopiert, sobald der Anwender (oder ein Makro) das Sheet z.B. in eine andere Arbeitsmappe kopiert.

Wenn der zur Darstellung nötige VBA-Code aber als separates Modul existiert, muss ich einige Klimmzüge bewerkstelligen, dass die Anwender nicht plötzlich mit Tabellenblättern dastehen, die nutzlos sind, weil der zugehörige VBA-Code plötzlich fehlt.

Anders ausgedrückt: Der Anwender soll sich darauf verlassen können, dass wenn er ein Sheet hat, auch immer die Darstellung funktioniert, selbst wenn er mit dem Sheet alles das anstellt, was Excel dem normalen Anwender so an Manipulationen (Umbenennen, verschieben, kopieren, als separates Dokument per Email versenden...) ermöglicht.

Das mit dem Modul werde ich aber mal im Hinterkopf behalten. Das könnte in anderem Zusammenhang noch sehr nützlich sein; vielen Dank für den Hinweis!

 

Hi,

Hmm, dann darfst Du aber auch keine Klassenmodule benutzen, oder?

cu, Bernd

 

Hallo, Bernd!

Doch, das geht durchaus, da die Arbeitsmappen-Vorlagen, in denen letztlich mit den Sheets gearbeitet wird, immer das Klassenmodul beinhalten. Und wie schon gesagt, ist cBericht "zukunftssicher" (Heißt: Änderungen extrem selten). Wenn da alle paar Jahre mal ein Update fällig wird, ist das zu stemmen.

Anders bei den Darstellungen: Da kommen monatlich, evtl. sogar wöchentlich neue hinzu. Und dann jedesmal ein großes Update durchführen zu müssen...

 

Du könntest mit Late-Binding arbeiten, den Bericht also als Objekt übergeben und nicht als cBericht:

Code:

Damit kannst du die Klasse auch in ein Addin auslagern und die Tabellenblätter z.B. so ansprechen:
Code:

Damit hast du dann, wenn die Klasse cBericht mal geändert werden soll, nicht das Problem das du den Code in 100 Arbeitsmappen verändern mußt.

 

Hallo, Styrkar!

Klingt interessant. Ich werde mir das mal näher anschauen.

 

Hallo, Styrkar

Ich habe da doch noch ein Problem mit Deinem Vorschlag. Ich habe jetzt cBericht in ein Addin ausgelagert und das Addin auch geladen und aktiviert. Wenn ich dann aber das darauf aufbauende VBA-Projekt kompilieren will, erhalte ich an dieser Zeile

Code:

immer die Fehlermeldung "Benutzerdefinierter Typ nicht definiert".

Was mache ich fasclh, bzw. wie mache ich es richtig?

Das Late-Binding hat ja einige gravierende Nachteile (z.B. mangelnde Möglichkeit der Prüfung, ob die angesprochene Funktion überhaupt existiert, weil im Editor das Auswahlfeld nicht erscheint). Das dürfte bei der Entwicklung neuer Darstellungen für einige Probleme sorgen, fürchte ich. Es macht auch wesentlich mehr Aufwand in der Testphase - und zwar bei *jeder* Darstellung.

 

Du kannst den Bericht nur da als cBericht erstellen wo du auch die Klasse cBericht gespeichert hast. In diesem Fall also im AddIn.
In allen anderen Projekten mußt du den Bericht als Objekt definieren.
Das hat natürlich die von dir angesprochenen Nachteile.
Während der Entwicklung kannst du das Teilweise umgehen in dem du die Klasse einfach auch im Darstellungsbereich einfügst und erst auf Late-Binding umstellst wenn du das ganze rausgibst.

 

Hallo, Styrkar!

Ja, das habe ich mir schon fast gedacht.

Vielen Dank!