Hi Prashant;

  FWIW: I generally consider an EVENT as a "notification" that something has happened. Whereas a FUNCTION is a request for a "Unit of Work". The Trigger or Post of either is only whether you need it performed "now" (before continuing) or "whenever" you get around to it.

  Note that Event methods are exceuted Top Down (Top Ancestor => Descendants), wheres Functions are executed Bottom Up (Descendant => Ancestors). Functions though are always in an "over-ride" state unless you code a SUPER::<name> command.

HTH

Regards ... Chris

Greetings, Prashant -

Interesting question!

The "newer" syntax that uses the EVENT keyword (this was introduced in PB 5, I believe, so the term "newer" is relative, I guess) supports DYNAMIC/STATIC calling, TRIGGER (immediate) or POST (queued) execution, and the ability to supply essentially an unlimited variety and quantity of arguments. I use this syntax almost 100% of the time for consistency, since it pretty much does it all. I'm an advocate for clear and consistent coding techniques, even if it means I have to type a few additional characters in a line of code.

The TriggerEvent & PostEvent PowerScript functions do have the ability to pass argument values, but it is fairly restricted, however. These PowerScript functions also support a couple of features that are useful in special circumstances: 1) There is a DataWindow method for TriggerEvent and for PostEvent, and 2) Both will fail "silently" if the event does not exist in the targeted object. For example, the PFC uses this feature to determine at execution time if the DW control(s) in a window are "PFC" DW's (inherited from u_dw) or not. It accomplishes this via a simple event named "pfc_descendant" in the base PFC DW control that returns the Boolean value True. TriggerEvent will return 1 if the event exists and -1 if it doesn't.

Regards, John