Office: (Office 2003) Kontextmenü mit eigenen Befehlen

Hallo zusammen,
ich bräuchte mal wieder ein paar Schubser.

Stehe vor meinem ersten "Kontextmenü". Ich brauche aber eines, welches bei Klick auf meinen Eintrag eigene Codes ausführt.

Wie man Access-eigene Kontextmenüs über 'Symbolleiste' erstellt ist klar. Aber soweit ich erlesen konnte, kann man hier nur Accesseigene Befehle anwenden.

Nun habe ich 2 Ideen.
1. Listenfeld mit den Befehlen in ein Form packen, Form über XY-Koordinaten beim aufrufenden Control öffnen
2. im Grunde wie 1., nur das Listenfeld im eigentlichen Formular unterbringen und bei Aufruf positionieren und sichtbar schalten.

Mir gefällt Variante 2 besser, denn bei 1. hat man den Nachteil das gesamte Formularrahmen und die Titelleiste zu sehen sind. Außerdem muss man die Befehlsaktionen in das aufrufende Form zurück holen

Vllt. hat noch jemand andere Vorschläge???

:)

 

Meinst Du mit Vorschläge Ideen oder konkrete Lösungsvorschläge?

Empfehlung: Schau Dir mal das AEK-Script "Kleine Helferlein" an.

 

Hallo Eberhard,

ich meinte Ideen. Nach Fertiglösungen zu fragen ist in den seltensten Fällen meins. Da müsste ich schon sehr verzweifelt sein.

Ich werde mir Deine Empfehlung mal raussuchen im NEtz. Danke

 

Hab den Beitrag gefunden. Die Idee dort deckt sich im Ansatz mit meinem 2. Gedanken und hilft mir weiter. Nur das ich es wirklich per Rechtsklick öffnen will als Kontextmenü und nicht mit einem sichtbaren Button.

Nochmal danke für den Hinweis und schönes Wochenende.

 

In der KnowHow von Klaus Oberdalhoff gibt es auch eine Lösung zu einem eigenen Kontextmenü.

 

Es gibt einen Befehl Benutzerdefiniert. Diesen kannst du mit eigenen Funktionen, die in einem öffentlichen Modul stehen, hinterlegen.
Du kannst dir also auch ohne Formular ein komplett eigenes Kontextmenü erstellen.

 

Nochmals Danke.

@Marsu, ich hab "Benutzerdefiniert" irgendwie nicht geblickt, das ist für die Lösung.

 

Meine Erkenntnisse und Lösung für andere.

Aber erstmal:
@Marsu
Dank Deiner Einlassung bin ich nun auch dahinter gekommen, das man neben Benutzerdefinierten Befehlen auch jeden anderen Befehl in eigene Menüleisten packen und nach eigenen Bedürfnissen modifizieren kann.
@Eberhard
Ich hab mich in Grundzügen an der Lösung aus dem AEK-Script orientiert

Zielstellung:
Ein Treeview mit 2 Ebenen, eine Root -und eine Childebene sollten mit Kontextmenü versehen werden, wobei sich die Befehlssätze für beide Ebenen unterscheiden sollen. Dazu wurden zwei benutzerdefinierte Kontextmenüs erstellt.

Quellen:
Erstmal die Anregungen von Eberhard und Marsu
Prinzip folgt abgewandelt dem AEK12-Beitrag 'Kleine Helferlein' / DropDownMenüs in Formularen
Zur Umrechnung von Twips in Pixel siehe HIER
Zur Umrechnung und Ermittlung der aktuellen DPI-Einstellungen siehe HIER

Problem bei der Positionierung des Kontextmenü ist, das dazu Bildschirmkoordinaten in Pixel gebraucht werden, während die x/y Koordinaten der Mouse-Ereignisse als auch die Positionierungs -und Dimensionierungsmaße für Controls in Twips angegeben werden. Das lässt sich natürlich alles berechnen, dabei sollte man immer den aktuellen DPI-Wert in die Berechnungen einbeziehen, weil die Pixelbreite in Twips von der DPI abhängig ist.

Standardcontrols w.z.B. Text -u. Kombiboxen o. Optionsfelder haben die Eigenschaft 'Kontextmenüleiste' in der man das gewünschte Kontextmenü eintragen kann. Ein Rechtsklick in das Control öffnet das Menü dann automatisch.

Tree -u. Listview und sicher die meisten, wenn nicht alle, anderen Active-X-Controls, bieten diese Eigenschaft nicht an. Dafür verfügen sie über die Eigenschaft 'hWnd' (nur unter VBA oder in Makros verfügbar). 'hWnd' beinhaltet einen eindeutigen Long-Wert der dem Control von Windows zugewiesen wurde. Über API-Funktionen lässt sich ermitteln, welches Fenster bzw. Treeview-Control den Fokus (den Fokus über alle geöffneten Fenster[nicht nur Access]) hat. Da das Treeview bei einem Click zuvor den Focus erhalten hat, kann über die API-Funktion 'Getfocus()' dessen Handle ermittelt werden. Dieses benutzt danach die API-Funktion 'GetWindowRect()' um die Eckdaten (Links, Oben, Rechts, Unten) des Treeviews zu ermitteln und in einer Array-Struktur zurück zu geben. Die Rückgabewerte werden in einem Object vom Type 'Rect' abgelegt.

Bitte in den Codes auf die Kommentare achten:

Aufgerufen wird meine Lösung bei 'Treeview_MouseDown', mein Treeview heißt 'tv_gruppen':

Code:

Weiter geht es mit folgender Prozedur:
Code:

Für die Verwendung von voran gezeigter Sub sind folgende (API)-Deklarationen notwendig. Diese müssen in einem Modul stehen.
Code:

