The importance of linking your fields to their prompts in Microsoft Dexterity


When you have been doing Dexterity development for as long as I have been, a lot of things are automatically assumed and taken for granted when developing an add-on solution.

A recent article by Patrick Roth over at Developing for Dynamics GP got me thinking on a common mistake that Dexterity developers (novice and experienced!) run into when developing add-ons for Microsoft Dynamics GP, or even in their own standalone solutions.

In his article, Patrick points out the fact that you can change the caption of a field -- in Dexterity lingo, this is called a prompt -- by using VBA. The code he published can be generalized as follows:

Generic Private Sub Window_AfterOpen()

Private Sub Window_AfterOpen()
fieldname.Caption = "Some Prompt Here"
End Sub
So, why the need to link fields with their corresponding prompts? -- I will get back to Patrick's article later and it's relation to this topic.

The answer is simple. Because they are a number of field properties that directly affect the behavior of the linked prompts. These properties are:

Visible. This property allows a developer to establish whether a field will be shown or hidden on a window interface. Visibility can be controlled via the Dexterity statements hide field and show field. When the hide field statement is executed the field's Visible property is set to false and the linked prompt is automatically hidden along with the field. The reverse effect will occur with the show field statement.

Editable. This property allows a developer to establish whether a field will allow data entry or not. Editability can be controlled via the Dexterity statements lock {field} and unlock {field} -- the keyword field is optional. When the lock statement is executed the field's Editable property is set to false and the linked prompt is automatically grayed out along with the field. The reverse effect will occur with the unlock statement.

Required. This property allows a developer to establish whether a field will force the user to enter data in it or not. Since the font color and style of a required field can be controlled via Dexterity with the Field_SetRequiredFormat() function, it is absolutely necessary to link the field to it's prompt for the visual effects to take place when toggling the Show Required Fields mode under User Preferences.

NOTE: This applies to integrating applications. For standalone applications please check the Dexterity help file for the Field_SetRequiredStatus() function.

This brings me back to Patrick's article and the generic code posted above. If you don't link your fields to your prompts, you will not be able to change the caption via VBA! fieldname.Caption allows a VBA developer to control a field's linked prompt created with Dexterity.

This simple ommission can turn an ordinary customization request into a semi-development project, since most likely, you will have to go back to Modifier, link the field to the prompt, not to mention wrangling with the Dynamics GP systems administrator for security permissions to your modified object. If you are talking about 5 users, this may not be an issue, but in environments with 100's of users and SOX compliance issues you may end up kissing your contract goodbye!

So the next time you start dragging fields to a window and adding prompts, think... "Have I linked all my fields and prompts?"

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Comments

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

eConnect Integration Service for Microsoft Dynamics GP 2010