|
![]() |
#1 |
Участник
|
X++: How to use X++ Delegates in Dynamics AX 2012
Источник: http://blogs.msdn.com/b/x/archive/20...s-ax-2012.aspx
============== In this post I want to cover some of the core functional aspects of the new delegates feature introduced in AX 2012. X++ delegates expose the publisher -subscriber pattern where a delegate defines a clear contract in a publisher class. This contract is used when an event occurs where the event can be a change of state, where all interested classes receive notification that the event has occurred. The delegate contract. The class that contains the delegate as a member is called a publisher class. A delegate must be defined on a class by using the right-click context menu ‘New > Delegate’ and it is important to mention there is no support for delegates on other AOT artifacts, just classes. ![]() A delegate never returns a value. A delegate is always a protected member of the class. The delegate can be invoked only by instance members of the class or derived classes. Here is a declaration of a delegate: X++: delegate void notifyChange(utcDateTime _dateTime,str _changeDescription) { } X++: public void callNotifyChange(utcDateTime _dateTime,str _changeDescription) { this.notifyChange(_dateTime, _changeDescription); } A delegate cannot be overridden in derived classes. Interfaces cannot have delegates. Whenever a new event handler is subscribed into a delegate in the AOT, the metadata associated with the delegate changes. These metadata changes require that the delegate be recompiled. Event Handlers. Methods that subscribe to an X++ delegate are called event handlers. An event handler can be written in two formats:
In the AOT, a method can be subscribed to a delegate by dragging the method onto the delegate. The subscribed event handler method must meet the following criteria:
X++: public static void notifyMe(utcDateTime _dateTime,str _changeDescription) { info("A notification has occurred at:" + DateTimeUtil::toStr(_dateTime) + "Message:" + _changeDescription); } ![]() The Properties window shows the name of the publisher class that owns the method that has become an event handler. The name of the method is also shown. The name of the delegate itself was manually changed to the more meaningful SubscriberOneNotify. The most interesting property is ‘EventHandlerType’. Its two possible values are:
Add an event handler programmatically in X++. Event handlers can be subscribed to a delegate during run time by X++ code. Consider a second subscriber class that is named SubscriberTwoClass. This class has to public methods, but only one is static: X++: public static void notifyStatic(utcDateTime _dateTime, str _changeDescription) { info("A notification has occurred calling static handler:" + DateTimeUtil::toStr(_dateTime) + " Message:" + _changeDescription); } X++: static void AddAndClassHandlers(Args _args) { PublisherClass publisher; SubscriberTwoClass subscriber; publisher = new PublisherClass(); subscriber = new SubscriberTwoClass(); publisher.notifyChange [B]+= eventhandler[/B]( SubscriberTwoClass::notifyStatic ); publisher.notifyChange [B]+= eventhandler[/B]( subscriber.notifyInstance ); publisher.callNotifyChange(DateTimeUtil::utcNow(),"Call handlers test"); } The -= operator over the eventHandler keyword can be as well utilized to remove event handlers previously added. Event handlers in the AOT cannot be removed using this approach at run time. When the publisher object eventually goes out of scope, the X++ runtime releases the references to all the subscriber objects, so their resources can be reclaimed for the system. Publisher and subscriber objects must run on the same tier. The delegate infrastructure does not allow making calls cross tiers. For example, if the publisher object which owns the delegate is running on the client, the event handler method cannot be marked as RunOn server. This system design decision was made because calls across tier boundaries are resource intensive. If an application needs cross-tier transitioning, it can be achieved by using regular X++ method invocation. The application logic would need to encapsulate the behavior. SysXppEvent and SysXppEventHandler classes. Dynamics AX 2012 has two new classes that are instantiated whenever event handlers are called by a delegate: SysXppEvent and SysXppEventHandler. The names of these classes can be seen in some debugging scenarios, as is shown in the following image. ![]() As with any other system X++ classes, it is strongly recommended that you neither update nor extend these two classes. Making any change to these classes could cause faulty behavior in the infrastructure that processes delegates, now or in the future. Источник: http://blogs.msdn.com/b/x/archive/20...s-ax-2012.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. Последний раз редактировалось mazzy; 05.11.2013 в 17:11. |
|
|
|