1. Important methodes in runbase and runbase batch class, that u have used and where u have used.

Runbase class ke methods: Jawab unka diyo jo tune sune hon aur unhi ka naam lena Neeche methods ki detail bhi daal rahi hun

Method
cancelTimeOut

Description
Cancels a previous method call to the Object::setTimeOut Method. (Inherited from Object.) Returns false in this class. Controls whether a calledFrom class that is instantiated on the server should have its prompt executed on the client. Returns whether it is possible to pack the class, reinstantiate a new class on the client or server, and unpack the packed class into the new class. Returns the description from the current class by calling the static description method on the class if there is one. Must be called in the RunBase dialog

canGoBatch

canSwapBetweenCS

canSwapBetweenCSPrim

caption

checkCloseDialog

CloseOk

method.

cleanupDialog

Provides a way to clean up after a dialog box has been canceled. Returns a class that contains the methods that are described by the
RunBaseDialogable

dialog

interface. dialogClear dialogInit dialogMake Should clear the contents of the dialog. Initializes the dialog. Obtains the dialog from a RunBase class. Makes it possible to add controls after the main dialog() has been run because this method is called after the dialog method is called. Called right after the RunBase.dialogInit Method. Called after Dialog.run Method. Reinitializes the dialog. When using the dialog class for dialog, this method is called whenever a control is selected. When using the Dialog Class for dialog, this method is called from the task

dialogPost

dialogPostInit

dialogPostRun dialogReInit

dialogSelectCtrl

dialogTask

method in the dialog form. Updates the dialog, for example after reinitializing the query. Updates the query in the dialog. Determines whether the specified object is equal to the current one. (Inherited from Object.) Assigns the dialog values to the internal variables. Gets the last choice that is stored in the last value table. Returns the timer handle for the object. (Inherited from Object.) Retrieves the handle of the class of the object. (Inherited from Object.) Returns true when the GetLast or SaveLast method is executed. Gives RunBase the same profile as, for example, a FormRun class. This method is not used in the standard application. Initializes the internal variables.

dialogUpdate

dialogUpdateQuery

equal

getFromDialog

getLast

getTimeOutTimerHandle

handle

inGetSaveLast

init

initParmDefault initSysSign

isSwappingPrompt isSysSignUsed lastValueDataAreaId lastValueDesignName lastValueElementName lastValueType lastValueUserId

Checks if the program is currently swapping from server to client.

mustLoadSaveQuery

Determines whether the last query must be loaded and saved when you leave the form. Called from SysQueryForm. Returns the name of the RunBase class. Overridden. Initializes a new instance of the RunBase class. Releases the hold on an object that has called a wait method on this object. (Inherited from Object.) Releases a lock on the object that was issued by a wait method on this object. (Inherited from Object.) Determines whether the object is on a server. (Inherited from Object.) Returns the instance that owns the object.

name

new

notify

notifyAll

objectOnServer

owner

(Inherited from Object.) pack Serializes the current instance of the RunBase class. Gets or sets the Progress parameter. Gets or sets the SysSign parameter. Hides the Progress form. Initializes the Progress object in RunBase. Kills the Progress object in RunBase.

parmProgress parmSysSign progressHide

progressInit

progressKill prompt

promptPack

Wraps a call to the RunBase.pack Method when packing in the RunBase.promptPrim Method. Contains the code for the prompt functionality. The RunBase.prompt Method simply wraps this method. Unpacks what the promptPack method has packed. Enables setting the fields that were just added in the RunBase.dialog Method. This method is called from the RunBase.promptPrim

promptPrim

promptUnpack

putToDialog

Method directly following the RunBase.dialogMake Method. queryRun Returns the QueryRun, which is used by the
QueryPrompt.

reset

Resets the class to its default state. Contains the code that does the actual job of the class. Returns the RunBase itself. Saves the last choice by using the RunBase.pack Method. Sets the internal
inGetSaveLast

run

runBase

saveLast

setGetLastCalled

variable. setInPrompt Sets the internal inPrompt variable. Sets the internal isSwappedFromServer variable. Sets up the scheduled execution of a specified method. (Inherited from Object.) Determines whether to add a Clear button to the dialog. If you change the return value to true it will add the button. Determines whether a Default button is to be

