<\/p>\n
Access ist bekannt dafür, dass man Daten schnell in gewünschter Weise zur Bearbeitung in Formularen anzeigen kann – zumindest für übliche Szenarien. Entwickler schätzen Access aber auch deshalb, weil sich auch außergewöhnliche Anforderungen damit realisieren lassen. In diesem Beitrag geht es um die Synchronisierung zweier Unterformulare.<\/b><\/p>\n
Die Anforderung für diesen Beitrag stammt aus einem anderen Beitrag, nämlich Mehrsprachige Anwendungen <\/b>(Shortlink 611). Dort sollen Benutzer in einem Formular verschiedene Übersetzungen der Beschriftungen von Steuerelementen eintragen, um die Anwendung mehrsprachig zu machen.<\/p>\n
Die Daten stammen aus einer einzigen Tabelle, die unter anderem die ID der Sprache und des Textes sowie die verschiedenen Übersetzungen beinhaltet. Wie immer unter Access gibt es verschiedene Ansätze, um den Originaltext und dessen Übersetzung so anzuzeigen, dass der Benutzer diese möglichst komfortabel editieren kann. So könnte man etwa die Originaltexte in einem Listenfeld anzeigen, aus dem der Benutzer den Text auswählt, den er übersetzen möchte, und diesen Text in einem Textfeld zur Bearbeitung bereitstellen. Diese Lösung programmiert ein durchschnittlich begabter Access-Programmierer wohl in maximal einer halben Stunde.<\/p>\n
Manchmal juckt dem Entwickler aber das Fell und er wählt einen Weg, der auf den ersten Blick nicht viel aufwendiger erscheint, aber erheblich ergonomischer wirkt. Dabei soll auf der linken Seite des Formulars ein Unterformular in der Datenblattansicht die Originaltexte und ein weiteres auf der rechten Seite die Übersetzungen in der jeweils ausgewählten Sprache anzeigen.<\/p>\n
Das ist gegenüber dem ersten Ansatz sicher ergonomischer, weil der Benutzer nicht für jede neue Übersetzung erst den Originaltext markieren muss, um den zu übersetzenden Text angezeigt zu bekommen. Stattdessen sieht er links eine Reihe Originaltexte und rechts die Übersetzungen, wobei er die Übersetzungen einfach von oben nach unten oder auch willkürlich abarbeiten kann. So weit, so gut: Zwei Unterformulare in einem Formular anzulegen, die jeweils andere Daten der gleichen Tabelle anzeigen (je einmal für jede Sprache), stellt keine echte Herausforderung dar. Dafür brauchen Sie sogar nur ein einziges Formular, das Sie zweimal als Unterformular in ein Hauptformular integrieren.<\/p>\n
Unpraktisch ist nur, dass man irgendwann alle aktuell angezeigten Texte übersetzt hat und die bis dahin nicht sichtbaren Texte nach oben scrollen muss – und das immer gleichzeitig für zwei Unterformulare, damit die entsprechenden Texte auch nebeneinanderliegen. Hier setzt die Lösung dieses Beitrags an: Sie zeigt, wie Sie die beiden Unterformulare synchron scrollen, egal, ob dies mit der Tastatur, dem Mausrad oder mit den Bildlaufleisten geschieht.<\/p>\n
Versuchsaufbau<\/b><\/p>\n
Als Grundlage dient eine Beispieltabelle namens tblBeispiele <\/b>mit den zwei Feldern BeispielID <\/b>und Beispiel<\/b>. Ein Hauptformular namens frmHauptformular <\/b>besitzt nur zwei Unterformularsteuerelemente sfm1 <\/b>und sfm2<\/b>, die jeweils das Unterformular sfmUnterformular <\/b>enthalten (siehe Bild 1).<\/p>\n
![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2008_02\/SynchroneUnterformulare-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Hauptformular mit zwei synchronisierten Unterformularen<\/span><\/b><\/p>\n Dieses Unterformular statten Sie mit der Tabelle tblBeispiele <\/b>als Datenherkunft aus, wobei es beide Felder dieser Tabelle in der Datenblattansicht anzeigen soll (zur Vereinfachung sollen links und rechts jeweils die gleichen Datensätze ein und derselben Tabelle angezeigt werden).<\/p>\n Das Unterformular ziehen Sie einfach zweimal vom Datenbankfenster in das im Entwurf geöffnete Hauptformular und nennen dann das erste Unterformularsteuerelement sfm1<\/b> und das zweite sfm2<\/b>. Achtung, es gibt einen Unterschied zwischen Unterformularsteuerelement und dem darin enthaltenen Formular! Selbstverständlich müssen die Unterformularsteuerelemente verschiedene Namen haben, können aber das gleiche Unterformular enthalten (nachzuprüfen in der Eigenschaft Herkunftsobjekt <\/b>auf der Registerseite Daten <\/b>der Steuerelementeigenschaften).<\/p>\n Gegenseitige Abhängigkeit<\/b><\/p>\n Die besondere Würze dieses Beispiels ist die Verwendung des gleichen Formulars in beiden Unterformularsteuerelementen. Mal ganz ohne den zugehörigen Code zu beschreiben soll ja bereits beim Wechseln des Datensatzes Folgendes passieren: Unterformular 1 wechselt vom untersten Datensatz zum nächsten Datensatz, der ja gleichzeitig der erste nicht mehr sichtbare Datensatz ist. In diesem Fall soll das Gleiche in Unterformular 2 geschehen – die Datensätze sollen um eine Position nach oben verschoben werden. Dazu sind verschiedene Aktionen notwendig, die unter anderem das Beim Anzeigen<\/b>-Ereignis von Formular 2 auslösen. Auch das Scrollen von Formular 1 kann prinzipiell (außer per Timer) nur durch das Beim Anzeigen<\/b>-Ereignis abgefangen werden. Wenn man nun nicht prüft, ob das Beim Anzeigen<\/b>-Ereignis nicht gerade durch das Scrollen des anderen Formulars ausgelöst wurde, und ein endloses, wechselseitiges Aufrufen vermeiden möchte, muss man dies abfangen.<\/p>\n Wenn nun das erste Unterformular dem zweiten auf irgendeine Weise mitteilen möchte, dass es gerade durch einen Scrollvorgang einen Datensatzwechsel ausgelöst hat, muss das erste Unterformular ja erstmal wissen, dass es überhaupt das erste Unterformular ist – immerhin unterscheiden sich die beiden Unterformulare ja nur dadurch, dass das erste in einem Unterformularsteuerelement etwa namens sfm1 <\/b>und das zweite in einem anderen namens sfm2 <\/b>untergebracht ist. Dummerweise kann man aber nicht durch einen Verweis wie Me.Parent <\/b>auf das Unterformularsteuerelement zugreifen, in dem ein Unterformular steckt, sondern erhält mit Me.Parent <\/b>direkt einen Verweis auf das Formular, in dem sich das Unterformular befindet.<\/p>\n <\/p>\n Selbstidentifikation<\/b><\/p>\n Will ein Unterformular nun erfahren, ob es das erste oder zweite Unterformular ist, benötigt es eine kleine Hilfsfunktion:<\/p>\n Diese durchläuft alle Steuerelemente des übergeordneten Formulars und prüft zunächst, ob es sich dabei um ein Unterformularsteuerelement handelt. Falls ja, zieht es die Eigenschaft hWnd <\/b>heran, um zu ermitteln, ob es selbst oder ein anderes Unterformular in diesem Unterformular steckt. hWnd <\/b>liefert ein eindeutiges Fenster-Handle beispielsweise für Formulare. GetMe <\/b>liefert schließlich den Namen des Unterformularsteuerelements zurück, in dem sich das Unterformular befindet. <\/p>\n Eine zweite Funktion namens GetYou<\/b> sieht ähnlich aus, liefert aber den Namen des ersten Unterformularsteuerelements, das nicht dem Unterformularsteuerelement entspricht, in dem das aufrufende Unterformular steckt:<\/p>\n Diese beiden Funktionen arbeiten nicht wie erwartet, wenn das Hauptformular mehr als die zwei betroffenen Unterformulare enthält. In diesem Fall müssten Sie noch eine weitere Prüfung etwa des Namens der Unterformularsteuerelemente hinzufügen.<\/p>\n Scrollen mit Cursor-, Tab- und Eingabetaste<\/p>\n Die Navigation in den Datensätzen ist durch verschiedene Tasten möglich. Das Abfragen der entsprechenden Tastenanschläge ist nicht notwendig, da ein ändern der Position ohnehin nur beim Wechseln des Datensatzes erfolgt, den Sie mit dem Ereignis Beim Anzeigen <\/b>des Unterformulars abfangen können. Listing 1 zeigt den Code, den das Unterformular enthalten muss, damit es beim Wechseln des Datensatzes und damit verbundener Scroll-Vorgänge ein Mitscrollen des jeweils anderen Unterformulars bewirkt.<\/p>\n Listing 1: Die Ereignisprozedur, die beim Anzeigen eines Datensatzes und somit bei jedem Datensatzwechsel ausgelöst wird, sorgt für das gegenseitige Aktualisieren der Scrollposition der Unterformulare.<\/p>\n Unterformular vor Hauptformular<\/b><\/p>\n Diese Routine berücksichtigt den Umstand, dass Access beim Öffnen eines Hauptformulars mit Unterformular(en) zunächst die Unterformulare, und dann das Hauptformular öffnet und somit auch die entsprechenden Ereignisse wie Beim Laden<\/b>, Beim Öffnen <\/b>oder Beim Anzeigen <\/b>in der entsprechenden Reihenfolge aufruft.<\/p>\n Das Abrufen des Unterformularsteuerelements eines der Unterformulare könnte daher zu früh kommen, also bevor das Hauptformular und damit das Unterformularsteuerelement überhaupt geladen ist. Deshalb bestücken Sie die Ereignisprozedur aus Listing 1, die direkt nach dem Öffnen der Unterformulare und dann bei jedem Datensatzwechsel ausgelöst wird, mit einer On Error Resume Next<\/b>-Anweisung: eventuelle Zugriffe auf noch nicht bereite Steuerelemente lösen dann keinen Fehler aus.<\/p>\n Die Routine aus Listing 1 macht Folgendes: Sie prüft zunächst, ob beide Formulare aktuell den gleichen Datensatz als ersten im sichtbaren Bereich anzeigen. Falls ja, geht es weiter: Die Routine prüft eine Eigenschaft des Hauptformulars namens strActiveForm <\/b>daraufhin, ob sie den Namen des anderen Unterformulars enthält. Dies ist die Absicherung, um das abwechselnde Auslösen der Form_Current<\/b>-Prozedur zu verhindern. Diese Eigenschaft wird im Hauptformular so deklariert:<\/p>\n Damit sie jeweils den aktuellen Wert enthält, erfolgt die Zuweisung im Ereignis Beim Hingehen<\/b> des jeweiligen Unterformularsteuerelements:<\/p>\n Ist das andere Unterformular das aktive Unterformular, wurde Form_Current <\/b>dieses Formulars durch das Anpassen vom anderen Formular aus ausgelöst. In dem Fall bricht die Routine ab.<\/p>\n Anderenfalls erfolgt der Aufruf von Form_Current <\/b>durch ein aktives Verschieben des Datensatzzeigers im aktuellen Unterformular. Dann deaktiviert die Routine zunächst die grafische Aktualisierung des anderen Unterformulars, um mögliches Flackern zu unterdrücken, verschiebt den Fokus auf den letzten, dann auf den zuoberst angezeigten und schließlich auf den aktuellen Datensatz. Nach dem Setzen von Painting <\/b>auf True <\/b>und damit der Aktivierung der Formularaktualisierung steht das andere Formular nicht nur auf dem gleichen Datensatz wie dieses Unterformular, sondern zeigt auch noch die Datensätze auf der gleichen Höhe an.<\/p>\n Verschieben durch den Scrollbalken<\/b><\/p>\n Etwas aufwendiger, aber nur, was den Codeumfang angeht, ist das Tracken der Position des Scrollbalkens und das dadurch notwendige Synchronisieren der Unterformulare.<\/p>\n Die wichtigste Information ist, dass es kein Ereignis gibt, das durch ändern der Position der Bildlaufleiste ausgelöst wird. Das heißt, dass man dessen Position regelmäßig abfragen muss, was in einer durch das Bei Zeitgeber<\/b>-Ereignis ausgelösten Routine geschieht. Damit dies regelmäßig passiert, stellt man die Eigenschaft Zeitgeberintervall <\/b>auf einen passenden Wert ein. Je kleiner der Wert, desto zügiger passt sich das jeweils andere Unterformular an das aktuelle Unterformular an – allerdings kostet dies natürlich auch Performance. Eine Abfrage alle 1\/40-Sekunde reichte in Tests aus, was einem Wert von 25 <\/b>für die Eigenschaft Zeitgeberintervall <\/b>entspricht.<\/p>\n Nun könnte man sich viel Arbeit machen und per API nicht nur die Position der Bildlaufleiste in einem Unterformular abfragen, sondern auch noch die Position der Bildlaufleiste des anderen Unterformulars per API synchronisieren.<\/p>\n Das wäre aber übertrieben, denn alle notwendigen Zeilen zum Synchronisieren der Anzeige der beiden Unterformulare haben wir ja schon zusammen. Also reicht es aus, zu prüfen, wann der Benutzer die Bildlaufleiste eines der Unterformulare benutzt, und anschließend die Unterformulare zu synchronisieren. Dazu speichert man einfach jeweils die aktuelle Position in einer Variablen zwischen und vergleicht diese beim nächsten Aufruf der Timer<\/b>-Ereignisprozedur mit dem Wert für die aktuelle Position (s. Listing 2).<\/p>\n Listing 2: Auch beim Scrollen mit der Bildlaufleiste sollen die beiden Unterformulare synchronisiert werden, was diese durch das Bei Zeitgeber-Ereignis ausgelöste Routine erledigt.<\/p>\n Die notwendige API-Funktion heißt GetScrollInfo<\/b>. Wie in vielen Fällen kann man auch diese API-Funktion nicht ohne Weiteres nutzen, um sich etwa eine einzige Information zurückgeben zu lassen. Also verwendet man eine Wrapper-Funktion, die noch einige weitere API-Funktionen hinzuzieht, um beispielsweise herauszufinden, ob der Benutzer auch wirklich auf die Bildlaufleiste und nicht etwa auf ein anderes Steuerelement geklickt hat, und lässt sich von dieser den gesuchten Wert zurückgeben. Die gesamte hierzu benötigte Funktionalität steckt im Standardmodul mdlScrollbar<\/b>, der enthaltene Code ist einem Beispiel von Stephen Lebans entnommen (http:\/\/www.lebans.com\/setgetsb.htm<\/b>) und für dieses Beispiel angepasst worden – so funktioniert der Originalcode etwa nicht mehr mit neueren Access-Versionen, weil die Bildlaufleisten nun einen anderen Fenstertitel als früher tragen.<\/p>\n Der Code der Ereignisprozedur Form_Timer <\/b>enthält wider Erwarten im Inneren nicht genau die gleichen Codezeilen wie die Prozedur, die durch das Beim Anzeigen<\/b>-Ereignis des Unterformulars ausgelöst wird.<\/p>\n Der Grund ist, dass man mit der Tastatur nur bis zum letzten Datensatz navigieren kann, den das Unterformular dann auch so weit wie möglich unten anzeigt. Mit dem Scrollbalken kommt man aber weiter runter – nämlich so weit, dass das Unterformular nur noch einen neuen, leeren Datensatz anzeigt (siehe Bild 2).<\/p>\nPrivate Function GetMe() As String\r\n Dim ctl As Control\r\n For Each ctl In Parent.Controls\r\n If ctl.ControlType = acSubform Then\r\n If ctl.Form.hWnd = Me.hWnd Then\r\n GetMe = ctl.Name\r\n Exit For\r\n End If\r\n End If\r\n Next ctl\r\nEnd Function<\/pre>\n
Private Function GetYou() As String\r\n Dim ctl As Control\r\n For Each ctl In Parent.Controls\r\n If ctl.ControlType = acSubform Then\r\n If ctl.Form.Name = Me.Name And _\r\n ctl.Form.hWnd <> Me.hWnd Then\r\n GetYou = ctl.Name\r\n Exit For\r\n End If\r\n End If\r\nNext ctl\r\nEnd Function<\/pre>\n
Private Sub Form_Current()\r\n On Error Resume Next\r\n If Not (Me.SelTop = Me.Parent(GetYou).Form.SelTop) Then\r\n If Me.Parent.strActiveForm = GetYou Then\r\n Exit Sub\r\n Else\r\n With Me.Parent(GetYou).Form\r\n .Painting = False\r\n .SelTop = .Recordset.RecordCount\r\n .SelTop = Me.SelTop - Me.CurrentSectionTop \/ intHeight + 1\r\n .SelTop = Me.SelTop\r\n .Painting = True\r\n End With\r\n End If\r\n End If\r\n End Sub<\/pre>\n
Public strActiveForm As String<\/pre>\n
Private Sub sfm1_Enter()\r\nstrActiveForm = "sfm1"\r\nstrActiveForm1 = "sfm1"\r\nEnd Sub\r\nPrivate Sub sfm2_Enter()\r\nstrActiveForm = "sfm2"\r\nstrActiveForm1 = "sfm2"\r\nEnd Sub<\/pre>\n
Private Sub Form_Timer()\r\n Dim intHeightForm As Integer\r\n intpos = fGetScrollBarPos(Me)\r\n If Not intpos = intposalt Then\r\n If Me.Parent.strActiveForm1 = GetYou Then\r\n Exit Sub\r\n Else\r\n With Me.Parent(GetYou).Form\r\n .Painting = False\r\n intHeightForm = Me.Parent(GetYou).Height\r\n Me.Parent(GetYou).Height = 0\r\n .SelTop = intpos - 1\r\n Me.Parent(GetYou).Height = intHeightForm\r\n .Painting = True\r\n End With\r\n End If\r\n End If\r\n intposalt = intpos\r\n End Sub<\/pre>\n
![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2008_02\/SynchroneUnterformulare-web-images\/pic002_opt.jpeg\")
<\/p>\n