AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.10.2007, 04:49   #1  
Blog bot is offline
Blog bot
Участник
 
25,640 / 848 (80) +++++++
Регистрация: 28.10.2006
Inside Dynamics AX 4.0: RunBase Framework Extension Part IV
Источник: http://feeds.feedburner.com/~r/Insid...n-part-iv.html
==============

Continue from Part III

Adding Constructors

As mentioned earlier in this chapter, X++ does not support method name overloading, and you should avoid using default parameters on constructors. You must create individually named new methods with different parameter profiles instead.

In the preceding example, you created an instance of the class and set the necessary parameters. Imagine that there is one more parameter in your class that indicates a certain customer account number for creating bike offers. Add a new member variable to the class declaration, and then add the new parameter method, like this.

Suppose that the customer record contained information about the option to create service orders with bike offers. For example, imagine that offers are not sent to the customer if the customer has been stopped for new transactions. Because you want to avoid using default parameters in the construct method, you must call both of these parm methods when you create an instance based on a customer record.
This code is a good candidate for the static new pattern, so implement a static newCustTable method on the BikeTuningOffers class to create an instance based on a customer record, as shown here.
Now change your job to a simpler version to be assured that the class gets properly instantiated and initialized.
Adding a Query
Adding a query to the business operation class allows the user to select a range of targets to apply the operation to, such as sending bike-tuning offers to selected customers. To use the query, you must be able to create an instance of QueryRun. Start by adding QueryRun as a member variable, as shown here.


To initialize the QueryRun object, override the initParmDefault method, as shown in the following code. This method is called by the RunBase framework if no saved object state is found by the SysLastValue framework via the unpack method.
You must modify the pack method, as shown in the following example, so that you can save the state of the QueryRun object.
Consequently, you must also modify the unpack method to reinstantiate the QueryRun object, as shown here.
To make the QueryRun object available for presentation in the dialog box, override the queryRun method to return your QueryRun object, as shown in the following code.

To actually show the query in the dialog box, you must override the showQueryValues method to return the value true, as follows.

If you open the class now, you can see that the query is embedded in the dialog box, as shown in below image.

The Create Bike-Tuning Offers dialog box with an embedded query

Finally, you must change your business logic method, sendOffers, so that it uses the QueryRun object, as shown here.
Client/Server Considerations


Typically, you will want to execute business operation jobs on the server tier, because these jobs almost always involve several database transactions. However, you want the user dialog box to be executed on the client to minimize client/server calls from the server tier. Fortunately, the RunBase framework can help you run the dialog box on the client and the business operation on the server tier.


To run the business operation job on the server and push the dialog box to the client, you should be aware of two settings. On the menu item that calls the job, ypou must set the RunOn property to Server; on the class, you must set the RunOn property to Called from. In below image shows where to set the RunOn property of a class.

The execution tier of the class set to Called from.



When the job is initiated, it starts on the server, and the RunBase framework packs the internal member variables and creates a new instance on the client, which then unpacks the internal member variables and runs the dialog box. When the user clicks OK in the dialog box, RunBase packs the internal member variables of the client instance and unpacks them again in the server instance.

Related Articles
RunBase Framework Extension Part I
RunBase Framework Extension Part II
RunBase Framework Extension Part III
</img> </img> </img> </img> </img>


Источник: http://feeds.feedburner.com/~r/Insid...n-part-iv.html
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Inside Dynamics AX 4.0: The Security Framework Blog bot DAX Blogs 0 31.10.2007 11:40
Inside Dynamics AX 4.0: RunBase Framework Extension Part III Blog bot DAX Blogs 0 02.10.2007 04:49
Inside Dynamics AX 4.0: RunBase Framework Extension Part I Blog bot DAX Blogs 0 30.09.2007 09:20
Inside Dynamics AX 4.0: Wizard Framework Extension Part II Blog bot DAX Blogs 0 29.09.2007 19:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:25.