Korreekte Verwendung TActionList.OnUpdate / TAction.OnUpdate

[BigAl]

Hallo zusammen,

ich hoffe ich bin mit dem Thema hier richtig. Die Actions betreffen ja im Wesentlich die Controls GUI (Controls).

Ich habe eine grundsätzlich Frage zu den Actions bzw. wie implementiert ihr üblicherweise das OnUpdate. Bisher habe ich die Verwaltung der Zustände der Aktionen immer in die zentrale TActionList.OnUpdate verfrachtet. Also:

Delphi-Quellcode:

procedure TfrmSomething.ActionListUpdate(Action: TBasicAction; var Handled: Boolean);
begin
  aAction1.Enabled := ...;
  aAction2.Enabled := ...;
  usw.

  Handled := True;
end;

Das müsste aber kontraproduktiv zu sein, da das OnUpdate wohl für jede Aktion einmal aufgerufen wird. Eine Alternative wäre:

Delphi-Quellcode:

procedure TfrmSomething.ActionListUpdate(Action: TBasicAction; var Handled: Boolean);
begin
  if Action = aAction1 then
    aAction1.Enabled := ...
  else if Action = aAction2 then
    aAction2.Enabled := ...
  usw.

  Handled := True;
end;

Das ist aber auch irgendwie umständlich bzw. macht den Code unübersichtlich. Die dritte Alternative wäre das TActionList.OnUpdate nicht zu verwenden und stattdessen die Zustandsverwaltung mit TAction.OnUpdate jeder Aktion selbst zu überlassen. Macht das ganze aber noch unübersichtlicher.

Ich mache das seit jeher wie ganz am Anfang gezeigt. Performance-Probleme hatte ich da noch nie, da die Boolschen Zustände die ich zum Aktivieren bzw. Deaktivieren der Aktionen verwende alle bereits vorliegen und nicht im OnUpdate erst ermittelt bzw. berechnet werden.

Um zum Anfang zurück zu kommen: Wie macht ihr das normalerweise? Ich suche da nach einer "Best Practice". Man will ja keine Rechenzeit / Energie verschwenden .

Alex

[BerndS]

Hallo,
ich verwende dafür immer TForm.UpdateActions. Dazu überschreibe ich es und setze dort die Actions entsprechend.

Delphi-Quellcode:

    
TMyForm = class(TForm)
public
  procedure UpdateActions; override;
end;

Delphi-Quellcode:

procedure TMyForm.UpdateActions;
begin
  inherited;
  aAction1.Enabled := ...;
  aAction2.Enabled := ...;
  usw.
end;

[BigAl]

Zitat von BerndS:

Hallo,
ich verwende dafür immer TForm.UpdateActions. Dazu überschreibe ich es und setze dort die Actions entsprechend.
[/DELPHI]

Muss ich mir mal anschauen wann das aufgerufen wird. Scheint aber vom Ansatz die bessere Lösung zu sein .

[Uwe Raabe]

Zitat von BerndS:

ich verwende dafür immer TForm.UpdateActions.

Das impliziert aber, dass die Actions im Form liegen und nicht z.B. zentral in einem Datenmodul, wo sie Controls aus mehreren Forms oder Frames referenziert werden.

Als weiteres wird der Update-Aufruf innerhalb von TCustomAction.Execute damit funktionslos.

Zitat von BigAl:

Die dritte Alternative wäre das TActionList.OnUpdate nicht zu verwenden und stattdessen die Zustandsverwaltung mit TAction.OnUpdate jeder Aktion selbst zu überlassen. Macht das ganze aber noch unübersichtlicher.

Ist wohl Geschmackssache. Ich finde das eigentlich ganz gut wenn die Action autark ist. Man muss halt darauf achten, die Bedingungen nicht on-the-fly zu ermitteln, sondern als Status zu verwalten.

[BerndS]

Wo die Actions liegen sollte doch keine Rolle spielen. Es ist ja trotzdem möglich auf das Datenmodul zuzugreifen. Aber man sollte im Form nur die Actions ansprechen, die hier auch eingebunden bzw. verknüpft sind.

[BigAl]

[QUOTE=Uwe Raabe;1510617]

Zitat von BerndS:

Ist wohl Geschmackssache. Ich finde das eigentlich ganz gut wenn die Action autark ist. Man muss halt darauf achten, die Bedingungen nicht on-the-fly zu ermitteln, sondern als Status zu verwalten.

