Ax2012 Enus Devii 01

Chapter 1: Introduction to X++

1-1

CHAPTER 1: INTRODUCTION TO X++ Objectives

The objectives are:

Identify key features of developing with X++. Describe the basic foundation of object-oriented programming. Use the development tools available within Microsoft Dynamics

AX. Create object and data models from existing application elements by

using the Reverse Engineering tool. Use best practices to instill good programming habits.

Introduction X++ is the primary programming language used in the MorphX Development environment. When you develop with X++, refer to Microsoft Dynamics AX Developer Help, available from the Help menu for detailed information. The following are important features of X++:

X++ resembles other popular languages such as C# and Java. Due to this resemblance, programmers already familiar with these languages will be able to transition into the MorphX development environment quickly.

Because X++ includes many integrated SQL commands, Microsoft Dynamics AX can build complex accounting and business management systems.

X++ is an object-oriented language and provides a clean and efficient object-based development platform.

Programmers who use X++ can access existing Microsoft Dynamics AX system classes that provide functionality ranging from basic I/O, XML, to changing controls in the graphical user interface at run time. These system classes can be extended to provide new behavior.

Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics AX 2012

1-2

Characteristics of X++ The following are characteristics of X++:

Reliable: X++ provides extensive compile-time checking, followed by a second level of run-time checking. Language features guide programmers toward reliable programming habits. The memory management model is simple; objects are created by using a "new" operator and there is automatic garbage collection. There are no explicit programmer-defined pointer data types or arithmetic. This model eliminates entire classes of programming errors.

Interpreted and Dynamic: Benefit from faster development cycles - prototyping, experimentation, and rapid development, versus the traditional compile, link, and test cycles.

Interoperable: Components in Microsoft Dynamics AX are seamlessly available to any application supporting .NET, and conversely X++ is able to consume external managed code and COM objects.

Scenario Systems developers in a large development environment have joined a team that is customizing a Microsoft Dynamics AX application. This is the team's first project in X++ so they need to learn what development tools are available to them within Microsoft Dynamics AX.

Development Tools All elements that comprise the Microsoft Dynamics AX application (classes, forms, tables, and more) are organized in the Application Object Tree (AOT). This is a central, organized index to all application elements, displayed in a graphical tree view.

Microsoft Dynamics AX customizations are developed by modifying one or more elements from the AOT. These elements are usually assembled in a project, or, in other words, a container for elements that implement an application in Microsoft Dynamics AX. Projects help manage development efforts by organizing units of functionality.

As developers create new projects or modify existing projects, they use a series of development tools. These tools include the following:

X++ Editor X++ Compiler X++ Debugger Visual Studio Visual Studio Debugger




1-3

Other tools exist to aid developers while writing code and for managing modifications they make to elements in the AOT.

All these tools, apart from Visual Studio, are accessible from the Development Workspace. This is a unique version of the regular workspace, designed specifically for developers to work in. To launch a development workspace press Ctrl+Shift+W from the regular workspace. Alternatively, a command line parameter (-development) can be added to the Microsoft Dynamics AX client shortcut, to automatically launch in the development workspace. Development cannot be done in the regular workspace, so a development workspace must be opened before doing any development.

The development workspace tools are described in the following sections.

The X++ Editor

Double-clicking many of the nodes in the AOT opens them in the X++ editor. The X++ editor can also be started by selecting View Code in the right-click context menu.

The X++ editor window consists of two panes:

The left pane contains a list of current methods or jobs The right pane displays the X++ code

FIGURE 1.1 CODE EDITOR WINDOW

There are several toolbar buttons in the heading of the X++ editor window. Many of these functions can be started using keyboard shortcuts. Moving the pointer over these buttons reveals the button's function. These buttons are described in the following table:




1-4

Button Keystroke Description New Ctrl + N Creates a new method or job.

Save Ctrl + S Saves the changes to the active method.

Undo Ctrl + Z Undo the last edit.

Redo Ctrl + Y Redo the last undone edit.

Go F5 Executes the class, form, or project.

Toggle Breakpoint F9 Turns breakpoints on and off.

