Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 2/2005.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Access-FAQ: Rund um Formulare

Karl Donaubauer, Wien

In der Access-FAQ von Karl Donaubauer (www.donkarl.com) finden Sie die meistgestellten Fragen und Anworten zum Thema Microsoft Access. In dieser Beitragsreihe stellt Karl Donaubauer die wichtigsten Einträge im Detail vor und zeigt Ihnen entsprechende Lösungen anhand praxisnaher Beispiele. Im siebten Teil lernen Sie die Lösungen zu den meistgenannten Problemen der Teilnehmer der deutschsprachigen Access-Newsgroups im Zusammenhang mit Formularen und Unterformularen kennen.

Prüfen, ob ein Formular
geöffnet ist

In vielen Situationen ist es notwendig zu wissen, ob ein bestimmtes Formular geöffnet ist, zum Beispiel damit ein Requery-Befehl oder ein anderer Bezug auf das Formular nicht zu einem Fehler führen kann. Es gibt etliche Methoden, um den Zustand eines Formulars zu prüfen. Eine ist das Durchlaufen der Forms-Auflistung, in der ja immer nur alle aktuell geöffneten Formulare stehen:

Dim frm As Form

For Each frm In Application.Forms

    If frm.Name = "FormularName" Then

        'Aktionen durchführen

    End If

Next frm

Der einzige kleine Nachteil dieser Methode, die in allen Access-Versionen funktioniert, ist eine in der Praxis kaum jemals merkbare Verzögerung, weil alle geöffneten Formulare durchlaufen werden müssen.

Eine andere Variante ist die Verwendung der Funktion SysCmd, die bis Access 2.0 noch undokumentiert war und seit Access 95 offiziell zur Verfügung steht. Am besten verwenden Sie dazu die folgende kleine Funktion in einem Standardmodul:

Public Function fctIsFormOpen( _
    StrFrmName As String) As Boolean

    fctIsFormOpen =
        (SysCmd(acSysCmdGetObjectState, _
        acForm, StrFrmName) > 0)

End Function

Hinweis