setIsSwappedFromServer

setTimeOut

showClearButton

showDefaultButton

added to the dialog. If you change the return value to true, it will add the button. showDialog If this method returns true, it will look for the first enabled index when you are adding query range fields to the dialog and if a data source does not have any ranges specified. It will also show the visible fields from that index.

showIndexFields

showQuerySelectButton Determines whether a Select button is to be added to the dialog. If you change the return value to true, the button will be added.

showQueryValues

sysSignFieldId sysSignTableId sysSignValidateEmployee Returns a string that represents the current object. (Inherited from Object.) Deserializes the packedClass parameter value to an instance of the RunBase class. Returns the current number of references (the value of the reference counter) that

toString

unpack

usageCount

the object has. (Inherited from Object.) validate Validates the state of the internal variables. Pauses a process. (Inherited from Object.) Returns an XML string that represents the current object. (Inherited from Object.) Gets the description of the class. Returns a description of the specified class. Returns the Help text from the class with the specified classId. Returns the version number from a container with a packed class. Instantiates a RunBase class with the specified class ID. Instantiates a RunBase class on the client. Instantiates the RunBase class on the server. Creates a RunBase on the client, unpacks the packed container, runs prompt, and returns the status from prompt, as well as the

wait

xml

::description ::getDescription

::getHelpText

::getVersion

::makeObject

::makeObjectOnClient

::makeObjectOnServer

::promptOnClient

packed client RunBase.

Using Runbase Framework

The runbase framework has two primary functions. To create a similar layout for dialogs presented to the application users and to make it possible to schedule a process to be batch able. The classes prefixed with RunBase* are referred to as the runbase framework. Several of these runbase classes are only called by the framework. In daily use you will only need to know the purpose of a few of them. See figure 20: Common used runbase framework classes.
Classname Description RunBase The class RunBase is used for tasks which should not be batch able. RunBaseBatch RunBaseBatch is used to give the application user the option to schedule a batch job for the task. RunBaseReport Only used for heavy reports and is therefore a subclass of RunBaseBatch.

The part of the runbase framework used for reports is explained in more detail in the chapter Reports.
Example 4: Creating batch able class