Enable/Disable Breakpoints

Ctrl + F9 Enables or disables a breakpoint.

Remove all breakpoints

Ctrl + Shift + F9

Deletes all breakpoints from the method.

Compile F7 Checks the code for errors, compiles the code, and saves it.

Lookup label/text Ctrl + Alt + Space

Helps you find a label.

Script Alt + R Helps you choose between a selection of scripts.

Add to Version Control

Adds the current element to Version Control and checks the element out.

Check In Alt + I Checks in the current element.

Check Out Alt + O Checks out the current element.

Undo Check Out Alt + U Reverts all edits since the last check out.

History Opens the Version Control History form.

Get Latest Get latest version of the element from Version Control history.

Help F1 Accesses the X++ editor window help.

Toggle line numbers

Turns the line numbers on and off.

Toggle change tracking margin

Turns the change tracking margin on and off.




1-5

To make reading easier, the X++ editor color-codes different kinds of code as follows:

Color Code type Blue Reserved words

Green Comments

Dark Red Strings

Bright Red Numbers

Purple Labels

Black Everything else

Jobs

A job is a stand-alone block of code in Microsoft Dynamics AX that can be run from the X++ editor. Jobs are used primarily for testing code during development and running batch processes within Microsoft Dynamics AX that affect large amounts of data.

This course uses jobs as a mechanism to write code and run it directly from the X++ editor. Most code for applications is written in classes, methods, tables, and forms. However, jobs are useful for testing blocks of code before inserting them into methods or classes.

The following is default code when you create a new job in the AOT:

static void Job1(Args _args) { }

NOTE: Unlike classes and other elements in the AOT, jobs can only be renamed in the Code Editor. Most other AOT elements can have their name changed in the Property window, or directly on the AOT node.

Create a new job by right-clicking the Job node on the AOT, and selecting New Job. The X++ editor opens, displaying the new job. The job can be renamed in the text editor or in the AOT. In the example above, the job is called Job1 and can be renamed by change Job1 to the required namein the text editor.




1-6

Compiler

When code that is written in X++ is ready to be executed, use the compiler. The compiler is a translation program that converts X++ into a language that can be interpreted.

Code can be compiled by clicking the Compile button in the X++ editor toolbar or by pressing F7. It can also be compiled by right-clicking the node in the AOT and selecting Compile.

In this course you will also learn about inheritance. Classes that inherit from, or extend, other classes can be compiled by right-clicking the main class, then selecting Add-Ins > Compile forward. This means any changes that are made to the main class are propagated down to the sub-classes correctly.

Use the Compiler Output window to view information to help improve and correct errors in the code. The Output window will update its contents every time a compilation is performed.

FIGURE 1.2 COMPILER OUTPUT WINDOW

There are four different compile result types:

Result type Description Error These are compile errors, and must be resolved before

code can be run.

Warning These are compile warnings, and should be resolved, but will not prevent the code from being run.

Best Practice These are found when an element contains code or properties that deviate from the list of Microsoft Dynamics AX Developers Best Practices. Best Practice deviations are only found by the compiler when the Diagnostic level is set to Level 4. The Diagnostic level is a parameter accessible from the Setup button, explained later in this material.

Task Tasks are placeholders that can be added to X++ code to remind developers that something is unfinished. To create a task, use a single line comment, followed by the word ToDo and a description of the task. For example: // ToDo Add validation code




1-7

The Compiler window contains the following features:

Filter buttons: At the top of the window, there are buttons to toggle the four different compile result types on and off. Toggling the result type off will remove results of that type from the Compiler Output window's list.

Reset button: This button will reset the contents of the Compiler Output window.

Edit button: This button will open the X++ editor or Property sheet corresponding to the selected compile result.

Import/Export button: This button allows compile results to be exported to an HTML file, or imported into the Compiler Output window from an HTML file.

Setup button: This button accesses forms where the Compiler Output window parameters can be set for the user. These include settings such as the Diagnostic level of the compiler, and which Best Practices will be enforced.

Debugger

Microsoft Dynamics AX includes a powerful stand-alone debugging tool for X++ code. Use the Debugger to debug X++ code running on the:

