Hallo,

ich habe im "DataModuleActionsUndMenus" eine ActionList angelegt. Darin befinden sich beispielsweise folgende drei Actions:
- Action_HM_Datei_Kategorisieren
- Action_HM_Datei_Beenden
- Action_HM_Film_Suchen
...

In "FormTsKatalog" liegt eine "TMainMenue"-Komponente, mit den Menüeinträgen
- Datei
- Kategorisieren
- Beenden
- Film
...

Die ActionList lag zuvor im "FormTsKatalog". Ihre Actions sind so geschrieben, dass sie vom "OnClick"-Event des Hauptmenüs direkt aufgerufen werden können.
Ich also im OI von "Datei-Beenden" unter "OnClick" "Action_HM_Datei_BeendenExecute" eintragen bzw. auswählen(!) konnte.

Nun lege ich aber meine Actions deshalb an, weil ich deren Code nicht an mehreren Stellen im Programm stehen haben will, sondern nur deren Aufruf.
(Ist halt so beim OO Programmieren)

Also tat ich mir die Arbeit an und "verschob" die TActionList in ein DataModule.

Jetzt, wo alles fertig ist, stelle ich zum wiederholten Male fest, dass es mir nicht gelingen will, im OI von "Datei-Beenden" unter "OnClick" des Menüeintrages "HM_Datei_Beenden" im "FormTsKatalog"
die Aktion "Action_HM_Datei_BeendenExecute" zuzuweisen.
Dies gelingt nur über den Umweg, einen Doppelklick im OI zu machen und der Methode "HM_Datei_BeendenOnClick" den Aufruf "Action_HM_Datei_BeendenExecute(Sender);" einzufügen.

Frage:
Ist das wirklich so? also Muss das so sein?
Oder gibt es da irgendwie eine Abkürzung?

Du hast den Code er Actions mit umgezogen und das Datenmodul per "uses" in Deinem Hauptformular aufgenommen?

Und wieso willst du dem OnClick-Event etwas zuweisen?

Bei Actions weist man z.B. dem Menü-Item einfach die passende Action zu und gut ist.

Ja, ich habe den Code mit umgezogen.
Gehören denn die Action und das ActionExecute nicht zusammen?


Wenn ich nur die passende Action zuweise, dann tut diese nachher nichts, wenn sie etwas tun soll.
Woher sollte sie auch wissen, bei welchem der Events (das sind beim Menü immerhin vier Stück) sie sich angesprochen fühlen soll?

Ja eine Action hat eine ActionExecute-Methode, da steht drin, was beim Auslösen der Action passieren soll.

Ein MenuItem hat eine Action-Eigenschaft, wo festgelegt werden kann, welche Action ausgelöst werden soll, wenn der Menüpunkt angeklickt wird (geht auch bei einem Button und vielen anderen Controls).

Wenn du nur die Methoden zuweisen willst, wofür nimmst du denn dann überhaupt die Actions? Damit du per Doppelklick einen Methodenrumpf bekommst?

Der Vorteil von Actions ist doch, dass hier von den Actions einige Eigenschaften übernommen werden (Caption, Enabled, Selected) und dieses dann an mehrere Controls dranklatschen kann.

"Der Herr noch einen Button zum Drucken?" - Button hin, Action zum Drucken dran, fertig

Zitat von Sir Rufo:

Ja eine Action hat eine ActionExecute-Methode, da steht drin, was beim Auslösen der Action passieren soll.

Soweit ist das klar.

Zitat von Sir Rufo:

Ein MenuItem hat eine Action-Eigenschaft, wo festgelegt werden kann, welche Action ausgelöst werden soll, wenn der Menüpunkt angeklickt wird (geht auch bei einem Button und vielen anderen Controls).

Da ist mir etwas unklar: Woher weiß das Kontrollelement (MenuItem, Button, ...) dass genau diese Action ausgeführt werden soll, wenn ich das Ding anklicke.
Und was mache ich, wenn ich eine Action für die zu erledigende Arbeit beim klicken und eine andere Action für die zu erledigende Arbeit beim "drüber hovern" habe?

Zitat von Sir Rufo:

"Der Herr noch einen Button zum Drucken?" - Button hin, Action zum Drucken dran, fertig

Das wiederum ist klar. Genau deshalb nehme ich die Actions.
Und natürlich auch deshalb, weil ich denen so ein schickes Bildchen zuweisen kann, einen Shurtcut, eine Caption, und sie so bequem En- und disablen kann mit allen dazugehörenden Konsequenzen.

Zitat von Glühwürmchen:

Nun lege ich aber meine Actions deshalb an, weil ich deren Code nicht an mehreren Stellen im Programm stehen haben will, sondern nur deren Aufruf.
(Ist halt so beim OO Programmieren)

