<\/p>\n
Im ersten Teil dieser Beitragsreihe haben wir uns mit der mehrsprachigen Gestaltung von Elementen der Benutzeroberfläche, wie Formularen und Berichten, beschäftigt. Das reicht natürlich längst nicht für eine Anwendung, die alle relevanten Texte in mehreren Sprachen anzeigt. In diesem Beitrag geht es weiter: mit der Übersetzung von Meldungsfenstern, Menüs, Ribbons und mehr.<\/b><\/p>\n
Im Beitrag Mehrsprachige Anwendungen <\/b>(Shortlink 611) haben wir eine recht bequeme Möglichkeit vorgestellt, um die Beschriftungen bestehender Formulare und Berichte sowie ihrer Steuerelemente in Tabellen einzulesen, diese zu übersetzen und die Beschriftungen bei Bedarf mit dem Text in der gewünschten Sprache auszustatten.<\/p>\n
Eine Access-Anwendung liefert aber weitaus viel mehr Stellen, deren Texte flexibel angepasst werden müssen. Die schlechte Nachricht ist, dass sich die meisten nicht so einfach einlesen lassen wie Formulare, Berichte und Steuerelemente: hier ist Handarbeit gefragt.<\/p>\n
Bevor wir in die übrigen Elemente von Access einsteigen, die noch nicht im ersten Teil unserer Beitragsreihe erläutert wurden, noch ein Nachtrag zum ersten Teil.<\/p>\n
Das Beispiel für den Einsatz der dort verwendeten Routine SpracheEinstellen <\/b>verwendete ein Kombinationsfeld, mit dem Sie die Sprache auswählen können und die nach dem Aktualisieren eine Ereignisprozedur auslöst. Diese wiederum stellt die Sprache der Steuerelemente des Formulars entsprechend dem im Kombinationsfeld ausgewählten Eintrag ein.<\/p>\n
Normalerweise stellen Sie die Sprache natürlich an zentraler Stelle ein, etwa über einen Menüpunkt, und speichern sie in einer globalen Variablen oder noch besser in einer Optionentabelle, damit diese Einstellungen sitzungsübergreifend wirken.<\/p>\n
Die Übersetzung der Eigenschaften von Formularen, Berichten und Steuerelementen erfolgt dann zwar auch durch einen Aufruf der Routine SpracheEinstellen <\/b>– diese wird jedoch direkt beim Öffnen des jeweiligen Objekts aufgerufen, etwa über die Ereignisprozedur Beim Laden <\/b>eines Formulars:<\/p>\n In diesem Fall wird die Sprache aus einer Konstanten namens cSprache <\/b>eingelesen, was eine Alternative zum flexiblen Einstellen der Anwendungssprache darstellt: Möglicherweise möchten Sie die Anwendung ja auch einfach in verschiedenen Sprachen veröffentlichen, ohne dass der Benutzer diese selbstständig anpassen kann.<\/p>\n Wohin mit der aktuellen Spracheinstellung<\/b><\/p>\n Je nachdem, ob Sie dem Kunden tatsächlich eine mehrsprachige Anwendung präsentieren möchte, deren Sprache dieser selbst einstellen kann, oder ob Sie einfach nur die Möglichkeit haben möchten, die Anwendung in der einen oder anderen Sprachversion zu vertreiben, wählen Sie eine von mehreren Varianten zum Einstellen der Sprache.<\/p>\n Wenn der Kunde selbst die Einstellung vornehmen soll, bieten Sie beispielsweise ein Formular an, das diese und andere Optionen enthält, deren Einstellungen in einer Optionentabelle gespeichert werden.<\/p>\n Informationen über das Speichern von Optionen in Tabellen erhalten Sie beispielsweise im Beitrag Anwendungsoptionen in Tabellen speichern <\/b>(Shortlink 617). Dort erfahren Sie auch, wie Sie die gespeicherten Informationen zur Laufzeit wieder verfügbar machen.<\/p>\n Wenn Sie die Anwendung zwar für mehrere Sprachen auslegen, jedoch nur in jeweils einer Sprache ausliefern möchten, sodass der Benutzer nur die voreingestellte Sprache verwenden kann, speichern Sie die ID der Sprache am einfachsten in einer Konstanten.<\/p>\n MsgBox und InputBox<\/b><\/p>\n Meldungsfenster und InputBox-Fenster sind zwei Elemente der Benutzeroberfläche, die nur per VBA-Code (eigentlich auch per Makros, aber dieses behandeln wir hier nicht) angezeigt werden können und deren Aussehen erst zur Laufzeit festgelegt wird.<\/p>\n Wir veranschaulichen die Vorgehensweise zur Internationalisierung der beiden Meldungsfensterarten anhand der MsgBox<\/b>.Die mit der InputBox<\/b>-Anweisung erzeugten Exemplare behandeln Sie analog.<\/p>\n Prinzipiell müssen Sie den üblicherweise verwendeten Aufruf des Meldungsfensters durch eine Variante ersetzen, welche die aktuelle Übersetzung des Texts aus einer Funktion liefert:<\/p>\n Im Gegensatz zu den Formularen, Berichten und Steuerelementen hat eine MsgBox<\/b>-Anweisung keine eindeutige ID (ein Steuerelement hat beispielsweise ein Host-Objekt wie ein Formular oder einen Bericht und einen Namen), über die man die entsprechenden Übersetzungen holen könnte.<\/p>\n Also legt man selbst eine ID fest, die entweder eine Zahl oder ein String ist und als Parameter der oben aufgeführten Funktion HoleUebersetzung <\/b>angegeben wird. Diese Funktion liefert dann beispielsweise aus einer Tabelle die Übersetzung des Texts in der aktuellen Anwendungssprache.<\/p>\n Den Text können Sie in der bereits vorhandenen Tabelle tblUebersetzungen <\/b>unterbringen. Dort verwenden Sie als BegriffID <\/b>am besten negative Zahlen, damit Sie diese von den übrigen für Formulare, Berichte und Steuerelemente vorgesehenen Übersetzungen unterscheiden können (und damit es eine Möglichkeit gibt, diese beim Neueinlesen der notwendigen Informationen per VBA zu löschen, ohne die Übersetzungen für Meldungsfenster und Co. zu berühren).<\/p>\n Dies könnte wie in Bild 1 aussehen. Legen Sie einfach die Übersetzungen für die in der Tabelle tblSprachen <\/b>gespeicherten Sprachen an und tragen Sie die entsprechenden Bedeutungen ein (mangels allzu umfangreicher Fremdsprachenkenntnisse belässt es der Autor bei Platzhaltertexten).<\/p>\n Bild 1: Die Übersetzungen für die Texte in Meldungsfenstern, Menüleisten und Co. können Sie ebenfalls in die Tabelle tblUebersetzungen schreiben.<\/span><\/b><\/p>\n Fehlt nur noch die Funktion HoleUebersetzung<\/b>, die lediglich aus einer einfachen DLookup<\/b>-Anweisung besteht:<\/p>\n Auch hier verwenden wir eine Konstante als Lieferant der ID der Sprache. Wenn Sie die Sprache in einer Optionentabelle oder in einer globalen Variablen vorhalten möchten, müssen Sie cSprache <\/b>durch einen entsprechenden Ausdruck oder eine Funktion ersetzen.<\/p>\n Der Aufruf des Meldungsfensters würde nun beispielsweise so aussehen:<\/p>\n Menüs<\/b><\/p>\n Bei Menüs gibt es ebenfalls verschiedene Texte, die zum Beispiel in den Eigenschaften Caption <\/b>und ToolTipText <\/b>gespeichert werden.<\/p>\n Menüs erstellt man typischerweise entweder über die Benutzeroberfläche, indem man den Anpassen-Dialog öffnet und die gewünschten Menüs zusammenstellt, oder man erzeugt diese komplett per VBA.<\/p>\n Bezüglich der Mehrsprachigkeit ergeben sich ebenfalls mehrere Möglichkeiten. Da man durchaus per VBA auf die vorhandenen Menü-, Symbol- und Kontextmenüs zugreifen kann, wäre es theoretisch kein Problem, deren Texte genau wie bei Formularen, Berichten und Steuerelementen auszulesen und diese zusammen mit den Übersetzungen in die bereits vorhandenen Tabellen zu schreiben.<\/p>\n Genauso können Sie beim Öffnen der Anwendung die Menüs mit den in den Tabellen gespeicherten Texten für die aktuell verwendete Sprache versehen.<\/p>\n Die zweite Variante für das Erstellen von Menüs ist VBA: Manch ein Entwickler erstellt alle Menüs beim Start der Anwendung oder auch zur Laufzeit. In diesem Fall könnte man die jeweiligen Übersetzungen direkt beim Erstellen der Menüs zuweisen. Allerdings braucht man hier eine weitere Routine, welche beim Wechsel der Spracheinstellungen zur Laufzeit auch die Menüs anpasst – am einfachsten ist es dann wohl, die Menüs komplett neu zu erstellen und mit den entsprechenden Texten zu versehen.<\/p>\n <\/p>\n Menütexte einlesen<\/b><\/p>\n Wir gehen im Folgenden davon aus, dass die Menüs, die mit einer Mehrsprachigkeitsfunktion ausgestattet werden sollen, bereits vorhanden sind, also entweder per Anpassen<\/b>-Dialog oder per VBA erzeugt wurden.<\/p>\n Unser Beispielmenü sieht wie in Bild 2 aus und enthält ein paar verschachtelte Elemente. Nach dem ändern der Sprache sollen alle Elemente mit neuen Texten ausgestattet sein, wie Bild 3 zeigt.<\/p>\n Bild 2: Menüs unter Access 2003 und früher mit deutschen …<\/span><\/b><\/p>\n Bild 3: … und mit anderssprachigen Texten<\/span><\/b><\/p>\n Die Vorgehensweise ist prinzipiell genau so wie bei Formularen, Berichten und Steuerelementen. Die Routine TexteEinlesenMenues <\/b>erwartet genau wie TexteEinlesen <\/b>die ID <\/b>der Sprache aus der Tabelle tblSprachen<\/b>, in der die aktuellen Steuerelemente beschriftet sind.<\/p>\n Sie schreibt für jedes Steuerelement einen Eintrag in die Tabelle tblElemente<\/b> (siehe Bild 4), wobei das Feld Objekt <\/b>den Namen des Menüs und Objektart <\/b>den Wert Menu <\/b>erhält.<\/p>\n Bild 4: Die Tabelle tblElemente speichert auch Informationen zu Menü-Elementen.<\/span><\/b><\/p>\n Für das Feld Steuerelement <\/b>wird allerdings nicht wie bei den Steuerelementen von Formularen und Berichten der Steuerelementname eingetragen, sondern ein eindeutiger Zahlenwert – die Elemente benutzerdefinierter Menüs besitzen nämlich normalerweise kein eindeutiges Merkmal.<\/p>\n Daher schreibt die Routine TexteEinlesenMenues <\/b>die eindeutige Nummer, die auch im Feld BegriffID <\/b>der Tabelle tblElemente <\/b>landet, auch noch in die Eigenschaft Tag <\/b>des jeweiligen Menüelements.<\/p>\n Der Hintergrund ist, dass die später vorgestellte Routine MenuespracheEinstellen <\/b>eine Möglichkeit braucht, um jedes der Menüelemente eindeutig zu identifizieren, um die richtige Beschriftung in der jeweiligen Sprache hinzuzufügen.<\/p>\n Nachdem für ein Menüelement ein Datensatz in der Tabelle tblElemente <\/b>angelegt wurde, kommen je nach Anzahl der in der Tabelle tblSprachen <\/b>festgelegten Sprachen entsprechende Einträge zur Tabelle tblUebersetzungen <\/b>hinzu – auch das kennen Sie bereits von der Routine TexteEinlesen <\/b>aus dem ersten Teil dieser Beitragsreihe.<\/p>\n Einen großen Unterschied gibt es dennoch zwischen dem Einlesen der Beschriftungen von Steuerelementen in Formularen und Berichten und in Menüs: Menüs können hierarchisch verschachtelte Elemente enthalten, weshalb die Routine TexteEinlesenMenues <\/b>eine weitere Prozedur namens TexteEinlesenMenuesRek <\/b>aufruft, die sich im weiteren Verlauf entsprechend der Menütiefe rekursiv selbst aufrufen kann und die Elemente der verschiedenen Ebenen in den Tabellen tblElemente <\/b>und tblUebersetzungen <\/b>verewigt.<\/p>\n Da die Routinen TexteEinlesenMenues<\/b>, TexteEinlesenMenuesRek <\/b>und MenuespracheEinstellen <\/b>sehr ähnlich wie die bereits im ersten Teil dieser Beitragsreihe vorgestellten Routinen aufgebaut sind, verzichten wir an dieser Stelle auf ihren Abdruck und verweisen auf das Modul mdlMehrsprachigkeit <\/b>der Beispieldatenbank.<\/p>\n Andere Sprache im Menü anwenden<\/b><\/p>\n Wer nun denkt, das Anwenden einer anderen Sprache auf die Menüs einer Datenbank sei ebenso kompliziert und funktioniere ebenfalls nur mit Rekursion, irrt: Immerhin haben wir gute Vorarbeit geleistet und jedem Steuerelement der eingelesenen Menüs eine ID <\/b>in die Eigenschaft Tag <\/b>geschrieben, aufgrund derer wir einfach nur noch die Datensätze der Tabelle tblElemente <\/b>durchlaufen und die Menüelemente mit dem passenden Tag heraussuchen müssen. Und dabei hilft sogar noch die nützliche Funktion FindControl <\/b>des CommandBar<\/b>-Objekts.<\/p>\n Der Rest ist Formsache: Die Routine schreibt die in der Tabelle tblUebersetzungen<\/b> gespeicherten Texte für die mit lngSpracheID<\/b> angegebene Sprache in die Caption<\/b>-Eigenschaft der betroffenen Menüelemente und sorgt so für eine einfache automatisierte Mehrsprachigkeit von Menüs.<\/p>\n Ribbons<\/p>\n Bei den Ribbons unter Access 2007 sieht die Sache wiederum ganz anders aus: Sie basieren auf einer XML-Definition, die variable Elemente in Form sogenannter Callback-Funktionen enthalten kann, die erst vor dem Anzeigen des jeweiligen Ribbons aufgerufen werden. <\/p>\n Jedes Steuerelement kann verschiedene Callback-Funktionen haben, von denen jede einen bestimmten Wert liefert – eine liefert die zur Laufzeit anzuzeigende Beschriftung, eine andere den Hilfetext und so weiter.<\/p>\n Die Grundlagen für die Verwendung von Callback-Funktionen zur dynamischen Gestaltung von Ribbons erhalten Sie in einem anderen Beitrag namens Ribbons dynamisch gestalten <\/b>(Shortlink 657).<\/p>\n Leider reicht der Platz an dieser Stelle nicht aus, um Begriffe wie Callback-Funktionen ausreichend genau zu erläutern; wenn Sie also noch keine Grundkenntnisse über Ribbons besitzen, kommen Sie einfach später zu diesem Abschnitt zurück und lesen nun ab der folgenden Zwischenüberschrift weiter.<\/p>\n Die theoretische Vorgehensweise erläutern wir an dieser Stelle in verkürzter Form: Wenn Sie einem Ribbon einen Beschriftungstext dynamisch, also über eine Callback-Funktion zuweisen möchten, können Sie keinen statischen Text etwa in einem XML-Attribut zuweisen – beides gleichzeitig ist nicht zulässig.<\/p>\n Sie können also nicht wie bei Formularen, Berichten, Steuerelementen oder Menüs einen bestehenden Beschriftungstext als Grundlage verwenden und diesen mit den Texten in anderen Sprachen in die Tabellen tblElemente <\/b>und tblUebersetzungen <\/b>schreiben, um diese anschließend entsprechend abzurufen.<\/p>\n Die Situation gestaltet sich also genau so wie bei den Meldungsfenstern: Sie müssen der Callback-Funktion eine Anweisung hinzufügen, die aufgrund einer ID<\/b>, die durchaus dem Attribut id <\/b>des aktuellen Ribbon-Elements entsprechen kann, und der Sprach-ID für die gewünschte Sprache die Übersetzung aus einer Tabelle wie tblUebersetzungen <\/b>liefert.<\/p>\n Sonstige Elemente<\/b><\/p>\n Weitere Elemente, um die man sich kümmern muss, sind etwa die in der Statusleiste angezeigten Texte. Diese erhalten Sie auf die gleiche Weise wie etwa die Texte für die Anzeige in Meldungsfenstern über die Funktion HoleUebersetzung<\/b>(). <\/p>\n Platzbedarf von Texten<\/b><\/p>\n Wer nur für eine Landessprache entwickelt, braucht sich keine Gedanken um den Platzbedarf verschiedener Übersetzungen von Texten zu machen – er braucht beispielsweise die Bezeichnungsfelder nur so breit zu formatieren, wie es der aktuelle Text erfordert.<\/p>\n Bei mehrsprachigen Anwendungen kann dies schiefgehen, weil ein Ausdruck in einer anderen Sprache nicht nur kürzer, sondern auch länger sein kann. Also müssen Sie alle Varianten durchtesten und visuell prüfen, ob auch alle Texte angezeigt werden … oder doch nicht<\/p>\n Nein, denn die versteckte und undokumentierte Klasse Wizhook<\/b> der Access-Bibliothek hält eine Methode namens TwipsFromFont <\/b>bereit, mit der Sie die Abmessungen von Texten in der angegebenen Schriftart und unter anderen Parametern ermitteln können. Das hilft insofern weiter, als dass Sie per Code prüfen können, welche sprachabhängigen Ausdrücke in ein Bezeichnungsfeld passen und welche nicht. Abgesehen von der Einschränkung, dass keine Bezeichnungsfelder mit mehrzeiligen Texten berücksichtigt werden können (die Funktion TwipsFromFont<\/b> wertet immer die Gesamtlänge aus, auch wenn der Text Zeilenumbrüche enthält), können Sie hiermit schnell zu schmale Bezeichnungsfelder ermitteln.<\/p>\n Die Routine BezeichnungsfelderPruefen <\/b>(Listing 1) nimmt Ihnen viel manuelle Arbeit ab. Sie durchläuft alle Formulare und Berichte, die in der Tabelle tblUebersetzungen <\/b>aufgeführt werden, öffnet diese in Abhängigkeit von ihrem Typ, durchläuft alle in der Tabelle tblUebersetzungen <\/b>angegebenen Übersetzungen für die Eigenschaft Caption <\/b>der Steuerelemente des Typs 100 <\/b>(Bezeichnungsfeld) und liest sowohl die Breite der Texte für die verschiedenen Sprachen als auch die Breite des jeweiligen Steuerelements aus. Wenn der Text breiter als das Steuerelement ist, schreibt die Routine die Differenz in Twips in das Feld Ueberlaenge <\/b>des aktuellen Datensatzes der Tabelle tblUebersetzungen<\/b> (siehe Bild 5).<\/p>\n Listing 1: Diese Routine vergleicht die Breite von Bezeichnungsfeldern und die möglichen Inhalte und schreibt einen entsprechenden Eintrag in die Tabelle tblUebersetzungen, wenn ein Eintrag nicht passt.<\/p>\n Bild 5: Zu lange Texte für Bezeichnungsfelder werden durch einen entsprechenden Zahlenwert im Feld Ueberlaenge der Tabelle tblUebersetzungen markiert.<\/span><\/b><\/p>\n Die Routine BezeichnungsfelderPruefen <\/b>verwendet eine Hilfsfunktion namens Textabmessungen<\/b>, welche die Wizhook<\/b>-Methode TwipsFromFont <\/b>verwendet, um die Breite des zu prüfenden Textes zu ermitteln. Diese Routine finden Sie genau wie BezeichnungsfelderPruefen <\/b>im Modul mdlMehrsprachigkeit <\/b>der Beispieldatenbank.<\/p>\n Entwicklungsumgebung<\/b><\/p>\n Wer normalerweise nur Datenbankanwendungen für deutschsprachige Kunden entwickelt, wird üblicherweise auch mit einer deutschen Version von Access arbeiten. Wenn eine Anwendung auch auf anderssprachigen Systemen funktionieren soll, ist es allerdings sinnvoll, mit einer englischen Version von Access zu arbeiten. Es gibt nämlich einige feine Unterschiede, die auf diese Weise nicht ins Gewicht fallen:<\/p>\n Anpassungen<\/b><\/p>\n Die Beispieldatenbank weist gegenüber der aus dem ersten Teil dieser Beitragsreihe eine kleine änderung auf. Diese betrifft die Tabelle tblElemente<\/b>, der wir ein zusätzliches Feld namens Objektart <\/b>hinzugefügt haben, das entweder den Text Form <\/b>oder Report <\/b>enthält. Dementsprechend hat auch der Code der Routine TexteEinlesen <\/b>und der dadurch aufgerufenen Funktionen kleinere änderungen erfahren. Die Tabelle tblUebersetzungen <\/b>hat zwei neue Felder namens Ueberlaenge <\/b>und Ueberhoehe <\/b>erhalten, die gefüllt werden, wenn das Zielsteuerelement ein Bezeichnungsfeld ist und der Text in einer bestimmten Sprache nicht in das Bezeichnungsfeld hineinpasst.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Nach der Vorgehensweise bei der mehrsprachigen Gestaltung von Formularen, Berichten und den enthaltenen Steuerelementen im Beitrag Mehrsprachige Anwendungen<\/b> (Shortlink 611) haben Sie in diesem Teil der Beitragsreihe erfahren, wie Sie Meldungsfenster, Menüs, Ribbons und weitere Elemente, deren Beschriftung mit VBA angepasst wird, mit mehrsprachigen Texten ausstatten.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Mehrsprachigkeit2.mdb<\/p>\nPrivate Sub Form_Load()\r\n SpracheEinstellen Me, cSprache\r\n End Sub<\/pre>\n
MsgBox HoleUebersetzungµ\r\n("Meldungsfenstertext"), ..., µ\r\nHoleUebersetzungµ\r\n("Meldungsfenstertitel")<\/pre>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2009_02\/MehrsprachigeDatenbanken-web-images\/pic002_opt.jpeg\")
<\/p>\nPublic Function HoleUebersetzung(lngBegriffID _\r\n As Long) As String\r\n HoleUebersetzung = DLookup("Begriff", _\r\n "tblUebersetzungen", "BegriffID = " _\r\n & lngBegriffID & " AND SpracheID = " _\r\n & cSprache)\r\nEnd Function<\/pre>\nMsgBox HoleUebersetzung(-1), vbOkOnly,\r\nHoleUebersetzung(-2)<\/pre>\n
![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2009_02\/MehrsprachigeDatenbanken-web-images\/pic003_opt.jpeg\")
<\/p>\n![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2009_02\/MehrsprachigeDatenbanken-web-images\/pic004_opt.jpeg\")
<\/p>\n![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2009_02\/MehrsprachigeDatenbanken-web-images\/pic005_opt.jpeg\")
<\/p>\nPublic Sub BezeichnungsfelderPruefen()\r\nDim db As DAO.Database\r\nDim rstObjekte As DAO.Recordset\r\nDim rstLabel As DAO.Recordset\r\nDim rstUebersetzungen As DAO.Recordset\r\nDim strObjektname As String\r\nDim strObjektart As String\r\nDim lngHoeheText As Long\r\nDim lngBreiteText As Long\r\nDim obj As Object\r\nSet db = CurrentDb\r\ndb.Execute "UPDATE tblUebersetzungen SET Ueberlaenge = 0, Ueberhoehe = 0", dbFailOnError\r\nSet rstObjekte = db.OpenRecordset("SELECT DISTINCT Objekt, Objektart FROM tblElemente", dbOpenDynaset)\r\nDo While Not rstObjekte.EOF\r\n strObjektname = rstObjekte!Objekt\r\n strObjektart = rstObjekte!Objektart\r\n If Not Left(strObjektname, 1) = "_" Then\r\n If strObjektart = "Form" Then\r\n DoCmd.OpenForm strObjektname, acPreview\r\n Set obj = Forms(strObjektname)\r\n Else\r\n DoCmd.OpenReport strObjektname, acViewPreview\r\n Set obj = Reports(strObjektname)\r\n End If\r\n Set rstLabel = db.OpenRecordset("SELECT DISTINCT Steuerelement, BegriffID FROM tblElemente " _\r\n & "WHERE Objekt = '" & strObjektname & "' AND Objektart = '" & strObjektart _\r\n & "' AND Steuerelementtyp = 100 AND Eigenschaft = 'Caption'", dbOpenDynaset)\r\n Do While Not rstLabel.EOF\r\n Set rstUebersetzungen = db.OpenRecordset("SELECT Begriff, SpracheID, Ueberlaenge, Ueberhoehe " _\r\n & "FROM tblUebersetzungen WHERE BegriffID = " & rstLabel!BegriffID, dbOpenDynaset)\r\n Do While Not rstUebersetzungen.EOF\r\n Textabmessungen rstUebersetzungen!Begriff, obj.Controls(rstLabel!Steuerelement), _\r\n lngHoeheText, lngBreiteText\r\n If lngBreiteText > obj.Controls(rstLabel!Steuerelement).Width Then\r\n rstUebersetzungen.Edit\r\n rstUebersetzungen!Ueberlaenge = lngBreiteText - obj.Controls(rstLabel!Steuerelement).Width\r\n rstUebersetzungen.Update\r\n End If\r\n If lngHoeheText > obj.Controls(rstLabel!Steuerelement).Height Then\r\n rstUebersetzungen.Edit\r\n rstUebersetzungen!Ueberhoehe = lngHoeheText - obj.Controls(rstLabel!Steuerelement).Height\r\n rstUebersetzungen.Update\r\n End If\r\n rstUebersetzungen.MoveNext\r\n Loop\r\n rstLabel.MoveNext\r\n Loop\r\n End If\r\n If strObjektart = "Form" Then\r\n DoCmd.Close acForm, strObjektname\r\n Else\r\n DoCmd.Close acReport, strObjektname\r\n End If\r\n rstObjekte.MoveNext\r\nLoop\r\nEnd Sub<\/pre>\n![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2009_02\/MehrsprachigeDatenbanken-web-images\/pic001_opt.jpeg\")
<\/p>\n\n
Downloads zu diesem Beitrag<\/h3>\n