Microsoft Dynamics AX Client Microsoft Dynamics AX Object Server (AOS)

NOTE: Managed code and X++ compiled into Intermediate Language (IL) are debugged using the Visual Studio debugger. This topic will be covered in the Visual Studio Integration chapter of the Development III course. This topic only covers debugging standard X++ code.

Use the Debugger to:

Run a program to a certain point and then stop at a defined breakpoint.

Step through the program one statement at a time. Display the call stack with code line numbers. Watch specific variables and modify their values during execution. Track messages being sent to the infolog.




1-8

Breakpoints

Breakpoints are set on individual lines of code. This is a command to stop program execution at that point and enter the debug mode.

When the logic flow of the code in a user's session reaches a breakpoint set by the same user, the debug session begins and the debugger is automatically started.

To set a breakpoint:

1. Rest the cursor within the X++ code in the editor where you want to insert the breakpoint.

2. Click the Breakpoint button in the toolbar or press F9. 3. Click in the gray area to the left of the line of code.

The line of code is highlighted in dark red to indicate that a breakpoint is enabled. A disabled breakpoint is indicated with a red border only. Disabled breakpoints will not cause program execution to stop, but are useful when a specific location needs to be remembered, perhaps to enable the breakpoint at a later point.

Breakpoints can also be set by inserting the keyword Breakpoint into the code. This should be used with caution, because it will mean that all users will enter the debugger when the code reaches this point.

All these methods of settings breakpoints are shown in the following figure:

FIGURE 1.3 BREAKPOINTS IN CODE




1-9

To turn debugging off, you can visit Tools > Options, and select the Developer tab. In the Debug field, select None. When you set a breakpoint in code, this field will automatically be set back to When Breakpoint.

Breakpoints are only recognized on the tiers (client or server) that have been configured to recognize them. Code running on the client tier will always stop at a breakpoint in a user's session, when the user has debugging turned on. Code running on the server tier will only stop at a breakpoint when the AOS has specifically been configured to enable breakpoints. This is a setting on the Microsoft Dynamics AX Server Configuration Utility.

The Debugger can display up to six information windows. The windows display detailed information about the current state of the executing code while you are debugging. The information windows available are as follows:

Window Description Code Displays the X++ code currently being debugged. The red

dot indicates where the breakpoint is inserted. The yellow arrow indicates the line that is being executed. The arrow can be dragged to a different line of code so that code is either re-executed or skipped.

Variables Displays the value of the variables. Modified variables appear in different colors to indicate change. Users can alter the value of variables in the debugger to see how the program would run under different conditions.

Call Stack Indicates which method is currently being debugged. Double-clicking a method further down the stack will take the Code window to that method.

Watch Contains a user-defined range of variables. The variables can be dragged and dropped from the Variables window or the Code window.

Breakpoints Displays the list of currently defined breakpoints with their enabled status and line number.

Output Displays separate views of text written to the window from X++ code and kernel code. These views organize information sent to the Output window.

HINT: The Microsoft Dynamics AX Debugger Help Guide can be accessed directly by pressing F1 in the debugger. This guide lists keyboard shortcuts that make it easier and faster to use the debugger.




1-10

Use the toolbar located above the Output window to navigate through the code and perform other actions.

FIGURE 1.4 DEBUGGER TOOLBAR

Moving the pointer over these buttons reveals the button's function and a keyboard shortcut.

The more generally used buttons are described in the following table, together with the keyboard shortcut:

Button Keystroke Description Go F5 Continues the execution.

Stop Debugging

Shift + F5 Terminates the execution at the current line.

Insert/Remove Breakpoint

F9 Inserts or clears a breakpoint.

Enable/Disable Breakpoint

Ctrl + F9 Enables or disables a breakpoint.

Remove all breakpoints

Ctrl + Shift + F9

Clears all breakpoints.

Step Over F10 Steps to the next line of code in the current method.

Step Into F11 Steps into the current line if it contains a method call.

Step Out Shift + F11 Steps out of the current method.

Run to Cursor Ctrl + F8 Continues the execution until reaching the location of the cursor in the Source window.