Für die Ermittlung der aktuellen DPI-Einstellung sorgt dieser Code:
Code:

Vllt. kann der Eine oder Andere mit dieser Lösung was anfangen.

Bei mir ist alles getestet und als 'funzt' anerkannt worden. Sollte trotzdem irgendwo ein (Tipp)Fehler sein, dann bitte ich um Info. Auch dann, wenn ich irgend etwas falsch erklärt haben sollte.

 

Hallo Uwe,

da ich vor kurzem ein Kontext für´s Treeview gebraucht habe, will ich nicht verschweigen, dass es auch ohne APIs geht.
Zwar musste ich bei mir nicht unterscheiden, ob Root oder Child, jedoch ließ sich das schnell anpassen (und kommentieren).
Code:

Schade, dass du nicht direkt gesagt hast, was du vorhast.
Hätte dir vlt. ein bisken Suche und Arbeit erspart *Smilie

 

Danke für Dein Beitrag. Dein Code deckt sich doch im Grunde mit meinem aber das eigentliche Problem löst der auch nicht, nämlich, wie und wo das Kontextmenü positioniert wird. Oder übersehe ich da was. Die Positionierung war am Ende die größere Herausforderung.

Naja und manchmal weiss man erst dann, was man vorhat, wenn man weiss, was geht. Und durch solche Arbeit lerne ich. Mich treibt ja keiner.

 

Naja, ich kann das Rad ja auch nicht neu erfinden. *wink.gif*
Man spart sich die APIs und du musst Root/ Child nicht im Nodekey haben.

Bei mir erscheint der Kontext direkt neben dem Node bzw. Mauszeiger.

Kannst es ja mal ausprobieren und berichten ob, bzw. welche Unterschiede zur Positionierung per API bestehen.

 

Warum eigentlich nicht??? Man wäre doch jahrelang im Gespräch *grins *grins *grins

Das probiere ich in der Tat aus aber erst Morgen. Ich habe nirgends einen Hinweis gesehen, das das so geht. Und selbst wenn, durch meine Lösung hab ich die Menüs auf einer fixen X-Position, so dass mir die Einträge des Treeview nicht überdeckt werden. Das finde ich ganz angenehm und war auch so gewollt.

Ich erstatte Bericht, sobald ich es getestet habe.

 

Ich habs doch gleich noch getestet. Musste ja nur die Koordinaten hinter 'ShowPopup' auskommentieren.

Es funzt tatsächlich so. Ich dachte wohl auch deswegen, das es nicht geht, weil das Treeview keine Eigenschaft Namens 'Kontextmenüleiste' hat.

Trotzdem bleibe ich wegen der Sichtbarkeit der Einträge bei meiner Variante. Wäre höchsten nochmal interesant zu gucken ob sich die Positionierung nicht doch irgendwie ohne API realisiseren lässt.

In wie weit machen APi-Funktionen eine Datenbankanwendung eigentlich störanfällig oder langsamer???

 

Danke für die Rückmeldung!

Das heißt, dass du das Popup, unabhängig davon welcher Knoten angeklickt wurde, immer an der selben Stelle im/am Treeview anzeigen lassen möchtest?
(Ich gehe davon aus, dass ein Knoten im TW kein eigenes Focushandle besitzt)

Ich hätte lieber das Kontextmenü in Mausnähe. Aber das mag wie oft Geschmacks-/Gewohnheitssache sein.

In dem Fall IMHO nicht. Irgendwie musst du ja feststellen, wo sich das Formular/Treeview gerade auf dem Bildschirm befindet, um das Popup in Relation dazu zu positionieren.

Meiner Erfahrung nach weder noch, wenn richtig angewendet.
Du nutzt meinem Verständnis nach, bei APIs nur den direkten /"kleinen Dienstweg", statt den "Umweg" über VBA zu gehen.

BTW: Ich habe mir deinen Code nochmal angesehen.
Du machst nirgendwo den angeklickten Node zum Selected Node.
Daher dürfte eigentl. der angeklickte nicht als ausgewählt unterlegt werden.

 

Gerne, ich lerne ja auch davon*Smilie

Nicht ganz.
Die x-Position soll die selbe sein. Nämlich der rechte Rand des Treeview-Rahmens. Meine Intention ist die:
wenn der Anwender sich verklickt, will er schnell den nächsten Knoten rechts klicken. folgt das Kontextmenü direkt der Maus, könnte es im schlechtesten Falle eine ganze Reihe von Knoten verdecken. der Anwender kommt an die Knoten dann vllt nicht ran mit der mAus und müsste dann erst das Kontextmenü schließen. die Positionierung auf den rechten Treeviewrand verhindert dies
Die Y-Position folgt der Maus, also die linke obere Ecke wird auf Höhe der Mausposition angeordnet. Wie ich eben festgestellt habe, geht dies aber auch ohne Übergabe und Umrechnung der Y-Koordinate. Wenn ich bei ShowPopup den y-Parameter einfach weg lasse passiert das auch ohne meinen Umweg.

Bedauerlich, das manches unter Access/VBA so umständlich ist. Ich hab kürzlich angefangen, mich ein wenig in VB 2010 einzuarbeiten. Da gibt es Methoden, um solche Werte direkt zu holen.

Ich verstehe hier nicht, was Du mit 'Kleinem Dienstweg' etc meinst.

In meinem Beispiel ging es mir ja nur um die Positionierung des Kontextmenüs. Dazu bedarf es ja nur der XY-Position der Maus.
In meiner Anwendung hab ich das nun schon nachgerüstet, da es für die Weiterverarbeitung der Daten notwendig ist.