Apr 27, 2011
Filed under: #daxmusings #bizapps

With the introduction of events in AX2012, a slew of possibilities has opened up. At the technical conference in January 2011, Peter Villadsen first unveiled the power of the new functionality. In conjunction with that, I had prepared a lab exercise which was available at the conference. I am working on preparing a new lab document, which I will post here on my blog, which is largely based on the original tech conference document, but with more detail and showing every possibility (the tech conference lab was limited to 1 hour of work, so some features were not explicitly shown).

Before I start posting these labs here, I would like to point out a few VERY important things that I feel the AX developer community should be aware of.

1) The pre/post handlers are a powerful concept, but one needs to be aware of its limitations. The power lies mostly in the ability to add behavior without modifying, and the power to apply/install multiple solutions together without the need to merge (think AxModels, or even traditional XPOs). However:

• when subscribing a handler, the subscription has a “name” property, which should ALWAYS be changed to a meaningful yet unique name. Failure to do so immediately eliminates the power of installing models without merging, since now you have two subscriptions titled “EventHandler1” and one will overwrite the other.
• when changing return values in a post-handler, be aware you may not be the last handler to do so. When changing the value of a validateField(), only change it to FALSE if you have a reason to do so, otherwise, leave the return value alone. In other less obvious cases, be aware of the limitations and potential other code impacting the return value.
• same goes for pre-handlers and changing arguments to the original method!

2) Managed handlers are powerful, but have their limitations. I will go into this in my lab posts, but there are limitations in what you can and cannot do, and what you should and should not do. Remember any data manipulation you do from managed code will have to cross the boundary again and could impact your code’s performance.

3) When creating delegates, look at best practices for C# delegates. Arguments should be the sender object, and a class, Extending XppEventArgs base class, containing all the variables you wish to pass. This will ensure that the API your delegate provides will never get broken. If you ever wish to add more data, you would add it to the class, without breaking any delegate subscriptions depending on your delegate method’s signature.

As far as delegates and events go, please review C# best practices for naming conventions (eg “InvoicePosting”, “InvoicePosted” as delegates, and the subscribers should be “InvoicePostingEventHandler” and “InvoicePostedEventHandler”).

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!