By default, for performance reasons, debugging in code that is executed on the AOS is disabled. During development it is often required to debug this code. The following procedure will enable code run on the AOS to be debugged.

1. Close the Microsoft Dynamics AX client 2. Click Start > Administrative Tools > Microsoft Dynamics AX

2012 Server Configuration 3. Click Manage > Create Configuration 4. In the Configuration Name, enter a name, for example AOS_Debug. 5. Click OK 6. Check the box Enable breakpoints to debug X++ code running on

this Server




1-11

7. Click Apply 8. Click Yes to restart the AOS service. This may take one or two

minutes. 9. Click OK to close the Server Configuration Utility. 10. Restart the Microsoft Dynamics AX client.

Demonstration: Using the Debugger

Perform the following steps to use the debugger.

1. Open the AOT. 2. Expand Tables > SalesLine > Methods 3. Double-click the method ItemIdChanged. 4. Position the cursor on the folloing line of code

this.initfromInventTable(this.inventTable(), _resetPrice); 5. Press F9 to set a breakpoint. The line of code should be highlighted

in red to indicate a breakpoint has been set. F9 will toggle this breakpoint on and off.

6. An infolog message may appear warning you that debugging is not enabled on the server. If it does, click Close.

7. Close the X++ editor. 8. In the Application workspace, click on Sales and marketting. 9. In the Common section click on Sales orders > All sales orders. 10. Click New > Sales Order. 11. Select a customer account. 12. Click OK. 13. Click the drop down button on the Item number field and select an

item. 14. The debugger should start. 15. Look at the windows that are available. 16. In the Variables window, find the variable this. 17. Press F10 to step through the code. 18. Note how the field values change and are highlighted in red. 19. Press F5 to run the code and stop debugging.

Compare

Use the compare tool to highlight differences between versions of a single element:

In two different layers In an old version of an element In two different elements An element that will be imported




1-12

The most common use is to review differences between two layers. This is useful when determining what was changed in a standard element. To compare two layers, right-click the element and select Compare. Select which two layers to compare and then click Compare.

Any element nodes that contain differences will be listed in the lower-left pane, and the differences can be seen in the lower-right pane. The differences are color coded to make it clear which version the differences come from.

FIGURE 1.5 COMPARE SYS TO USR

You can also use the compare tool to move code and element properties between layers. When a difference is found, a black arrow is displayed in the left margin of the lower-right pane. The icon will delete code from the current layer, or paste code in to the current layer. This feature is useful when upgrading code.

NOTE: You can view code in a different layer by right-clicking the element and selecting Layers.

Demonstration: Using the Compare Tool

Perform the following steps to use the compare tool.

1. Open the AOT. 2. Expand the Classes node. 3. Expand the Activities class. 4. Double-click the Construct method. 5. Add the following line of code:

// Compare tool demonstration 6. Press F8 to compile and save. 7. Right-click the Activities class. 8. Select Compare to open the compare tool.




1-13

9. Click the Compare button. 10. Note how the tool displays differences in the color of the version the

code is in. 11. Note the icon to remove the code from the USR layer.

X++ Attributes

Microsoft Dynamics AX supports attributes being assigned to X++ code. This allows for a rich set of metadata to be built. It describes methods and types that are defined within X++ code.

Attributes are defined as classes that are derived from the SysAttribute class. The following code for the SampleAttribute class is an example of an attribute class:

public class SampleAttribute extends SysAttribute { str sMetadata; // A field in classDeclaration.

public str GetMetadata() { return sMetadata; }

public void new(str _sMetadata) { super(); sMetadata = _sMetadata; } }

Attributes can then be used on other classes and methods. The following example shows the structure of a new Attribute class, AuthorAttribute:

class AuthorAttribute extends SysAttribute { str author; public str Author() { return author; } public void new(str _author) { super(); author = _author; } }




1-14

In the following example, AuthorAttribute is used to decorate other classes and methods:

[AuthorAttribute("Isaac")] public class MyClass() { ... } [AuthorAttribute("Isaac")] void MyMethod() { ... }

