Comments on: If You Use OnUpdate, Your Code Must Be Perfect

By: Alister Christie

Alister Christie — Tue, 06 May 2008 22:29:24 +0000

I somewhat share your concern for OnUpdate events and they have annoyed me within the Delphi IDE when they go wrong - they are however very convenient. An OnUpdate event with a couple lines of code that enables or disables a button(s) can replace a whole bunch of annoying code that needs to be called from numerous places. In this they are a great way of simplifying code, however when they do go wrong it can be very nasty.

By: Michael Skachkov

Michael Skachkov — Tue, 06 May 2008 07:46:42 +0000

2 cents:

if you want to simulate radiobuttons behavior with menu items, then you will have to use OnUpdate handlers for actions linked to that items. this is because AutoCheck, Checked and GroupIndex properties are not synchronized between themselves (I mean all at the same time). Thus you may have situation when user selects one menu item twice and all items are unchecked. there is no elegant way of controlling that (smth. like AllowAllUp property would be very appreciated). the only way is to write OnUpdate handlers.

By: Xepol

Xepol — Mon, 05 May 2008 18:11:51 +0000

I get those a LOT out of the IDE. The problem is similar to OnClose in TForm. You really need to catch any exceptions you might raise and handle them or you can never seem to get any further.

By: stanleyxu

stanleyxu — Mon, 05 May 2008 17:16:29 +0000

Even you do not use OnUpdate, it will consume your CPU usage.
http://stanleyxu2005.blogspot.com/2008/01/performance-issue-of-taction.html

By: David Novo

David Novo — Mon, 05 May 2008 15:50:57 +0000

Why single OnUpdate out for this…. Many things suffer the same problem…

OnPaint
OnMouseMove (in general, its impossible to get out of this without moving the mouse and triggering the A/V)

OnUpdate is usually smarter than the help makes them seem to be. For instance, onUpdate of actions attached to menu items are only triggered if the menu items are visible.