Korreekte Verwendung TActionList.OnUpdate / TAction.OnUpdate

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

[Uwe Raabe]

Zitat von BerndS:

In welcher Form könnte sich das negativ auswirken?

Das UpdateAction wird ja zyklisch aufgerufen. Insofern kann sich in manchen Fällen z.B. die Enabled-Bedingung der Action zwischen dem letzten UpdateAction und dem Execute-Aufruf geändert haben. Der Update-Aufruf im Execute würde das erkennen und entsprechend agieren.

Zitat von BerndS:

Was mir aufgefallen ist, das Actions, denen kein OnExecute zugewiesen ist, automatisch auf Enabled := False gesetzt wird.

Dafür gibt es bei der Action die Eigenschaft DisableIfNoHandler, die per Default auf True steht.

Zitat von BerndS:

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

UpdateActions wird von zwei Stellen aufgerufen: Aus einem ActionMenu im Zusammenhang mit einem ActionManager und im TApplication.DoActionIdle. Letzteres wird im TApplication.Idle aufgerufen wenn Done = True ist oder in einem Timer-Event wenn mit ActionUpdateDelay > 0 die Update-Frequenz gedrosselt wird (das ist z.B. bei MDI-Anwendungen notwendig). Somit geschieht das in der Regel dann, wenn die Applikation gerade nichts besseres zu tun hat.

Zwischen einem UpdateAction und dem Action-Execute liegt also immer eine zeitliche Lücke. Wenn dann noch mit Application.ProcessMessages hantiert wird, sind sporadische Merkwürdigkeiten kaum noch vermeidbar.

[BerndS]

DisableIfNoHandler kannte ich noch nicht. Es ist leider nicht published. Daher habe ich den Actions, die z.B. nur ein Submenü zugewiesen sind immer eine leere OnExecute zugewiesen. DisableIfNoHandler im Quelltext auf False wäre nun auch eine Option, aber das per OI setzen zu könnnen, wäre schon wünschenswert.

Zitat:

Zwischen einem UpdateAction und dem Action-Execute liegt also immer eine zeitliche Lücke. Wenn dann noch mit Application.ProcessMessages hantiert wird, sind sporadische Merkwürdigkeiten kaum noch vermeidbar.

Im UpdateAction soll doch lediglich Enabled und oder Visible der Action verändert werden. Das Execute würde doch erst erfolgen, wenn ich ein zugewiesenes Control (Button, Menü usw. anklicke / drücke)
Application.ProcessMessages wird hier nicht aufgerufen.

[Uwe Raabe]

Es kann ja durchaus sein, dass es in deiner Anwendung nicht relevant ist.