Type Hierarchy Browser

The Type Hierarchy Browser is a tool for viewing at a glance, which other elements one element inherits from. For example, open the Type Hierarchy Browser for the CustAccount extended data type. This can be done from the elements context menu > Add-ins > Type hierarchy browser:

FIGURE 1.6 TYPE HIERARCHY BROWSER FOR CUSTACCOUNT

Notice that CustAccount inherits from CustVendAC, which inherits from ExternalAccount, which inherits from the primitive string type. This is displayed in a tabular format so that the value of properties at each level of the hierarchy can be compared side-by-side.




1-15

The browser can also be used to explore the hierarchy farther down the tree. In the tree view on the left-hand pane, expand the selected node to display all elements that inherit it. In this example, you can expand the CustAccount node, to display all extended data types that inherit it. The following figure shows the same browser shown earlier in this topic. The difference now is that the CustInvoiceAccount type is selected:

FIGURE 1.7 EXPANDING THE TYPE HIERARCHY




1-16

This tool can also be used on other elements, such as classes. When browsing the hierarchy on classes, the blue boxes in the grid represent a method that is overridden, or that exists only, on that class. The following figure shows a view of the hierarchy for the SalesLineType_Sales class:

FIGURE 1.8 CLASSES IN TYPE HIERARCHY BROWSER

Type Hierarchy Context

In addition to the Type Hierarchy Browser, the Type Hierarchy Context window can be used to view the hierarchy of an element in the AOT. The Type Hierarchy Context window can be docked to the workspace, and will change dynamically as AOT nodes are selected.

Open the Type Hierarchy Context window by navigating to: Tools > Type Hierarchy Context.

With the Type Hierarchy Context window open, select a few different nodes in the AOT, and notice how the window changes its contents based on the selected node.




1-17

The following figure shows a view of the Type Hierarchy Context window, with the SalesLineType_Sales class node selected in the AOT:

FIGURE 1.9 TYPE HIERARCHY CONTEXT

Each of the nodes in the Type Hierarchy Context window is also a hyperlink that will open the Type Hierarchy Browser for an element.

Reverse Engineering Reverse engineering is used by partners to easily retrieve detailed information about the structures and relationships of the Microsoft Dynamics AX business logic and data model. The goals of reverse engineering are to extract relationships, and integrate and view collections in Microsoft Office Visio as UML diagrams.

The feature handles both reverse engineering of the data model and the object model.

You can use the Reverse Engineering tool to visualize data and object models generated from projects in Microsoft Dynamics AX. These models are created as Microsoft Visio documents.

To open the Reverse Engineering tool, right-click a project and select Add- ins > Reverse engineer.

The information Microsoft Dynamics AX provides Visio depends on whether you are creating a data or an object model from a project. The following table shows what is provided for each model type:

Data Model Object Model Tables

Table Group property

Table Fields

Table Index information

Table Methods and parameters




1-18

Data Model Object Model Classes (extended and referenced)

All Extended Data Types

All Base Enums

All X++ Data Types

Procedure: Reverse Engineering an Object Model

Perform the following steps to generate an object model that is based on elements included in a project.

1. Create a project. 2. Drag AOT elements into the project you want to reverse engineer

into an object model. 3. Right-click the project and select Add- ins > Reverse engineer. 4. Click Visio UML Object model to create a UML object model. 5. Select a name and path for the file and then click OK. 6. From Microsoft Visio, drag object nodes into the center grid to lay

out the desired model.

Procedure: Reverse Engineering a Data Model

Perform the following steps to generate a data model that is based on elements included in a project.

1. Create a project. 2. Drag the AOT elements into the project you want to reverse engineer

into a data model. 3. Right-click the project and select Add-ins > Reverse engineer. 4. Click Visio UML Data model to create a UML data model. 5. Select a name and path for the file and then click OK. 6. From Microsoft Visio drag table nodes into the center grid to lay out

the desired model.




1-19

Best Practices Best practices involve understanding all the things that you should do and distinguishing them from the things that you can do.

