In Form1 auf eine in DataModul definierte TAction zugreifen

[Glühwürmchen]

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?

[Bummi]

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

[Sir Rufo]

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.

[Glühwürmchen]

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?

[Sir Rufo]

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

[Glühwürmchen]

Zitat:

Zitat von Sir Rufo (Beitrag 1270167)

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

Soweit ist das klar.

Zitat:

Zitat von Sir Rufo (Beitrag 1270167)

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:

Zitat von Sir Rufo (Beitrag 1270167)

"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.

[Sir Rufo]

Zitat:

Zitat von Glühwürmchen (Beitrag 1270174)

Zitat:

Zitat von Sir Rufo (Beitrag 1270167)

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?

Hmmm, du weißt was Actions sind und wie man die benutzt und dann diese Frage? :gruebel:

So ein Control hat eine Standard-Aktion (Button->Click, MenüItem->Click) und diese Standard-Aktion kann man mit einer Action belegen. Alles weitere muss man "per Hand" dazubauen.

[Glühwürmchen]

Zitat:

Zitat von Sir Rufo (Beitrag 1270176)

Hmmm, du weißt was Actions sind und wie man die benutzt und dann diese Frage? :gruebel:

:lol:
Alles autodidaktisch gelernt. Da bleibt zwischendurch was auf der Strecke...

Ich habe da jetzt ein bisschen rum experimentiert und herausgefunden, warum die Actions einfach nicht tun wollten.
Wenn ich die Actionlist in dem Formular habe, in dem ich die Actions benutzen will,
dann kann ich im OI dem gewünschten OnClick-Event eines Panels die ActionExecute-Methode direkt zuweisen.

Liegt die ActionList aber in einem anderen Formular, dann kann ich im OI dem gewünschten Panel nur die Action zuweisen, ohne sie gezielt an ein bestimmtes Event dranzunähen.
Das habe ich getan und dann ging es nicht.
Der Grund: Ich muss dann im Eventteil des OI die Action aufklappen und dem "OnExecute"-Event die ActionExecute-Methode noch mal extra zuweisen. Tue ich das, dann klappt es auch mit dem Nachbarn.

Frage beantwortet:
Nächste Frage:
Welchen Vorteil bietet mir in diesem Zusammenhang die ActionManager-Limousine gegenüber dem ActionList-Tretroller?

[sx2008]

Zitat:

Zitat von Glühwürmchen (Beitrag 1270126)

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...

[Harry Stahl]

Zitat:

Zitat von sx2008 (Beitrag 1270287)

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.

[sx2008]

Zitat:

Zitat von Harry Stahl (Beitrag 1270289)

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.

[Glühwürmchen]

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? :?:

[Jumpy]

Keine Antwort zu der ActionManager-Frage, dafür noch eine (unausgegorene) Idee bzgl. Action auf Datamodul statt auf Formular. Wie ist es denn, wenn man die Action auf ein Basisformular packt, von dem alle anderen Formulare erben. Kann man die Actionlist dann benutzen?

[Glühwürmchen]

Vererbung!

Das ist eine gute, gangbare und ziemlich flexible Lösung.
Vielen Dank für den Tip.

[Dejan Vu]

Zitat:

Zitat von Glühwürmchen (Beitrag 1270714)

Vererbung!

Hmm. Ich habe eine Action 'Kundeninfo als Popup anzeigen'. Die habe ich im Hauptmenü als stinknormalen Menüpunkt, aber auch als Button in diversen Formularen in der Adresspflege, Auftragsannahme, Dispo etc. Welches Basisformular wäre das? ;-) Ich werde ja wohl kaum mein Hauptformular und meine Dispomaske von ein und demselben Formular ableiten und dort sämtliche Actionlisten, Imagelisten etc. platzieren, nur damit man die zentral verteilen kann. Igitt. Kann man in einer Desktopanwendung ruhig so machen, aber wenn die Projekte größer werden und oder sich auf verschieden Exen verteilen, wird das doch sehr häßlich.

Was spricht dagegen, diese Aktionen in einer eigenen Klasse zu verwalten? Wäre das nicht viel sauberer? Eine Action ist ja schließlich unsichtbar, hat also eigentlich nichts auf einem Formular zu suchen, denn im Formular sollten nur die sichtbare Komponenten liegen.

Also eine Actions-Klasse (TCustomerActions) wäre ziemlich fein. Diese Klasse verwaltet alle Aktionen, die ich mit einem Kunden so anstellen kann, sowie die Tooltips, Icons und sonstigen Schnickschnack. So, und wenn ich schon Komponenten hin und her schubse, dann packe ich sie mir eben in ein TDataModule, was eben mein visueller Container für meine CustomerActions ist. Vielleicht packe ich mir in die TCustomerDatamodule auch gleich meine Imagelist mit den Icons und meinen TsiLang-Übersetzer, der mir das alles multilingual macht. Klasse! Alles an einem Ort.

Das tolle ist ja, das so eine Action vielleicht auch etwas nichtvisuelles anstellt, z.B. die Kundendaten direkt auf den Drucker schicken. Dann kann ich das sogar vom Code an beliebiger Stelle machen, ohne in einer Unit plötzlich ein 'uses MainForm' machen zu müssen. Das verstößt ja gegen jeden Ordnungssinn.

Ich finde 'TDatamodule' ist ein unglücklicher Name für einen Container, der für die unsichtbaren Komponenten zuständig ist (TContainer fände ich besser). Ich kann so einen Container als Datenbanklayer bzw. Teil davon ansehen (eben eine Art Datamodule), oder als Actioncontainer, oder als Sammelsurium sonstiger Dinge, die konzeptionell zusammen gehören, und für die es eine Komponente gibt.

Ich habe z.B. die gesammte TCP/IP-Kommunikationslogik mit einem TCP-Server in einem Datenmodul drin. Was so ein Teil auf einem Formular zu suchen hat, frage ich mich bis heute. Cool. Das ist sogar komplett wiederverwendbar, was bei Plazierung auf meinem Formular nicht gegeben ist.

DevExpress bietet Templates für ihr Editoren an, damit steuert man das komplette Verhalten eines Eingabefeldes. Das packe ich mir in meinen TEditorTemplateContainer (was ein TDataModule ist), programmiere das durch und flansche es dort an, wo ich es benötige.

Die Zuweisung im OI mag an mancher Stelle etwas mühselig sein, vor allen Dingen, wenn man das Formular lädt, ohne das vorher der Container geladen ist (dann verschwinden die Verknüpfungen blöderweise). Aber ich habe mir angewöhnt, diese Verknüpfungen im Code eh explizit zu setzen, meist im FormCreate.

Das nur mal so als Anregung.