Let’s look at some examples using a fictitious Add-On solution called DuraPlus

The first release of a DuraPlus object could be version listed as follows:

DUP1.00

The same release of this base DuraPlus object with additional customer specific modifications for the fictitious company Crocker International, could be version listed as follows:

DUP1.00,CRO1.00

Microsoft version list information should remain untouched at all times. I have seen objects in databases where the base Microsoft elements have been completely removed!

Any change that modifies a base Dynamics NAV object should be reflected by appending to the existing version list. It should always be easy to establish what version of a base Dynamics NAV object a change has been built upon.

The following example shows the version list from Codeunit 22 in a GB NAV 5.00 database which has been modified, again by the fictitious DuraPlus add-on solution:

NAVW15.00,NAVGB4.00,DUP1.00

Subsequent changes to objects should be shown by increasing the major and/or minor elements of the existing version list element, and not by replicating the element each time a change is made.

Correct: NAVW15.00,NAVGB4.00,DUP1.01
Wrong: NAVW15.00,NAVGB4.00,DUP1.00,DUP1.01

I have seen the second method used before; but this quickly becomes unwieldy, hard to read and for an object that over time may be subject to many changes, the maximum 80 character length of the version list is going to be an issue.

Version Listing of Service Packs and Hot Fixes

Using the Microsoft approach to version listing in Dynamics NAV, service pack levels are not reflected in a version list until an object has first had a service pack applied.

So rather than write DUP1.00.00.00 for the first release of an object, you would list as follows:

DUP1.00

When first service packed, this would be reflected in the version list as follows:

DUP1.00.01

A subsequent hotfix to this same object would be reflected as follows:

DUP1.00.01.01

Not adding superfluous service pack and hotfix elements to the version list until they are actually relevant helps to reduce the overall length of the version list and makes for a clutter free Object Designer.

Version List Prefix

In terms of a version list prefix I try and keep it simple, either using three or four letters from the customer’s company name or a similar size prefix to represent the product name if it is an Add-On solution.

I have seen people use the developers name as a version list prefix; not really the correct approach in my opinion.

Author information can be specified in the Documentation trigger and in external change log documentation.

I’m sure we’ve all seen this one. Your new form, buttons lined up nice and neatly in the bottom right hand corner, all looks well and good until somebody decides to maximize it, then hey presto, one or more of the buttons shoot off screen somewhere.

Buttons need to be glued bottom, right to avoid this. So, run your form and maximize it just to check you’ve got your glueing set correctly.

There will always be one that escapes though, so keep your eyes peeled.

2. Subform forms and SubForm controls with different widths and/or heights
This is another quite common mistake which can cause problems with disappearing scroll bars amongst other things.

The basic rule is, if you’re designing a form which has a subform (e.g. a Sales Order or Purchase Order type form) make sure that the subform control and the subform itself are both the same width and the same height.

3. Extra space to the right and/or the bottom of forms
People will often design a form, expand the width and/or height of the form to make some room to move controls about whilst in design mode.

This is fine as long as things are set back as they should be when completing design of the form.

The rule is: 2 grid spaces of free air to the right and 2 grid spaces to the bottom.

4. Non-standard HeadingHeight’s on TableBox controls
I must confess to this as being one of my biggest annoyances and yes, some people may disagree but I believe the HeadingHeight property on a TableBox control should be left well alone.

It seems to be a common thing for people to increase the size of headings on table boxes when designing new or modifying existing forms, Sales Order and Purchase Order subforms being prime targets.

Now my argument against doing this is that there is simply no need. The choice should just be left to the user, if he/she wants more room to read the field names on the sales order subform for example, then they can quite easily increase the height of the columns and this setting will be saved in their zup file.

Bottom line: Let the zup file do its job.

5. Overuse of colour
This one speaks for itself really. People will often get the coloured crayons out and believe it to be an exercise in useablity and good gui design. Believe me, I’ve seen some quite hideous uses of colour on forms and it rarely never adds anything in terms of useability gains or user acceptance/experience.

Granted Microsoft themselves use splashes of colour here and there, but it is limited to some red text maybe to represent a negative number. This i would say is ok and quite subtle. Making the background colour of a column or text box bright green or yellow isn’t.