Best Practices in Microsoft Dynamics AX apply to programming in a standard application, certified solutions, and they are recommended for any Microsoft Dynamics AX partner or an end-user enhancing or customizing Microsoft Dynamics AX.

Some benefits of using best practices include:

They guarantee consistency throughout the code. This lets other developers more easily read and understand your code.

Code is more secure. There is no redundant code. Upgrading is easier and quicker, and has less risk of errors.

Refer to the "Microsoft Dynamics AX Developer's Help" for detailed information on best practices.

Naming Conventions

Naming conventions contribute to consistency and to making the application easier to understand.

Where you can, application element names should be constructed hierarchically from three basic components:

{business area name} + {business area description} + {action performed (for classes) or type of contents (for tables)}

Examples:

CustJournalPrintOutInvoice PriceDiscAdmDelete PriceDiscAdmSearch PriceDiscAdmName PriceDiscAdmTrans




1-20

Additionally:

All names must be in U.S. English. The default rule is to use logical and descriptive names if no other

specialized rules apply. Identifier names have a limit of 40 characters. Names must be spelled correctly. Names must be used consistently. All texts that appear in the user interface must be defined by using a

label. Do not begin a name with nonsensical or confusing prefixes, such as

"aaa" or "CopyOf". Do not begin a name with "DEL_" unless it is a table, extended data

type or enum, and it is needed for data upgrade purposes - doing this may cause unexpected results.

Code Placement

The placement of code depends on the code you are writing. The preferred procedure in an object-oriented programming language is to place code in a class that can be reused and called when it is needed.

You can place code in classes to have better control over where the code is executed. Performance considerations frequently dictate where code should run, and so controlling this is desirable. Code included in forms always runs on the client, and this could cause excessive client/server communication where it might not be necessary.

When deciding where to place code, ask the following questions:

Is the code related to the form's appearance or to the data that is entered through the form?

Can I use the code's functionality elsewhere in the application or in a different application?

Does the code execute on the client or on the server?

BEST PRACTICE: Always place the code nearest to the source so that it can be more easily manipulated. For example, code that manipulates a table should be placed in that table's methods.




1-21

Comments

A best practice for all programming is to consistently use comments. It is important when developing X++ programs in Microsoft Dynamics AX to use comments and document what the code does and how parameters are used. It is also good to know who made the change and why. When upgrading code, you have to decide whether to merge code and if this is the case, how to merge it; comments are useful to help determine why a code change is made. Note the following about how to use comments:

Comments can be inserted directly into the lines of code. Comments are ignored by the compiler. Comments turn the code green in the editor.

Some of the comments include the following:

Single line "//" Block comments "/* */" To do comments "TODO." To do comments appear in the compiler's

Tasks tab page. XML documentation comments

// This is a single line comment

/* This is a block comment because It contains more than one line */

/// /// Comment where XML tags distinguish sections. ///

The preceding XML documentation comments can be used to build XML documents that contain developer documentation. The XML documentation comments are also used to display "hover-over" help in the X++ editor. To extract an XML documentation file from code, right-click a development project node, and select Add-ins > Extract XML documentation.




1-22

Lab 1.1 - Print to the Screen Scenario

The client wants you to demonstrate how to print a message to the screen. Create a job that prints a message to the screen.

Challenge Yourself!

Create a job that prints the message "Microsoft Dynamics AX is fantastic."

Step by Step

1. Open the AOT. 2. Right-click the Jobs node and select New Job. 3. Rename the job. 4. Add the following code.

info("Microsoft Dynamics AX is fantastic.");

5. Compile (press F7 or click the Compile button on the toolbar). 6. Run the job (press F5 or click the Go button on the toolbar).




1-23

Lab 1.2 - Debug the Job Scenario

The client wants you to verify the code executes without errors. Debug the job that you created in the previous lab.

Challenge Yourself!

Set a breakpoint in the code in the job from the previous lab. Run the code and step through it.

Step by Step

1. Set a breakpoint in your job on this line of code: static void (Args _args)

2. Save the code by using a keyboard shortcut. 3. Run the code.

NOTE: You should enter the Microsoft Dynamics AX Debugger at this point. If not, ask your instructor.