Auf der Begleit-CD finden Sie Beispiel-Datenbanken im Format von Access 97 und Access 2000 mit den Quellcodes und Beispielen aus diesem Artikel. (

Die Funktion liefert True oder False zurück, je nachdem, ob das Formular geöffnet ist oder nicht. Der typische Aufruf dieser Funktion sieht dann so aus:

If fctIsFormOpen("NameDesFormulares") Then ...

Ab Access 2000 hat Microsoft endlich eine Möglichkeit zur Prüfung in die Access-Bibliothek eingebaut. Es handelt sich um die Eigenschaft IsLoaded. Damit können Sie für alle Access-Objekte, also auch für Tabellen, Abfragen und so weiter, prüfen, ob sie aktuell geöffnet sind. Für ein Formular sieht das so aus (in einer Zeile):

Abb. 1: Zwei Instanzen desselben Formulars

Dim myCopy As Form

Private Sub btnNeueInstanz_Click()

    Dim rs As DAO.Recordset

    Set myCopy = New Form_frmInstanzen

    Set rs = myCopy.RecordsetClone

    With myCopy

        .Visible = True

        .Caption = .Caption & " - Kopie"

        DoCmd.MoveSize 2000, 2000

        If Not IsNull(Me!cboAuswahl) Then

            rs.FindFirst "ArtikelId = " & Me!cboAuswahl

            If Not rs.NoMatch Then

              .Bookmark = rs.Bookmark

            End If

        End If

    End With

    Set rs = Nothing

End Sub

Quellcode 1

CurrentProject.AllForms("FormularName").
IsLoaded

Im Gegensatz zur oben angeführten Prüfung mit der selbst erstellten Funktion liefert die Eigenschaft IsLoaded drei mögliche Ergebnisse. True, wenn das Objekt geöffnet ist, False, wenn es nicht geöffnet ist, und als dritte Variante den Laufzeitfehler 2467, wenn ein nicht vorhandener Objektname verwendet wurde. Den Fehler können Sie natürlich abfangen, aber das bedeutet immerhin etwas Mehrarbeit.

Formular mehrfach anzeigen

Ab der Version 95 bietet Access die Möglichkeit, mehrere Instanzen desselben Formulars zu öffnen. Das typische Anwendungsbeispiel ist das Anzeigen mehrerer Datensätze neben- oder übereinander (s. Abb. 1).

In der Beispiel-Datenbank zu diesem Artikel finden Sie das Formular frmInstanzen, das den nötigen Code und die praktische Anwendung demonstriert (s. Quellcode 1).

Im Kombinationsfeld des Beispielformulars können Sie einen anderen Artikel auswählen, der dann beim Klicken der Befehlsschaltfläche in einer neuen Formularinstanz angezeigt wird.

Von "Instanzen" spricht man in diesem Zusammenhang schon deshalb, weil es sich um eine neue Instanz der Klasse des Formulars handelt. Das ist eine der vielen Gelegenheiten, bei denen man Access beziehungsweise VBA die Objektorientierung ansieht.

Die wesentlichen Teile des Codes sind dementsprechend objektorientiert. Zuerst erfolgt die Deklaration eines Formular-Objekts im Deklarationsbereich des Formular-Klassenmoduls mit

Declare Function GetSystemMetrics Lib "user32" (ByVal nIndex As Long) As Long

Const SM_CXSCREEN = 0

Const SM_CYSCREEN = 1

Public Function fctAufloesung()

    fctAufloesung = "Pixel horizontal: " & GetSystemMetrics(SM_CXSCREEN) _

        & "  vertikal: " & GetSystemMetrics(SM_CYSCREEN)

End Function

Quellcode 2

Dim myCopy As Form

Hier könnte man auch den Namen des speziellen Formulars verwenden, also

Dim myCopy As Form_frmInstanzen

Im Ereigniscode Beim Klicken der Schaltfläche wird dann die Klasse instanziiert mit

Set myCopy = New Form_frmInstanzen

Die neue Formularinstanz ist vorläufig noch nicht sichtbar. Das geschieht erst mit der Codezeile

.Visible = True

Der restliche Code sorgt dafür, dass die neue Instanz nicht genau über der ersten geöffnet wird und dass ein anderer Datensatz angezeigt wird, sofern im Kombinationsfeld einer ausgewählt wurde.

Wenn Sie in der neuen Instanz wieder auf die Schaltfläche klicken, wird die nächste Instanz erzeugt. Sie liegt jedoch genau über der aufrufenden. Deshalb müssen Sie das Fenster etwas verschieben, um den neuesten Klon zu sehen.

Formulare an
Bildschirmauflösung anpassen

Eine alte Schwäche von Access ist, dass sich seine Formulare nicht von selbst dynamisch an die Größe des Bildschirmes anpassen. Die meisten Entwickler gehen daher den Weg, eine Standardauflösung für ihre Anwendung vorzusehen, beziehungsweise beim Anwender vorzuschreiben. Dennoch geschieht es in der Praxis oft, dass ein Anwender mit einer anderen Auflösung arbeitet und dann die Formulare entweder zu groß oder zu klein erscheinen.

Möchten Sie Ihre Anwendung an verschiedene Auflösungen anpassen, so ist der erste Schritt das Ermitteln der aktuellen Bildschirmauflösung. Mithilfe der API-Funktion GetSystemMetrics ist das keine große Sache (s. Quellcode 2).

Die kleine Beispielfunktion fctAufloesung in Quellcode 2 zeigt auch gleich beispielhaft den Aufruf der API-Funktion. GetSystemMetrics
(SM_CXSCREEN) liefert die Breite des Bildschirmes in Pixeln, GetSystemMetrics(SM_CYSCREEN) liefert die Höhe.

Der schwierigere Teil der Arbeit ist die Größenanpassung der Formulare. Falls sie eine unbedingte Vorgabe ist und Sie nicht viel Zeit oder Mühe investieren möchten, gibt es einen einfachen Workaround, um zumindest zwei oder drei Standardauflösungen zu bedienen: Fertigen Sie für jede zu unterstützende Auflösung eine angepasste Kopie der Formulare an.

Ermitteln Sie beim Programmstart die Werte für die Breite und Höhe des Bildschirms und schreiben Sie sie in eine Variable. In der Anwendung rufen Sie dann die jeweils passende Kopie der Formulare auf. Ein Nachteil dieser Methode ist natürlich, dass bei Entwurfsänderungen auch die Kopien gepflegt werden müssen.

Type Rect

    x1 As Long

    y1 As Long

    x2 As Long

    y2 As Long

End Type

Declare Function GetWindowRect Lib "user32" (ByVal hWnd As Long, lpRect As Rect) _
    As Long

Declare Function IsZoomed Lib "user32" (ByVal hWnd As Long) As Long

Declare Function ShowWindow Lib "user32" (ByVal hWnd As Long, _
    ByVal nCmdShow As Long) As Long

Declare Function MoveWindow Lib "user32" (ByVal hWnd As Long, ByVal X As Long, _
    ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, _
    ByVal bRepaint As Long) As Long

Declare Function GetParent Lib "user32" (ByVal hWnd As Long) As Long

Declare Function GetClientRect Lib "user32" (ByVal hWnd As Long, _
    lpRect As Rect) As Long

Public Const SW_MAXIMIZE = 3

Public Const SW_SHOWNORMAL = 1

Sub MaximizeRestoredForm(F As Form)

    Dim MDIRect As Rect

    If IsZoomed(F.hWnd) <> 0 Then

        ShowWindow F.hWnd, SW_SHOWNORMAL

    End If

    GetClientRect GetParent(F.hWnd), MDIRect

    MoveWindow F.hWnd, 0, 0, MDIRect.x2 - MDIRect.x1, MDIRect.y2 - MDIRect.y1, True

End Sub

Quellcode 3

Die wirklich dynamische Anpassung der Formulare an die Bildschirmauflösung ist hingegen ein technisch sehr aufwändiges Unterfangen und erfordert viel Programmcode. Es müssen ja alle Steuerelemente, Beschriftungen, Schriftgrößen, grafischen Elemente und so weiter an die jeweilige Auflösung angepasst werden.

Der Code hierfür würde den Rahmen dieses Artikels sprengen. Es gibt entsprechenden Code in Büchern und auf Webseiten, sowohl gratis als auch käuflich, die sich über eine Websuche finden lassen. Sogar bei kommerziellen Tools kommt es aber in manchen Details bei den Proportionen oder Schriftgrößen zu Problemen.

Formular
minimieren/maximieren

Der Code, um ein Formular zu maximieren, wiederherzustellen oder zu minimieren ist einfach und weithin bekannt:

DoCmd.Maximize

DoCmd.Restore

DoCmd.Minimize

Dieser Code, vor allem jener zum Maximieren, steht in sehr vielen Lade- oder Öffnen-Ereignissen von Access-Anwendungen.

Nun sind Formulare so genannte Kind-Fenster des Access-Hauptfensters. Das hat zur Folge, dass, wenn Sie ein Formular maximieren, wiederherstellen oder minimieren, diese Einstellung auch für alle anderen Formulare gilt, genauso wie bei Dokumenten in Word oder Arbeitsmappen in Excel.

Abb. 2: Maximiertes und nicht maximiertes Formular

Bei Access-Anwendungen ist das oft unerwünscht, insbesondere das Maximieren aller Fenster. Es gibt jedoch keine eingebaute Möglichkeit, um Formular-Fenster individuell zu maximieren. Hier hilft nur API-Code, wie er etwa von Microsoft im Knowledgebase-Artikel 210299 angeboten wird (s. Quellcode 3).

Ich habe den Code des Knowledgebase-Artikels in ein paar wenigen Punkten verändert. Die Hinweise dazu kamen vom englischen Programmierer Terry Kreft.

Sie finden Quellcode 3 auch im Modul basMaxRestoredForm der Beispiel-Datenbank zu diesem Artikel. Ebenfalls enthalten ist das Formular frmMaxRestored, das den praktischen Einsatz zeigt (s. Abb. 2).

Im Ereignis Beim Laden dieses Formulars wird die Prozedur aus Quellcode 3 aufgerufen, um das Formular an die Größe des Access-Fensters anzupassen. Der Aufruf lautet:

MaximizeRestoredForm Me

Das Formular sieht damit genauso aus, als sei es maximiert.

Der große Unterschied und Vorteil ist jedoch, dass weitere Formulare über diesem Formular geöffnet werden können, ohne maximiert zu sein.

Falls Sie Access 97 verwenden, hat diese Methode noch einen positiven Effekt. Access 97 hat einen Bug, der dafür sorgt, dass die Schließen-Schaltfläche eines Formulars im maximierten Zustand erscheint und aktiv ist, auch wenn die Eigenschaft Schließen Schaltfläche auf Nein eingestellt wurde. Diesen Fehler können Sie mit der vorgestellten Methode umgehen.

Alle Steuerelemente sind
verschwunden

Folgendes Verhalten von Access hat schon für so manche Verwunderung und Schrecksekunde gesorgt:

Sie entwerfen ein Formular mit verschiedenen Steuerelementen nur im Detailbereich. Wenn Sie das Formular in der Formularansicht öffnen, ist es jedoch völlig leer.

Kein einziges der zuvor erstellten Steuerelemente ist mehr sichtbar, egal um welchen Steuerelementtyp es sich handelt oder ob gebunden oder nicht. Es präsentiert sich nur der leere Detailbereich. Wechseln Sie in die Entwurfsansicht, so sind alle Steuerelemente wieder zu sehen.

Dieses Verhalten ist "by Design". Die Ursache liegt darin, dass die zugrunde liegende Tabelle oder Abfrage keine Datensätze liefert und die Einstellungen in der Abfrage oder im Formular noch dazu verhindern, dass neue Datensätze angelegt werden können - zum Beispiel, wenn die Eigenschaft Anfügen zulassen des Formulars auf Nein steht.

Abb. 3: Die Steuerelemente sind nur in der Entwursansicht vorhanden.

Abb. 4: Dialogfenster der bedingten Formatierung

Die Lösung des Problems ist einfach: Sorgen Sie dafür, dass die Datenquelle Datensätze liefert oder dass das Anlegen neuer Datensätze erlaubt ist.

Wenn das nicht möglich oder erwünscht ist, so können Sie sich zumindest damit behelfen, dass Sie eine Schaltfläche zum Schließen oder ein anderes Steuerelement in den Formularkopf oder -fuß platzieren. Steuerelemente in diesen Bereichen werden auf jeden Fall angezeigt.

In der Beispieldatenbank zu diesem Artikel finden Sie die beiden Formulare frmOhneSteuerelemente1 und frmOhneSteuerelemente2 die das Verhalten demonstrieren (s. Abb. 3).

Unterschiedliche
Formatierungen im
Endlosformular

Bis einschließlich Access 97 war es nur sehr begrenzt und zum Teil mit Workarounds möglich, unterschiedliche Formatierungen in den Datensätzen eines Endlosformulares zu erhalten. Standardmäßig wirkt sich die Formatierungseinstellung eines Steuerelements auf alle Datensätze aus.

Erst seit der Einführung der Bedingten Formatierung mit Access 2000 wurde dieses Unterfangen wesentlich erleichtert und die Möglichkeiten erweitert.

Die Bedingte Formatierung ist relativ einfach zu handhaben. In der Entwurfsansicht des Formulars muss mindestens ein Steuerelement markiert sein - es können auch mehrere sein, die dann identisch formatiert werden.

Mit der Auswahl des Menüpunkts Format/Bedingte Formatierung öffnet sich das Dialogfenster aus Abb. 4.

Diese Abbildung zeigt auch gleich eine der Schwächen der Bedingten Formatierung. Die Schaltfläche "Hinzufügen" ist deaktiviert, weil bereits drei Bedingungen ausgewählt wurden.

Es sind also nur drei Bedingungen und damit drei unterschiedliche Formatierungen möglich.

Das Einstellen der Bedingungen und Formatierungen im Dialog erklärt sich weitgehend von selbst. Ich gehe daher im Folgenden nur auf ein paar Spezialfälle ein.

Die Bedingte Formatierung ist nur darauf ausgerichtet, einzelne Steuerelemente mit einer besonderen Formatierung zu versehen.

Was aber, wenn Sie einen ganzen Datensatz durch Einfärben seines Hintergrundes hervorheben möchten, sofern er eine bestimmte Bedingung erfüllt?

Hier hilft folgender Workaround:

  • Erzeugen Sie ein neues, ungebundenes Textfeld, das so groß ist wie der komplette Detailbereich des Formulars.
  • Stellen Sie die Eigenschaften Aktiviert auf Nein und Gesperrt auf Ja.
  • Abb. 5: Bedingte Formatierung des Detailbereichs

    Abb. 6: Bedingte Formatierung mit zwei Bedingungen

    Abb. 7: Dummy-Bedingung, die später per Code geändert wird

  • Wählen Sie den Menüpunkt Format/In den Hintergrund, damit das Textfeld hinter allen anderen Steuerelementen des Detailbereichs liegt.
  • Wählen Sie den Menüpunkt For-mat/Bedingte Formatierung und stellen Sie die Bedingung und die gewünschte Forma-tierung für das Textfeld ein. (
  • Abb. 5 zeigt das Formular frmBedingteFormatierung1 in der Beispiel-Datenbank. Die zwei eingestellten Bedingungen lauten Ausdruck ist [Preis]>
    1000 und Ausdruck ist [Preis]<100.

    Im ersten Fall ist die Hintergrundfarbe des Textfeldes auf Rot eingestellt, im zweiten Fall auf Grün. Wichtig ist noch, dass im Dialogfeld die Optionsschaltfläche für Aktiviert, ganz rechts bei den Formatierungen, auf Nein gestellt wird, das heißt nicht vertieft dargestellt ist (s. Abb. 6)..

    Ansonsten würde das Textfeld in den Datensätzen, in denen die Bedingung erfüllt ist, wieder aktiviert und der Fokus könnte in das Textfeld gelangen. Dadurch wird im Dialogfenster zwar die Formatierungs-Vorschau ausgegraut, das Ergebnis sieht aber dennoch farblich wie beabsichtigt aus, denn das Textfeld bleibt weiterhin gesperrt.

    Die Bedingte Formatierung ist auch per VBA programmierbar und zwar mithilfe der Eigenschaft beziehungsweise Auflistung FormatConditions. Für manche Zwecke ist dieser Zugriff per VBA auch unbedingt notwendig. Wenn Sie zum Beispiel den aktuellen Datensatz rot hinterlegen möchten, können Sie zwar wiederum das ungebundene Textfeld aus dem vorhergehenden Beispiel verwenden, für die eigentliche Steuerung muss aber Code verwendet werden.

    Abb. 8: Einfärben des aktuellen Datensatzes

    Im Beispielformular frmBedingteFormatierung2 heißt das Textfeld txtHintergrund. Stellen Sie zuerst eine Bedingung und die gewünschte Formatierung für txtHintergrund ein (s. Abb. 7). Als Bedingung ist eingestellt:

    Ausdruck ist [ArtikelId]=4711

    ArtikelId ist das Primärschlüsselfeld in der Datenherkunft tblArtikel. Es kennzeichnet also eindeutig den Datensatz. Die Zahl 4711 wurde hier absichtlich schnoddrig gewählt, denn es ist eigentlich egal, was in der Bedingung steht. Sie wird ohnehin per VBA geändert. Wichtiger ist, dass Sie die Formatierung wie gewünscht einstellen und nicht vergessen, die Optionsschaltfläche für Aktiviert wieder auf den Wert Nein zu stellen.

    Um zu erreichen, dass der aktuelle Datensatz entsprechend der Formatierung eingefärbt wird, muss per VBA bei jedem Datensatzwechsel die aktuelle ArtikelId in die Bedingung geschrieben werden. Das geschieht mit der folgenden Codezeile im Ereigniscode Beim Anzeigen des Formulars (in einer Zeile):

    Me!txtHintergrund.FormatConditions(0).
    Modify acExpression, acEqual, 
    "ArtikelId = " & Me!ArtikelId

    Details über die verwendeten Parameter und weitere Möglichkeiten zur Programmierung der Bedingten Formatierung gibt es in der Online-Hilfe zu FormatConditions. Abb. 8 zeigt das Ergebnis der Bemühungen. Wie gewünscht wird der jeweils aktuelle Datensatz rot hervorgehoben.

    Bezug auf
    Unterformulare

    Die Syntax für den Bezug auf ein Steuerelement oder eine Eigenschaft in einem Unterformular führt sehr oft zu Problemen. Eine der Ursachen ist die Vielfalt der möglichen Bezüge und Schreibweisen. Ich beschränke mich hier auf einfache Syntaxvarianten, die mit etwas Übung leicht anzuwenden sind. Der richtige Bezug auf ein Steuerelement in einem Unterformular lautet (in einer Zeile):

    Forms![Hauptformular]![Unterformular-Steuerelement]![Steuerelement im Unterformular]

    Der häufigste Fehler in diesem Zusammenhang besteht darin, dass die Eigenschaften Name und Herkunftsobjekt eines Unterformulars verwechselt werden. Die beiden können, müssen aber nicht identisch sein.

    Für den Bezug benötigt man immer nur den Namen des Unterformular-Steuerelements im Hauptformular, also des Steuerelements, in dem sich das Unterformular befindet. Das Herkunftsobjekt hingegen ist für den Bezug uninteressant.

    Möchten Sie in einem Ausdruck im Hauptformular auf ein Steuerelement im Unterformular verweisen, sollte der Bezug so aussehen:

    [Unterformular-Steuerelement]!
    [Steuerelement im Unterformular]

    Möchten Sie im Code des Hauptformulars auf ein Steuerelement in einem Unterformular verweisen, ist es besser, das Schlüsselwort Me davor zu setzen:

    Me![Unterformular-Steuerelement]!
    [Steuerelement im Unterformular]

    Ist im ersten Unterformular ein weiteres Unterformular eingebettet, auf das Bezug genommen werden soll, so bilden Sie einfach die Hierarchie der Unterformulare in der Syntax nach:

    Me![Unterformular1-Steuerelement]!
    [Unterformular2-Steuerelement]!
    [Steuerelement im Unterformular2]

    Die eckigen Klammern können im Code natürlich entfallen, sofern die Objektnamen keine Leer- oder Sonderzeichen enthalten, worauf Sie stets achten sollten.

    Schwierigkeiten bereitet oft der Umgang mit den beiden Methoden SetFocus und GoToRecord im Zusammenhang mit Unterformularen. Möchten Sie den Fokus auf ein bestimmtes Steuerelement im Unterformular setzen, so ist ein zweistufiges Vorgehen notwendig, damit das zuverlässig klappt. Setzen Sie zuerst den Fokus auf das Unterformular-Steuerelement im Hauptformular und danach erst auf das Steuerelement im Unterformular:

    Me![Unterformular-Steuerelement].SetFocus

    Me![Unterformular-Steuerelement]![Steuerelement im Unterformular].SetFocus

    Analog funktioniert das Wechseln des aktuellen Datensatzes im Unterformular mit der Methode GotoRecord.

    Me![Unterformular-Steuerelement].SetFocus

    DoCmd.GoToRecord , , acNext

    Wichtig ist, dass die beiden Parameter nach GoToRecord leer gelassen werden. Sie dienen zur Angabe des Objekttyps und des Objektnamens und führen bei einem Unterformular unweigerlich zu Fehlermeldungen, weil es keinen passenden Objekttyp für ein Unterformular gibt und das Herkunftsobjekt des Unterformulars nicht wirklich geöffnet ist.

    Möchten Sie sich hingegen auf eine Eigenschaft des Herkunftsobjektes beziehen, also des Formulars, das als Unterformular dient, dann müssen Sie dessen Form-Eigenschaft ansprechen. Angenommen Sie haben VBA-Code im Hauptformular, der die Eigenschaft Daten Eingeben (in VBA: DataEntry) des Unterformulars auf Ja setzen soll. Der richtige Befehl dazu lautet:

    Me![Unterformular-Steuerelement].Form.DataEntry = True

    Unterformular wechseln

    Eine praktische Sache für viele Zwecke ist das dynamische Wechseln des Unterformulars per Code. Sie können damit im selben Unterformular-Steuerelement verschiedene Unterformulare anzeigen.

    Im Beispielformular frmUnterFormularWechseln (s. Abb. 9) werden etwa wechselweise Unterformulare für Ansprechpartner und Artikel angezeigt.

    Abb. 9: Wechselnde Unterformulare

    Der Wechsel erfolgt bei Klick auf die beiden entsprechenden Schaltflächen. Der für das Wechseln des dargestellten Unterformulars nötige Code ist sehr kurz, in der Regel genügt eine Zeile nach dem Muster:

    Me![Unterformular-Steuerelement]
    .SourceObject = "AnderesUnterformular"

    Es wird also nur das Herkunftsobjekt (in VBA: SourceObject) des Unterformular-Steuerelements geändert.

    Wenn Sie Haupt- und Unterformular über bestimmte Felder verknüpfen möchten, so können Sie diese Einstellungen unmittelbar nach dem Zuweisen des Herkunftsobjekts vornehmen:

    Me!UFoElement.LinkChildFields = "Feld_im_Unterformular"

    Me!UFoElement.LinkMasterFields = "Feld_im_HauptFormular"

    Ansonsten stellt Access automatisch die Eigenschaften Verknüpfen von und Verknüpfen nach des Unterformulars auf den Feldnamen eines Primärschlüsselfeldes, sofern es im Haupt- und im Unterformular Felder mit gleichem Namen findet. Das ist meistens ein Vorteil, weil man sich nicht um die korrekte Verknüpfung kümmern muss. Es kann aber zum Nachteil werden, wenn man eben nicht über diese gleich benannten Felder verknüpfen möchte.

    In diesem Fall muss man die beiden Eigenschaften zuerst auf einen Leerstring einstellen und dann mit den gewünschten Verknüpfungsfeldern versorgen (Beispiel siehe Beispieldatenbank).

    Me!UFoElement.SourceObject = _
        "AnderesUnterformular"

    Me!UFoElement.LinkChildFields = ""

    Me!UFoElement.LinkMasterFields = ""

    Me!UFoElement.LinkChildFields = _
        "Feld_im_Unterformular"

    Me!UFoElement.LinkMasterFields = _
        "Feld_im_Hauptformular"

    Formulare synchronisieren

    Eine ähnliche Funktionalität wie mit Unterformularen können Sie auch mit zwei separaten Formularen erzielen. Nur müssen Sie die Angleichung des jeweils aktuellen Datensatzes selbst programmieren.

    Der häufigste Anwendungsfall: In einem Auswahlformular befinden sich alle Datensätze. Bei Auswahl eines Datensatzes sollen in einem anderen Formular die Details zu diesem Datensatz erscheinen.

    Die einfachste Variante ist, dass (zum Beispiel beim Klicken einer Befehlsschaltfläche) ein Detailformular zu dem ausgewählten Datensatz geöffnet wird. In der Beispieldatenbank finden Sie dazu die beiden Formulare frmArtikelAuswahl und frmArtikelDetails. Im Formular frmArtikelAuswahl steht hinter der ersten Schaltfläche folgender Code, der das Formular frmArtikelDetails mit der gewünschten Where-Klausel öffnet:

    DoCmd.OpenForm "frmArtikelDetails", , , "ArtikelId = " & Me!ArtikelId

    Nun gibt es aber Fälle, in denen das Detailformular nicht nur mit einem einzelnen Datensatz geöffnet werden soll, sondern mit allen Datensätzen, aber mit dem ausgewählten als aktuellem. Dadurch können Sie im Detailformular beliebig navigieren. Quellcode 4 steht hinter der zweiten Schaltfläche im frmArtikelAuswahl.

    If fctIsFormOpen("frmArtikelDetails") = _
      False Then

      DoCmd.OpenForm "frmArtikelDetails"

    End If

    Dim rs As DAO.Recordset

    Set rs = _
      Forms!frmArtikelDetails.RecordsetClone

    rs.FindFirst "ArtikelId = " _
      & Me!ArtikelId

    If Not rs.NoMatch Then

      Forms!frmArtikelDetails.Bookmark = rs.Bookmark

    End If

    Set rs = Nothing

    Zuerst wird - wie im ersten Thema dieses Artikels erläutert - geprüft, ob das Detailformular bereits geöffnet ist, und ansonsten geöffnet. Dann wird ein DAO-Recordset mit dem RecordsetClone des Detailformulars belegt.

    Mit der Methode FindFirst wird im Recordset die passende Artikelid gesucht. Anschließend wird die Bookmark-Eigenschaft des Detailformulars mit der seines RecordsetClones synchronisiert. Dadurch wechselt das Formular zum entsprechenden Datensatz.

    Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

    Sind Sie Abonnent?Jetzt einloggen ...
     

    Kompletten Artikel lesen?

    Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

    E-Mail:

    © 2003-2015 André Minhorst Alle Rechte vorbehalten.