MENÜBEFEHLE / DoMenuItem
Eine Sache, die immer wieder Verdruß bereitet, da das umständliche Herausfischen irgendwelcher ListIndex-Werte in den Kombinationsfeldern des Makro-Entwurfs-Modus spätestens beim zweiten Mal tierisch nervt.
Existiert zu einem angesagten Menübefehl eine Tastenkombination, wurde bisher das nicht immer unproblematische SendKeys eingesetzt. Mit DoCmd MenuItem steht immerhin ein Code-Werkzeug zur Verfügung, das auf die an sich funktionierenden ACCESS-Internas zurückgreift. Um das Handeln solcher Menü-Befehle zu vereinfachen, bietet es sich an, die entsprechenden Befehle mit aussagekräftigen Prozedurnamen (Rueckgaengig_Feld) zu versehen und in einem eigenen Modul (MENU_VER20) zu speichern.
Aber es gab auch schon Fälle, in denen Indexwerte, die gemäß Doku aus Makro-Ausführen-Menübefehl herausgefischt und in eine DoMenuItem-Code-Funktion eingesetzt wurden, einfach nicht zum gewünschtem Erfolg führten.
Dasselbe anstatt Code in ein echtes Makro AusführenMenübefehl eingebettet tut dann doch.
Was lernen wir daraus:
Makros entsprechen wirklich überhaupt nicht dem, was ich als Programmieren bezeichnen würde, aber man muß die softe Ware eben nehmen, wie Sie ist, und deswegen ist es wohl besser, Menübefehle nicht in ein Modul, sondern in ein Mehrfach-Makro 'Menübefehle' zu packen, dann klappt's auch mit der Datenbank.
WÜRG !
Beinahe wäre es gelungen, durch Code-gesteuertes Umbenennen diverser Tastatur-Belegungs-Makro's nach 'Tastaturbelegung' einer Applikation kontextbezogene Short-Cuts unterzujubeln. Leider mußte festgestellt werden, daß die Short-Cut's mal tun und mal nicht.
Bevor wieder end- und ergebnislose Stunden geopfert wurden, habe ich beschlossen, so etwas im Notfall über Menüleisten-Makros zu machen (Würg!) und lieber 15 min. in eine Imitation einer ausführbaren 'Menüleisten-Direkt-Option' zu investieren.
Bevor Freude aufkommt:
Nach 5 min. war klar, daß die Menü-Makro's sich nicht so einfach verarschen lassen.
Akzeptabler Kompromiß:
Selbstdefinierte MENÜLEISTEN / MENÜMAKRO's
Das Erstellen eigener Menüleisten mittels des Menü-Editors sowie der ihm eigenen Makro-Technik führt zu einer unüberschaubaren Flut von Drecks-Makros, deren Namen zudem zu nicht mehr zumutbaren Konstrukten anschwellen.
Aber immerhin scheint Access die Kontrolle über die Funktionsweise einzelner Menüpunkte zu behalten. Laut dem 'großen Buch zur Access-Programmierung' kann es bei solchen Menüleisten zu Problemen kommen, wenn solche Menü's durch eigene Zusätze erweitert werden. Dieses Problem konnte aber mittlerweile nachvollzogen werden, und zwar bei selbsterstellten Menüleisten-Einträgen sowie selbsterstellten Symbolleisten-Schaltflächen. Wenn diese Einträge bzw. Schaltflächen auf selbsterstellte Makros verweisen anstatt native Access-Funktionen zu benutzen (z.B. 'Schließen'), damit z.B. englische Sprechblasentexte realisiert werden können ('Close'), verliert Access die Kontrolle über die Sinnhaftigkeit der Aktion im jeweils aktuellen Kontext. Ein De-Aktivieren per API-Funktionen kann bei den bisher gemachten Erfahrungen nicht einmal im Traum avisiert werden.
Sehr interessant ist auch die von Oliver Krüger angeregte Möglichkeit, zu versuchen, ein Formular völlig ohne Menüleiste im monitor-füllenden Vollbildmodus anzeigen zu lassen. Dies konnte aber nur mittels typischer Kack-Tricks erreicht werden. Nachzusehen in KORO.MDB.
Ferner besteht die Möglichkeit, einen Text in die Menüleiste einzublenden, ohne daß damit ein aufklappbares Pull-Down-Menü verbunden ist. Ein Standard-Menüleisten-Makro verweist auf ein Untermenü-Makro, das gar keinen Eintrag, bzw. keinen mit Namen enthält. Leider ist es nicht möglich, einen untermenülosem Menüeintrag eine direkte Funktion ausführen zu lassen, was aber laut SAA-Standard vorgesehen ist. Wer hat eigentlich diesen Standard mitverbrochen ? - Microsoft, und wer hält sich nicht an seine Standards ? ...
