Kategorie: Formulare und Steuerelemente

Immer wieder taucht die Anforderung auf, dass wir prüfen müssen, ob ein Formular geöffnet ist. Das ist zum Beispiel der Fall, wenn man von einem anderen Formular oder Modul aus auf die Inhalte des fraglichen Formulars zugreifen möchte. Es gibt verschiedene Möglichkeiten, zu prüfen, ob das Formular geöffnet ist. In diesem Beitrag schauen wir uns die verschiedenen Möglichkeiten an.

In vielen bisherigen Lösungen haben wir für die Schnellsuche im Listenfeld oder auch in Unterformularen in der Datenblattansicht ein Textfeld als Suchfeld verwendet. Direkt bei Eingabe eines jeden Zeichens wurde das Suchergebnis aktualisiert. In diesem Beitrag wollen wir einmal eine noch ergonomischere Version vorstellen. Der Unterschied soll so aussehen, dass man den Suchbegriff eingeben kann, während das Listenfeld den Fokus hat. Es soll also kein Wechseln vom Suchfeld zum Listenfeld und zurück nötig sein, wenn man durch die Suche den gewünschten Datensatz vorgefunden hat und diesen beispielsweise markieren und beispielsweise durch Betätigen der Eingabetaste eine Aktion für diesen Eintrag durchführen möchte. Wir zeigen dies am Beispiel aus dem Beitrag „m:n-Beziehung mit Listenfeld und Datenblatt“ (www.access-im-unternehmen.de/1510).

Es gibt verschiedene Möglichkeiten, eine m:n-Beziehung zwischen zwei Tabellen in Formularen abzubilden: Mit zwei Listenfeldern, mit einem Haupt- und einem Unterformular und viele weitere. In diesem Beitrag schauen wir uns eine Kombination aus Listenfeld und Datenblatt an. Dabei betrachten wir das Beispiel von Fahrzeugen und Ausstattungsmerkmalen. Eigentlich sollte man meinen, das wäre eine reine m:n-Beziehung, in der die Verknüpfungstabelle nur die Zuordnung der Merkmale zu den Fahrzeugen vornimmt. Allerdings liefert einer unserer Kunden ein Beispiel, bei dem es etwas aufwendiger wird: Zusätzlich zur reinen Zuordnung soll auch noch festgelegt werden können, welche Ausstattungsmerkmale mit auf das Preisschild sollen und welche Serien- und welche Sonderausstattungen es gibt. Kein Problem: Dann bauen wir einfach eine ergonomische Lösung für diesen Fall, wie dieser Beitrag zeigt.

In einem anderen Beitrag namens „Mehrwertige Felder mit Wertliste loswerden“ (www.access-im-unternehmen.de/1493) beschreiben wir, wie man die in Access 2010 eingeführten mehrwertige Felder durch m:n-Beziehungen ersetzt. Es fehlt dann allerdings die praktische Liste mit Kontrollkästchen, mit der man einen oder mehrere der zu verknüpfenden Elemente einfach markieren kann. Auf diese Weise lassen sich schnell die Kategorien zu einem Produkt oder auch die Ausstattungen für Fahrzeuge zusammenklicken. Da für uns das Motto „Wer A sagt, muss auch B sagen“ gilt, liefern wir also noch eine Möglichkeit hinterher, um die aus den mehrwertigen Feldern in eine m:n-Beziehung überführten Daten auf praktische Weise anzuzeigen.

Eine gute Basis für das Anzeigen und Bearbeiten von Daten ist die folgende Konstellation: Wir verwenden ein Haupt- und Unterformular, um die Daten einer Tabelle in einer Übersichtsansicht anzuzeigen. Dabei können wir die Daten, die im Unterformular angezeigt werden, filtern und sortieren. Außerdem stellen wir Schaltflächen bereit, mit denen wir die Datensätze anlegen, bearbeiten und löschen können. Zum Bearbeiten verwenden wir ein weiteres Formular, das die Daten in einer übersichtlichen Ansicht darstellt. Zusätzlich fügen wir noch ein den Code hinzu, der für das Interagieren der Formulare untereinander notwendig ist. Diese Konstellation von Formularen können wir für alle möglichen Tabellen verwenden und schaffen so die Basis einer professionellen Anwendung. Anpassungen können schließlich dort vorgenommen werden, wo m:n- oder 1:n-Beziehungen dargestellt werden sollen.

Es gibt seit vielen Jahren einen Bug in Access-Formularen, der möglicherweise Entwickler und Benutzer in den Wahnsinn treibt. Dabei geht es darum, dass neue oder geänderte Datensätze beim Schließen des Formulars nicht automatisch gespeichert werden. Stattdessen findet man neue Datensätze einfach nicht in der entsprechenden Tabelle vor und bei vermeintlich geänderten Datensätzen wurde die Änderung nicht übernommen. Dies geschieht, wenn man das Formular auf eine bestimmte Art schließt und Restriktionen in der zugrunde liegenden Tabelle dafür sorgen, dass der Datensatz nicht gespeichert werden kann. Wird zum Beispiel ein Pflichtfeld nicht gefüllt und das Formular geschlossen, verwirft Access den neuen Datensatz einfach, anstatt eine entsprechende Meldung zu liefern. Dieser Beitrag dokumentiert das Fehlverhalten und zeigt, welche Möglichkeiten wir zum Umgehen dieses Problems haben.

Wenn man das TreeView-Steuerelement professioneller nutzt, programmiert man unter anderem Ereignisse, die durch das Anklicken von Elementen ausgelöst werden. Damit kann man Ereignisprozeduren auslösen, die beispielsweise Daten zum angeklickten Element in einem Unterformular anzeigen oder man blendet ein Kontextmenü zum jeweils angeklickten Element mit weiteren Optionen ein. Dazu ist es notwendig, zu identifizieren, auf welches Element der Benutzer geklickt hat. Die notwendigen Informationen liefern die Parameter der Prozeduren, das Ermitteln des angeklickten Elements erledigt man mit einer bestimmten Funktion. Seit Kurzem erreichen uns allerdings Meldungen von Lesern, bei denen dies nicht mehr zuverlässig funktioniert: Es werden keine Kontextmenüs mehr angezeigt und auch das Anklicken gelingt nicht mehr wie gewünscht. Interessanterweise tritt das Problem nur bei Verwendung von Office 365 auf. Wir schauen uns in diesem Beitrag an, woher das Problem rührt und wie Sie es lösen können.

Im Beitrag „Icons in Access-Formularen und Berichten“ (www.access-im-unternehmen.de/1235) haben wir schon einmal eine Möglichkeit aufgezeigt, wir man Formulare und Berichte in Access mit individuellen Icons ausstatten kann. So kann man beispielsweise ein Formular zum Bearbeiten eines Kunden mit dem gleichen Icon ausstatten, das man auch für die Schaltfläche zum Öffnen dieses Formulars im Ribbon untergebracht hat. Der Benutzer kann so noch besser erkennen, worum es im Formular geht. In der vorherigen Fassung der Lösung hatten wir allerdings noch das Problem, dass wir die Icons, die links oben in Formularen und Berichten erscheinen sollten, noch im Dateisystem speichern mussten. Das kann aus diversen Gründen zu Problem führen und daher sind wir froh, hier den nächsten Schritt gehen zu können: Das direkt Einlesen der Icons aus der Tabelle „MSysResources“ und anschließendes Anzeigen in Formulare und Berichten.