4. Step through the code by using the icon on the toolbar or F11.




1-24

Lab 1.3 - Create a Data Model Scenario

You have been asked to evaluate the Project Accounting data model to prepare for required customizations according to customer requirements.

Challenge Yourself!

Make the data model for the Project Accounting module in Microsoft Visio by using the Reverse Engineering tool in Microsoft Dynamics AX.

Step by Step

1. Create a new Project. 2. Rename it to Reverse_Engineering. 3. Open the Reverse_Engineering project. 4. Open the AOT in another window and expand the Tables node 5. Drag-and-drop some project tables (tables starting with Proj) from

the AOT, to the Reverse_Engineering project. 6. Right-click the Reverse_Engineering project root node. 7. Select Add-ins > Reverse Engineer. Ensure that the Data model

option is marked. 8. Enter the path for the Microsoft Visio file. 9. Once the file is generated in Microsoft Visio, drag the tables to the

workspace and show the relationships.




1-25

Lab 1.4 - Create an XML Developer Document Scenario

You have been asked to create developer documentation for the Credit Limit modifications made in the standard Microsoft Dynamics AX application.

Challenge Yourself!

Create an XML file by using the XML documentation generation, for the Credit Limit development project.

Step by Step

1. Open the development project tree. 2. Find the Credit Limit project. 3. Right-click the project, and select Add-ins > Extract XML

documentation. 4. Enter a file name. 5. Click OK. 6. Click Close to close the infolog window. 7. Review the file created.




1-26

Summary This lesson introduced some development tools that you will use to make modifications to Microsoft Dynamics AX. You learned how to use the X++ editor to write code; how to compile code and review errors with the Compiler; and how to create breakpoints and step through executing code with the Debugger. Other tools like the Compare, Type Hierarchy Browser, Type Hierarchy Context, and Reverse Engineering tools were also introduced.

The next lesson will show how to use these tools by creating a Calculator Class that uses four basic methods.




1-27

Test Your Knowledge Test your knowledge with the following questions.

1. What are the three main Object-Oriented Programming components?

2. What are the functions of the six Debugger window panes?

3. What do you use the X++ editor for?




1-28

Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter

1.

2.

3.




1-29

Solutions Test Your Knowledge

1. What are the three main Object-Oriented Programming components?

MODEL ANSWER:

Classes are blueprints that describe the objects derived from them. A class is a model classification of the methods and variables in a specific type of object. Objects are instances of classes. Each instance has data members and logic (methods) defined in the class. Methods are functions (subroutines) associated with a class or an object. An object implements its behavior with methods.

2. What are the functions of the six Debugger window panes?

MODEL ANSWER:

The Code window pane displays the X++ code that is currently being debugged. The Variables window displays the value of the variables in the current block of code. Modified variables appear in different colors to indicate change. The Call Stack window tells you which method is currently being worked on. The Watch Status window displays a user-defined range of variables. The Breakpoint window consists of a header with two columns and the list of currently defined breakpoints. The Output window in the Microsoft Dynamics AX Debugger has separate views that display text written to the window from X++ code and kernel code. These views organize the information that is sent to the Output window.

3. What do you use the X++ editor for?

MODEL ANSWER:

The X++ editor is used for editing and creating X++ code. This editor contains many functions in the toolbar, through keyboard shortcuts, and also by using the context (right-click) menu. The X++ editor has two panes: the left side shows a list of the current methods and the right side shows the current X++ code.




1-30



/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages false /GrayImageMinResolution 244 /GrayImageMinResolutionPolicy /Warning /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.00000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages false /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /Warning /DownsampleMonoImages false /MonoImageDownsampleType /Average /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /PDFX1a:2001 ] /PDFX1aCheck true /PDFX3Check false /PDFXCompliantPDFOnly true /PDFXNoTrimBoxError false /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (U.S. Web Coated \050SWOP\051 v2) /PDFXOutputConditionIdentifier (CGATS TR 001) /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /False

/CreateJDFFile false /Description

Ax2012 Enus Devii 01

Documents

Transcript of Ax2012 Enus Devii 01