Also tat ich mir die Arbeit an und "verschob" die TActionList in ein DataModule.

Actionlists sind der "Klebstoff" zwischen Buttons & Menuitems und Events.
Man kann zwar Actionlists auf ein Datenmodul legen aber das ist nicht der richtige Weg.
Eigentlich müsste man verhindern dass man Actionlists auf etwas anderes als Form und Frames legen kann...

Zitat von sx2008:

Actionlists sind der "Klebstoff" zwischen Buttons & Menuitems und Events.
Man kann zwar Actionlists auf ein Datenmodul legen aber das ist nicht der richtige Weg.
Eigentlich müsste man verhindern dass man Actionlists auf etwas anderes als Form und Frames legen kann...

Das sehe ich anders. Wenn man die Funktionen im Datamodule hat, kann man z.B. für das Programm unterschiedliche Oberflächen verwenden. Du kannst dann die Actions einfach an eine andere Oberfläche binden. Darüber hinaus kann ich den Source-Code aus dem Actionmodule auch für mobile Anwendungen verwenden (die ja i.d.R. andere Formen als die Desktop-Anwendungen haben). Und Nachteile für diesen Weg sind mir keine bekannt.

Zitat von Harry Stahl:

Wenn man die Funktionen im Datamodule hat, kann man z.B. für das Programm unterschiedliche Oberflächen verwenden

Dann stell dir einfach mal vor du würdest das Datenmodul aus einer Konsolenanwendung heraus anwenden.
In diesem Fall merkt man nämlich dass eine Actionlist oder gar ein Actionmanager keine universelle API darstellt sondern in die Welt der Benutzeroberflächen gehört.

Oder anderst formuliert:
Angenommen man hat eine VCL-Anwendung und man möchte daraus zusätzlich eine Konsolenanwendung und einen Dienst der nur über TCP/IP kommuniziert ableiten.
Man würde also die Businesslogik extrahieren und in einen eigenen Namespace legen und getrennt von den 3 Anwendungarten aufbewahren.
Datenmodule gehören zur Businesslogik (bzw. zur Datenzugriffsschicht).
Aber die Actions, ActionLists und ActionManager müsste man entfernen denn schließlich sind diese Klassen in dem Namespace "Vcl.ActnList" bzw. "Vcl.ActnMan".

Man kann auch das Model-View-Controller Entwurfsmuster heranziehen.
Wohin gehören die ActionLists?
Ich würde sagen weder ins Modell noch in die View sondern ActionLists nehmen die Aufgaben von Controllern wahr.
Die ganze Architektur der VCL ist so aufgebaut, dass Delphi Steuerelemente gleichzeitig View- und Controller-Aufgaben wahrnehmen.
Ein Delphi Formular vereinigt sowohl View als auch Controller in sich, daher sind Actionlists auf dem Formular am Besten aufgehoben.

Hm, nachdem ich mir Euer beider Argumente durchgelesen habe, neige ich dazu, Euch beiden Recht zu geben:

Der Grund, warum ich überhaupt auf die Idee kam, die Actionlist in das Datenmodule zu legen, war, dass ich deren Actions dann auf allen Formularen in der Anwendung verwenden kann, ohne immer die jeweiligie Unit in die USES-Klausel aufnehmen zu müssen.
Also angenommen, ich habe 20 Formulare und auf jeder liegt eine ActionList. Und dann baue ich ein 21. Formular zusammen, das Elemente jeden anderen Formulars in sich vereinigt (die Sinnhaftigkeit dessen sei jetzt mal dahingestellt), dann müsste ich im einen Fall 20 Units in die USES-Klausel packen und im anderen Fall nur das Datamodule.

Andererseits habe ich jedoch weiter oben beschrieben, dass ich, liegt die Actionlist auf dem Formular, wo deren Actions gebraucht werden, für jedes Ereignis einer Komponente eine eigene Action zuweisen kann, während ich in Dem Fall, dass die Actionlist im Datamodule liegt, nur das jeweilige Standardevent mit einer Action belegen kann und für die anderen Events einen Umweg laufen muss.
Darüber hinaus muss der Delphianer noch wissen, welches denn nun das Standardevent einer Komponente ist.

Das Standardevent eines Buttons oder eines MenuItems mag ja noch eindeutig sein. Aber was ist das Standardevent eines Panels oder eines Formulars?


Darf ich noch einmal an die Frage erinneren, welchen Vorteil die Verwendung des wesentlich komplizierter ercheinenenden AchtionManagers, der ja seine eigene Actionlist mitbringt, gegennüber der Verwendung einer einfachen Actionlist hat?