Darum auch die Frage "wie macht ihr das". Ich suche halt nach einer effizienteren Lösung. Zentrale Actions habe ich eigentlich so gut wie nie. Mit der "übergreifenden" Lösung hatte in der Vergangenheit des Öfteren Probleme, da beim Öffnen der IDE da immer mal wieder Fehlermeldungen kamen bzw. die Bezüge einfach kommentarlos gelöscht wurden. Ich hatte mal mit zentralen Image-Listen gearbeitet. Doch plötzlich hatte ich dann Applikationen ausgeliefert, bei denen die Images in verschiedenen Formularen fehlten. Ich habe dann wieder auf lokale Image-Listen umgestellt...

[Uwe Raabe]

Zitat von BigAl:

Ich habe dann wieder auf lokale Image-Listen umgestellt...

Was in Zeiten von High-DPI sowieso wieder zur Norm werden wird - allerdings aus anderen Gründen.

Das Problem mit den verschwindenden Links in den DFMs ist leider ärgerlich, taucht aber nach meinem Gefühl nur noch gelegentlich bei tiefen Form-Vererbungs-Hierarchien auf. Ich löse das dann durch gezielte Zuweisungen im Source-Code. Das erlaubt weiterhin die zentrale Verwaltung der Actions in Datenmodulen.

[BigAl]

Zitat von Uwe Raabe:

Zitat von BigAl:

Ich habe dann wieder auf lokale Image-Listen umgestellt...

Was in Zeiten von High-DPI sowieso wieder zur Norm werden wird - allerdings aus anderen Gründen.

Das Problem mit den verschwindenden Links in den DFMs ist leider ärgerlich, taucht aber nach meinem Gefühl nur noch gelegentlich bei tiefen Form-Vererbungs-Hierarchien auf. Ich löse das dann durch gezielte Zuweisungen im Source-Code. Das erlaubt weiterhin die zentrale Verwaltung der Actions in Datenmodulen.

Hallo Uwe,

ja, das mit der Vererbung von Forms ist in meinen Applikationen leider an der Tagesordnung. Sämtliche forms (Formulare, Dialoge und Frames) basieren bei mir auf einer zentralen Basis, da diese immer eine Grundfunktionalität mitbringen müssen (dynamisch Sprachumschaltung etc.). Ich gebe Dir aber recht, dass die IDE und vor allem der LSP mittlerweile damit besser zurecht kommen. Wobei der LSP immer noch das Problem hat, dass neue Units (egal ob normale Unit oder VCL Form etc.) erst nach einem Neustart der IDE vom LSP berücksichtigt werden (dafür muss ich mal einen eigenen Thread aufmachen, da ich nicht weiß ob das Problem nur bei mir besteht).

Das mit dem gezielten Zuweisen im Source-Code ist auf jeden Fall eine gute Idee...

[Uwe Raabe]

Zitat von BigAl:

Wobei der LSP immer noch das Problem hat, dass neue Units (egal ob normale Unit oder VCL Form etc.) erst nach einem Neustart der IDE vom LSP berücksichtigt werden

Ich habe mir im Tools-Menü einen Eintrag "Kill LSP" angelegt mit Programm="taskkill" und Parameter="/IM DelphiLSP.exe /F" (jeweils ohne die Anführungszeichen). Das einmal anklicken und danach eine (auch redundante) Änderung am Source machen hilft ihm meistens wieder auf die Sprünge.

Aber vielleicht spaltet ein Moderator das hier mal in einen neuen Thread ab...

[BerndS]

Zitat:

Als weiteres wird der Update-Aufruf innerhalb von TCustomAction.Execute damit funktionslos.

In welcher Form könnte sich das negativ auswirken?

Was mir aufgefallen ist, das Actions, denen kein OnExecute zugewiesen ist, automatisch auf Enabled := False gesetzt wird.
Setzt man es trotzdem im UpdateActions auf True, wird das nach wieder auf False gesetzt im UpdateActions wieder auf True.
Es entsteht dann zwar keine Endlosschleife, aber ist z.B. ein Button mit der Action verklüpft, flackert der dann entsprechen.

Ich habe eigendlich angenommen, dass UpdateActions der beste Zeitpunkt ist, die Actions zu setzen. Der Name der Prozedur sagt doch alles.

Man könnte sicher noch ein Property (z.B. DoUpdateActions) im Form hinzufügen, dass UpdateActions mitteilt, dass die Actions gesetzt werden sollen.