Verschiedene Anwendungszwecke machen es erforderlich, dass man ein Formular an einer bestimmten Position \u00f6ffnet. Und selbst wenn es an sich nicht erforderlich ist, steigert es doch die Ergonomie, wenn zum Beispiel ein Popup-Formular an der Stelle erscheint, an der man den Befehl zum \u00d6ffnen bet\u00e4tigt hat \u2013 beispielsweise durch einen Klick auf eine Schaltfl\u00e4che oder auf ein anderes Steuerelement. In diesem Beitrag schauen wir uns an, wie wir unabh\u00e4ngig von anderen Elementen ein Formular \u00f6ffnen und an der Position des Mauszeiters positionieren k\u00f6nnen. Dazu ben\u00f6tigen wir nichts au\u00dfer ein paar Ereignisprozeduren und API-Funktionen.<\/p>\n
Zum Artikel …<\/a><\/p>\n Modale Dialoge, also Formulare, die mit dem Befehl DoCmd.OpenForm mit dem Parameter WindowMode:=acDialog ge\u00f6ffnet wurden, sind in vielen F\u00e4llen hilfreich: Wir k\u00f6nnen den aufrufenden Code anhalten, bis das Formular geschlossen oder ausgeblendet wird und so gegebenenfalls auszulesende Werte ermitteln. Oder wir sorgen so daf\u00fcr, dass der Benutzer nicht an anderen Formularen arbeiten kann, bevor er nicht die Eingabe in dieses Formular abgeschlossen hat. Einen Nachteil haben modale Dialog allerdings: Wir k\u00f6nnen ihre Rahmenart nicht so einstellen, wie wir es von normal ge\u00f6ffneten Formularen gewohnt sind. Wollen wir also einen modalen Dialog einmal ohne Titelleiste anzeigen, weil er zum Beispiel einfach als Erweiterung neben einem anderen Steuerelement ge\u00f6ffnet werden soll, k\u00f6nnen wir das so nicht machen. Es gibt allerdings einen Workaround, den wir hier vorstellen.<\/p>\n Zum Artikel …<\/a><\/p>\n F\u00fcr Felder in Tabellen kann man jeweils einen Standardwert im Tabellenentwurf festlegen, der beim Anlegen eines neuen Datensatzes in dieser Tabelle vorbelegt wird. Etwas anspruchsvoller ist es, wenn wir Standardwerte durch den Benutzer festlegen wollen. Noch einen Schritt weiter gehen wir, wenn der Standardwert f\u00fcr ein Fremdschl\u00fcsselfeld verwendet werden soll \u2013 also zur Auswahl eines Datensatzes aus einer verkn\u00fcpften Tabelle. Einfache Beispiele sind Anreden, Zahlungsmethoden, Priorit\u00e4ten oder Kategorien. Hier k\u00f6nnen wir jeweils einen Eintrag anwendungsweit festlegen. Es geht aber auch noch anspruchsvoller: Wenn wir beispielsweise Adressen f\u00fcr Kunden in einer eigenen Tabelle speichern, wo mehrere Adressen je Kunde angelegt werden k\u00f6nnen und nur eine als Standard verwendet werden soll. Sp\u00e4testens hier m\u00fcssen wir auch beim Datenmodell umdenken. In diesem Beitrag schauen wir uns erst einmal an, wie wir Standardwerte f\u00fcr Nachschlagefelder komfortabel ausw\u00e4hlen k\u00f6nnen.<\/p>\n Zum Artikel …<\/a><\/p>\n In der bisherigen Version der Rechnungsverwaltung haben wir nur eine Kundenadresse gespeichert, die in der Tabelle \u00bbtblKunden\u00ab gespeichert war. Im Bestreben, diese Rechnungsverwaltung flexibler zu gestalten, wollen wir in diesem Beitrag zwei Dinge durchf\u00fchren: Das Aufteilen der Kundentabelle in eine Tabelle mit den Basisdaten des Kunden und mehrere weitere Tabellen zum Speichern der Adressen dieses Kunden sowie das Anpassen des Formulars \u00bbfrmKundenDetails\u00ab an diese \u00c4nderung des Datenmodells. Dies soll die Grundlage bilden, mehrere Adressen je Kunde zu speichern und diese dann nach Bedarf in Bestellungen, Lieferungen, Rechnungen und weitere Vorg\u00e4nge zu \u00fcbernehmen.<\/p>\n Zum Artikel …<\/a><\/p>\n Im ersten Teil dieser Beitragsreihe haben wir die grundlegenden Ideen vorgestellt, die wir zum Thema Bestellungen\/Rechnungen\/Lieferungen haben. Uns ist jedoch noch eine Feinheit entgangen, die wir in diesem Beitrag noch nachreichen wollen. Dabei geht es darum, eventuelle Inkonsistenzen beim Erstellen von Rechnungspositionen auf Basis von Bestellpositionen zu vermeiden. Normalerweise sollte mit dem aktuellen Datenmodell nichts schiefgehen, aber das Datenmodell sollte so viele Probleme wie m\u00f6glich bereits durch die enthaltenen Restriktionen in Form von Beziehungen verhindern.<\/p>\n Zum Artikel …<\/a><\/p>\n Wer wie ich den SQL Server auf dem gleichen Desktop-Rechner installiert hat, auf dem er auch arbeitet, macht sich \u00fcber den Einsatz im Netzwerk keine gro\u00dfen Gedanken. Neulich aber habe ich einen neuen Rechner aufgesetzt und es fehlte schlicht die Zeit, auch den SQL Server und die damit verwalteten Datenbanken auf dem neuen Rechner zu installieren. Also dachte ich, dass ich einfach \u00fcber das Netzwerk auf den SQL Server des alten Rechners zugreifen k\u00f6nnte. Das geht jedoch nicht ohne Weiteres und je nach Konfiguration ist der eine oder andere Schritt n\u00f6tig. Also schauen wir uns an, was bei mir zum Erfolg gef\u00fchrt hat.<\/p>\n Zum Artikel …<\/a><\/p>\n Seit vielen Jahren w\u00fcnschen sich Access-Nutzer sehr kleine Ver\u00e4nderungen von Microsoft, die den Programmieralltag stark erleichtern k\u00f6nnten.\u00a0Eine davon ist, Abfragen direkt in der SQL-Ansicht zu \u00f6ffnen. Ja, es gibt Entwickler, die nicht ausschlie\u00dflich in der Entwurfsansicht arbeiten \u2013 und manche Abfragetypen wie beispielsweise die UNION-Abfrage k\u00f6nnen nur in der SQL-Ansicht angezeigt werden. Bis vor kurzem musste man zur SQL-Ansicht einen Umweg \u00fcber die Entwurfsansicht gehen. Wie dieser aussah und welche M\u00f6glichkeiten wir nun haben, zeigen wir in diesem Beitrag.<\/p>\n Zum Artikel …<\/a><\/p>\n Microsoft hat neuerdings einen Befehl zum direkten Anzeigen von Abfragen in der SQL-Ansicht. Damit k\u00f6nnen wir eine Abfrage direkt in der SQL-Ansicht \u00f6ffnen statt den Umweg \u00fcber den Abfrageentwurf zu w\u00e4hlen. Leider hat Microsoft keine entsprechende Funktion f\u00fcr das Erstellen von Abfragen hinzugef\u00fcgt \u2013 also eine Schaltfl\u00e4che im Ribbon, mit der wir eine neue SQL-Abfrage direkt in der SQL-Ansicht \u00f6ffnen k\u00f6nnen. Das ist allerdings gar nicht schlimm, denn wir r\u00fcsten diese Funktion einfach selbst nach. Zun\u00e4chst schauen wir uns an, welche Befehle dazu notwendig sind, danach erstellen wir ein COM-Add-In, das die Funktion in der Benutzeroberfl\u00e4che verankert \u2013 gleich neben den Schaltfl\u00e4chen f\u00fcr den Abfrageassistenten und das Anlegen von neuen Abfragen \u00fcber die Entwurfsansicht.<\/p>\n Zum Artikel …<\/a><\/p>\n Wenn man eine COM-DLL oder ein COM-Add-In mit VB6 oder twinBASIC erstellt hat, muss dieses registriert werden muss, damit es in einer der Office-Anwendungen angezeigt wird oder unter VBA zur Verf\u00fcgung steht. Die Informationen f\u00fcr die Registrierung werden in der Regel direkt in die jeweilige .dll-Datei integriert, sodass man die Registrierung nur noch von au\u00dfen initialisieren muss. Daf\u00fcr gibt es verschiedene Wege, die sich je nach Zweck (COM-DLL oder COM-Add-In) unterscheiden. Einer davon ist das Erstellen eines Setups mit Inno Setup. Dieses braucht der Anwender nur auszuf\u00fchren und muss keine Verrenkungen machen, um die neuen Funktionen auf seinem Rechner nutzen zu k\u00f6nnen. Es gibt aber auch noch alternative Methoden, die wir ebenfalls in diesem Beitrag vorstellen.<\/p>\nModale Dialoge nach Wunsch gestalten<\/h3>\n
Standardwerte f\u00fcr Fremdschl\u00fcsselfelder pflegen<\/h3>\n
Rechnungsverwaltung: Kundenadressen ausgliedern<\/h3>\n
Datenmodelle f\u00fcr die Rechnungsverwaltung, Teil 2<\/h3>\n
SQL Server zwischen zwei Rechnern im Netzwerk<\/h3>\n
Abfragen in der SQL-Ansicht \u00f6ffnen<\/h3>\n
Abfragen direkt in der SQL-Ansicht erstellen<\/h3>\n
COM-Add-Ins und -DLLs installieren oder registrieren<\/h3>\n