Objects used from MORPHXIT_Classes project _ Class, MyClass_RunBaseBatch _ Menu item action, MyClass_RunBaseBatch In this example a class using the runbase framework will be created. The class will have an option to be executed as a batch job. Focus is on how to construct a class using the runbase framework. The class will print all customers where customer transactions are posted after a specified date. The last entered from date used for searching customer transactions will be stored. Create a new class called MyClass_RunBaseBatch.
class MyClass_RunBaseBatch extends RunBaseBatch { FromDate fromDate; DialogField dialogFromDate; #define.CurrentVersion(1) #localmacro.CurrentList

fromDate #endmacro }

The new class must be a subclass of the class RunBaseBatch. A variable of the extended data type FromDate is created for storing the last entered date. The variable dialogFromField is a variable of the class DialogField which is used to add a field to the dialog shown to the application users. The macro constant CurrentVersion is keeping track of the last version of the dialog. CurrentList is a macro containing the variables to be stored from the last run of the class.
public container pack() { return [#CurrentVersion, #CurrentList]; }

Pack() is overridden. The method is returning the two macros created in ClassDeclaration.
public boolean unpack(container packedClass) { container base; boolean ret; Integer version = conPeek(packedClass,1); switch (version) { case #CurrentVersion: [version, #CurrentList, base] = packedClass; ret = true; break; default: ret = false; } return ret; }

Unpack() is also a overridden method(). The variables in the macro CurrentList are initialized when unpack() is executed.
static void main(Args _args) { MyClass_RunBaseBatch runBaseBatch = new MyClass_RunBaseBatch(); ; if (runBaseBatch.prompt()) runBaseBatch.run(); }

This is a static method declaring the class. Main() is used to execute the class. If the dialog is not canceled by the application user, the method run() will be executed.
protected Object dialog() { DialogRunBase dialog = super(); ;

dialog.addGroup("Date"); dialogFromDate = dialog.addFieldValue(typeId(FromDate), fromDate); return dialog; }

I n this overridden method the dialog is declared. A field for entering from date is added to the dialog.
public boolean getFromDialog() { boolean ret; ret = super(); if (ret) { fromDate = dialogFromDate.value(); } return ret; }

GetFromDialog() is called if the button Ok is pressed in the dialog. The value entered in the from date field in the dialog is stored in the variable fromDate.
client server static ClassDescription description() { return "Testing batch able class"; }

All classes inherited from the runbase framework should have this method. As the method is static you cannot override the method from the super class, so description() must be created manually. The method will add a caption to the top of the dialog window.
public void run() { CustTable custTable; CustTrans custTrans; Counter totalRecords; ; select count(recId) from custTable exists join custTrans where custTrans.accountNum == custTable.accountNum && custTrans.transDate >= fromDate; totalRecords = custTable.recId; startLengthyOperation(); this.progressInit("List customers with transactions", totalRecords, #AviSearch); while select custTable exists join custTrans where custTrans.accountNum == custTable.accountNum && custTrans.transDate >= fromDate { progress.incCount(); progress.setText(strfmt("%1, %2", custTable.accountNum, custTable.name)); sleep(500); } endLengthyOperation();

Run() is processing the task for the class based on the dialog settings. The first select statement is counting the number of customers to be processed using an aggregate function. The counted numbers are used for a progress bar which will be incremented for each loop where looping the customers. The global methods startLengthyOperation() endLenghthyOperation() is used the set the scope to invoke thehour glass. A macro call is used as parameter when initializing the progress bar. This is macro constant from the macro library AviFiles which is declared in the runbase framework. Instead of printed information to the Infolog, the progress bar is updated for each loop. The function sleep() is setting a delay of second making it possible to see the progress bar. Finally, create a menu item for the class by dragging the class to the menu item node Output. When executing MyClass_Runable a dialog will appear. The dialog has two tab pages. The first tab page has a field group with the field for specifying from date. The value added will be stored as the default value next time the class is executed. The prompt() method in main() is calling the dialog() method. The method run() is called if the button Ok is pressed in the dialog and the method getFromDialog() is validated true. You should always start by overriding the methods pack() and unpack() when creating a runbase class. If you try to create the static main() method before overriding these methods you will have an error as pack() and unpack() are part of an interface implemented by the runbase framework. The second tab page is for the batch settings. Even though a class may not be executed as a batch job you can still use the class RunBaseBatch. If the method canGoBatch() is overridden and return false, the batch tab page will not appear. Notice, if you need to validate the values keyed in by the application user in the dialog, you should override the method validate(). The dialog cannot be closed using the Ok button before the method validate() returns true. You can execute the class MyClass_Runable directly by right-clicking the class and choose Open. As the class has a static method called main() with the parameter Args, the class can be executed without any coding. This is also called a run able class. All classes with a static main() method are runable and can be executed from a menu item. Note that the runbase framework is not required to create a runable class. You should execute the class from a menu item. It is recommended always to create a menu item for your runable class as you will then be testing your class as the application users will execute the class. Runable classes are always created as action menu items, if not calling a form or a report. A progress bar was used in the example. For a task which takes more than a few minutes to process you should consider adding a progress bar. This will make your class more user friendly as the application user can see when the job is finished. As progress bars are a part of the runbase framework you can easily add a progress bar to your subclass. You can however use progress bars for any block of code. The classes

prefixed with SysOperationProgress* are used for building progress bars from scratch. The form Tutorial_Progress will show you a lot of the features available when using progress bars. For an overview of the available animations in progress bars check the class Tutorial_ShowAviFiles. The parameter Args in main() is used to get a handle on the calling object. This is often used when calling and runable class from a form as you by using Args will be able to get the cursor record or just identify the calling object. The chapter Forms shows the use of Args.

Dialog
A dialog is the user interface of a class. When you need a dialog for your class you should use the runbase framework as dialogs is an integrated part of the framework. The classes prefixed with Dialog* are used by the framework. Simple form features like grouping fields, adding lookups to related fields are provided by the dialog classes. You can add additional buttons to your dialog like calling a query. If your class is inherited from the RunBaseReport class your report query and printer settings will automatically be wrapped in the dialog.
Example 4: Class dialog

Objects used from MORPHXIT_Classes project _ Class, MyClass_RunBaseDialog _ Menu item action, MyClass_RunBaseDialog In this example some of the common features in the class dialog is shown. To simplify the code, the methods description() and run() has by purpose been left out. Start duplicating the class MyClass_RunBaseBatch and rename the class to MyClass_RunBaseDialog. Pack() and unpack() will remain unchanged. The run() method must be deleted. The other methods will be modified as follows:
class MyClass_RunBaseDialog extends RunBaseBatch { NoYesId selectDate; FromDate fromDate; ToDate toDate; NoYesId selectCustGroup; CustGroupId custGroupId; DialogField dialogFromDate, dialogToDate, dialogSelectCustGroup, dialogCustGroup; DialogGroup dateGroup, countryGroup; #define.CurrentVersion(1) #localmacro.CurrentList fromDate, toDate, selectCustGroup, custGroupId #endmacro }

Some additional dialog fields have been declared. A variable is created to store each of

the dialog fields. The macro CurrentList is extended to store the new variables.
protected Object dialog() { DialogRunbase dialog = super(); ; dialog.allowUpdateOnSelectCtrl(true); dateGroup = dialog.addGroup("Date"); dateGroup.frameOptionButton(FormFrameOptionButton::Check); dateGroup.columns(2); dialogFromDate = dialog.addFieldValue(typeId(FromDate), fromDate); dialogToDate = dialog.addFieldValue(typeId(ToDate), toDate); countryGroup = dialog.addGroup("Customer"); countryGroup.columns(2); dialogSelectCustGroup = dialog.addFieldValue(typeId(NoYesId), selectCustGroup, "Select customer group"); dialogCustGroup = dialog.addFieldValue(typeId(CustGroupId), custGroupId); return dialog; }

The dialog group date now contains from date and to date. By default all dialog fields will be added to a single column. The method columns() is used to set from date and to date at one line. The dialog method frameOptionButton() is used to have a checkbox in the field group header. The other field group Country has two fields. If the field dialogSelectCustGroup is unmarked, the field dialogCustGroup cannot be edited. This feature can only be used if the dialog method allowUpdateOnSelectCtrl() is set to true.
public void dialogSelectCtrl() { ; if (dialogSelectCustGroup.value()) { dialogCustGroup.allowEdit(true); } else { dialogCustGroup.allowEdit(false); } }

Each time a dialog method is entered this method is executed if the dialog method allowUpdateOnSelectCtrl() is set to true.
public boolean getFromDialog() { boolean ret; ret = super(); if (ret) { fromDate = dialogFromDate.value() ? dialogFromDate.value() : systemdateget(); toDate = dialogToDate.value() ? dialogToDate.value() : systemdateget(); selectCustGroup = dialogSelectCustGroup.value(); custGroupId = dialogCustGroup.value(); }

return ret; }

The values are retrieved from the dialog fields and initialized with the variables declared in ClassDeclaration. The check field in the header of the dialog group date is on purpose not added.
static void main(Args _args) { MyClass_RunBaseDialog runBaseDialog = new MyClass_RunBaseDialog(); ; if (runBaseDialog.prompt()) runBaseDialog.run(); }

Main() has just been changed to executed the new class. All that is left is to create a new action menu item for the class. The class will not process anything as run() has been left out. As run() is a member of the super class this will not give any error. Running the class will show the dialog. The dialog shows two ways of making a value of a field value depended on another field value. If unmarking the check field in the date field group header, the fields from date and to date cannot be edited. Your case could be that a date range is entered and if disabled all records are looped. The Customer field group uses a similar functionality. The field Customer group can only be specified if the Select customer group is marked. As the method dialogSelectCtrl() can only be executed when using fields of the type DialogField this is a often used solution. However dialogSelectCtrl() cannot refresh the dialog so the dialog will not be update with the new settings before leaving the field select customer group. An alternative to use the dialog classes for building dialogs is to create a form. The runbase framework supports the using standard forms as dialogs. A form will be presented just as a dialog. This is often a preferable solution for complex dialogs. If you have to build a complex dialog it can often save time to use a form. You will have an easier overview of your dialog and it will be easier later to extend the dialog. You will find more information on using forms as dialogs in the chapter Forms. In the dialog example the dialog fields could just as well have been added to a query instead. By using the dialog method addMenuItemButton() a button called Select will be added to the dialog. The query loaded when the select button is pressed must be specified by overriding the method queryRun(). Add the following code to your dialog to have a button for the query shown in the dialog:
dialog.addMenuItemButton(MenuItemType::Display, menuItemDisplayStr(RunBaseQueryDialog), dialogMenuItemGroup::BottomGrp);

By overriding queryRun() with the code below, a query containing CustTable joined by

CustTrans will be loaded.

public QueryRun queryRun() { QueryRun ret; ret = new QueryRun(QueryStr(Cust)); return ret; }

Details on how to build and retrieve information from a query is explained in the chapter Queries. A useful feature of using the runbase framework is that the last entered value of a field can easily be stored for the next run. Typically this is used for storing values of dialog fields, however any variables can be stored. You will only have to add the variable to the CurrentList macro. When changing CurrentList on an existing class, you should increment the macro constant CurrentVersion by one, as errors might occur if using the same version when changing the list of saved variables. The last values are stored in the system table SysLastValue per user and company. Incrementing CurrentVersion will cause a new record to be created in SysLastValue. Pack() and unpack() must always be overridden as they are part of an interface in the runbase framework. Also the two macros in ClassDeclaration are required. You will have situations where the last values are not needed. To skip using the last values pack() must return an empty container like connull() and unpack() must return false. If you just need a dialog to appear with the choice to continue or not, there will be a more simple solution than using the runbase framework. The class Box has a collection of static method which supports all the common combinations. You can wrap the call of a method from the class box in an if statement:
static void Classes_Box(Args _args) { if (Box::yesNo("Continue", DialogButton::Yes,"Test of Box") == DialogButton::Yes) info("Here goes."); }

Study this link also: http://www.axaptapedia.com/RunBaseBatch

2. Pack unpack method and where does last value gets store?
Ans. Last value stored in usage data (joshi answered and I also think) tu check kar lena

Pack This method is used for storing last values. It is used in conjunction with unpack(), which loads the last value stored. However unpack() is not a base method. If a new dialog field has been added, pack() is overridden to store the values from the dialog.

Pack-Unpack Design Pattern Use the pack-unpack pattern to save and/or store the state of an object, and then later reinstantiate the same object.

Situation
An object has a particular state. You want to work with the same object at a later time or another place (such as on another tier).

Solution
Make it possible to save the state of the object in a form that can be persistently saved or transported to another tier. Moreover, make it possible to reinstantiate the object. For Table objects (records), this is straightforward because they are enabled for persistence and are automatically transported between client and server. For class objects, create a pack method to read the state of the object and return it in a container suitable for saving or transporting between tiers. Reading the state of the object implies collecting the value of all its members. If the members are tables (records, cursors, temporary tables) or classes, it must also be possible to read their state. Likewise, create an unpack method that takes the packed state and reinitializes an object with it. Construct the object before creating an unpack method. You can also create a static create method that instantiates a new object. Initialize the new object with the packed state information, and return it ready for use.

Implementation
To implement the pack-unpack pattern, create the following methods. public container pack() Returns the state of the object as a container.

According to the Persistent Data Storage Design Pattern, the first entry is a version number that describes the version of the saved structure. Example:
container pack() { return [#CurrentVersion,#CurrentList]; }

Where the macros are defined in the classDeclaration:

public class InventAdj extends RunBaseBatch { InventClosing inventClosing; #DEFINE.CurrentVersion(1) #LOCALMACRO.CurrentList InventClosing #ENDMACRO }

public boolean unpack(container _packedObject) The unpack method takes the saved state of the object and reinitializes the object with it. It reinitializes the object members according to the values in the container, taking the supplied version number into account. The method can return a Boolean that signals the result of the initialization process. The object should be only instantiated before a call is made to the unpack method. Example:
public boolean unpack(container _packedClass) { int version = conPeek(_packedClass,1); ; switch (version) { case #CurrentVersion: [version,#CurrentList] = _packedClass; break; default: return false; } return true; }

public void new() The constructor (the new method) of the object is expected to take no parameters. It should be possible to instantiate the object without knowing anything about it except its class type, and then completely reinitialize it by using the unpack method. A typical example would be to not have an explicitly defined new method, but to use the standard new method without parameters. public static <YourClass> create(container _packedObject) You can also create a create method that does the following:

Instantiates a new object (by calling the constructor) Initializes it with the saved state of the object and reinitializes the object with it (by calling the unpack method, which can then be set to private) Returns the reinitialized object of your class

For example, this is done in the List::create system class method.

Limitations
An object cannot be packed unless all the members it contains can be packed. If objects contain table or class members, it must be possible to pack these members and to return them to the same state when unpacked. A reinstantiated object is not the same object as the one that was saved. It is simply an object of the same class whose members contain the same information.

Other info
Pack() and unpack() must always be overridden as they are part of an interface in the runbase framework. Also the two macros in ClassDeclaration are required. You will have situations where the last values are not needed. To skip using the last values pack() must return an empty container like connull() and unpack() must return false.
Pack This method is used for storing last values. It is used in conjunction with unpack(), which loads the last value stored. However unpack() is not a base method. If a new dialog field has been added, pack() is overridden to store the values from the dialog.

Pack() saves the current value of CurrentVersion and CurrentList specified in the ClassDesclaration. In the report dialog example, the methods pack() and unpack() were used. These are the methods used to store the last value of a dialog and transfer the user parameters specified in the dialog from the client to the server when the report will executed in batch mode

3. Batch processing diffrence in 4.0 and 09.

Ans. Batch processing enhancements
You can now run batch jobs on an AOS instance without a client. You can set specific times for each AOS instance to run batch jobs and manage all running batch jobs in the environment from a single form. Dependencies between batch jobs have been enhanced so that you can specify processing order and parallelism, and also the steps to take after batches have been run.

4. Enum value passing through code.

Ans. Through args class.. Args = new Args(formstr(COSDimensionFill)); args.caller(element); args.parmEnumType(enumnum(SysDimension)); args.parmEnum(COSAllowedDimensions::getAllowedDimensionValue(sysDim)); args.record(cosCostDistribution); formRun = classfactory.formRunClass(args); formRun.init();

5. what tables are hit when S.O. or P.O. is created, picking list packing list, invoicing etc.
Ans. Saletable, sales line, inventsum, inventdim, inventtrans, ledgertable,ledgertrans, Purchtable,purchline and same abuv

6. select statment or query, what to use? Query is best thats what I knw.. call mukesh sir and take the answer and tell me also. 7. MAPS.. are Table maps, where you can maps fields of different table and create a common functionality, methods in those map, it reduce writing code again and again, just like addres map.

4 layers have been renamed in Dynamics AX 2009 . DIS / DIP / LOS / LOP have become HFX / SL1 / SL2 / SL3 respectively. HFX is reserved for releasing hot fixes, and the 3 new solution layers (SL1/SL2/SL3) will be used to release Microsoft Dynamics Industry Solutions.

Layers, -

The purpose of having 3 solution layers is to enable side-by-side install of Industry Solutions. At deployment time any SL1 layer can be renamed to SL2, SL3, BUS or BUP through a regular file rename. The AOS will recognize the layer, and honor its position in the layer stack. This will enable installing up to 3 Industry Solutions on the same system (or up to 5 Industry Solutions if the BUS and BUP layers are vacant.)

http://blogs.msdn.com/b/mfp/archive/2008/04/22/new-layers-in-dynamics-ax-2009.aspx

chk abuv link. 8. Constryct methods how and why its use. To initialize and construct the class on global level or param level.. public static InventReport_Age construct() { return new InventReport_Age(); }

9. Relation on EDT for look up and stuff Table for child master relationship.

10. We can put our tables in table collection and make them virtual for all company, virtual means global for all company, only main tables are recommended to be in Virtual table collection not transaction table. 11. Delet actions cascade, restricted and cascade+restricted it does not allow to delet the record from table or forms, but you can delet via code, coz via code validate delet method is not called.

Relation norma, field fixed, related field fixed. Agar kuch puchna hai toh call me ok.