Dynamics NAVAX

I have seen many ways of modifying standard code and how commenting is done. The best practice is to make as little change as possible or as little impact to the standard solution as possible. Otherwise, making it stand out and the next person can clearly see the difference between standard code and custom code. Looking at how the Feature pack incorporates the Extension model is very interesting. See the screenshot below. You can see how the standard code is commented out with the <SYS> tag. Then the changes are added with their tag <PSA> or <RETAIL> as illustrated in the screenshot below. Now if you look at the compare, it stands out. If for some reason you had to revert your custom code back to the original. You just delete your code between your tags and uncomment the <SYS> tags. On msdn there is a best practice on how to do code commenting. http://msdn.microsoft.com/en-us/library/cc967435.aspx It clearly says: Do not use multi-line syntax /* … */ fo...

Make use of form best practice when you are created/updating forms in AX 2012. It isn't 100% bullet proof solution but it does get rid of your most common form problems. Also keep in mind that Microsoft doesnt deliver all their forms conforming to the Form best practice. Some form are just different. Right click on the form. Add-Ins > Check form style best practices The form will open up. The style you set in the form design property will be defaulted and analysed. Some basic violations can be fixed right from this form. For example, the New button label must be @SYS000001 (not the right label id but you get the idea) then you click the Fix violation button. This will update the form and fix it for you. Notice below CustTable form, it doesn't 100% conform to this but it is not intended to be 100%. It is there to make sure you follow the form styles and the look&feel of the system is uniform. Reference: http://msdn.microsoft.com/en-us/library/hh397319.asp...

I would highly recommend this parameter be turned on all development environments. It will help you catch invalid field access through code before they reach testing or production.

I had recently asked this question to Microsoft and thought I should share. Question: I am trying to make sense of the security AOT property ManagedBy. I can understand if I have to put something there to indicate it is being managed manually but why does best practice accept only the two values (that I found): Manual CodeAnalysis I have searched on msdn for more help but all it says is: ManagedBy Optional This property is for use by automation tools. http://msdn.microsoft.com/en-us/library/gg731858.aspx Answer: This property is used by one of our automation tools internally. We were using it simply so that we could write automations to help the feature teams to make sure they had all of the new security aspects covered for their objects. It could be used by a custom tool that checks the objects to make sure that all the security is implemented correctly for the objects by checking if the object should be managed manually or automatically.

On forms you want to set controls ie enabled or visible You can do this by specifying the control name or the id but the best way is to do it like this: element.design().control(control::Name).visible(false); "control" is a system enum that maps the name to the id. Another advantage of doing it this is, you don't have to set the AutoDeclaration on the form control.