Category Archives: Dexterity Programming

Dexterity 2010 R2 Supports Microsoft Team Foundation Server (TFS)

Posted on by

That’s a GREAT GREAT news from Microsoft about Dexterity. Inside Microsoft Dynamics GP blog informs us that Dexterity 2010 (v11) R2 will support Microsoft Team Foundation Server (TFS).

What this means? Dexterity supported only Microsoft Visual SourceSafe (fondly called VSS), which has been used under discontinued support from Microsoft. Those who wants to streamline Dexterity Development on their organizations, found it very difficult to use something which is not supported by Microsoft but Dexterity.

Microsoft introduced Team Foundation Server (TFS) which is advanced and very easy to use and maintain. With Dexterity 2010 R2 release, the biggest gap in Dexterity Development history is now filled.

VAIDY

Advertisement

Difference between Saving & Compiling a Dexterity Code

Posted on by

I was quite taken back by this very difference of Saving a Code and Compiling a Code in Dexterity.

Alright, let me explain.

I was demonstrating a customization my team yesterday and I had to change some code to show a Window on a Button Click event. The only code I had to change in that event script was to add the following statement:

open window [Window_Name];

And even a Non-Dexterity developer would tell us that the above statement do not contain any error, unless the window [Window_Name] do not exist at all. But in my case it did.

I SAVED the code and closed the Project. Created a Chunk and deployed it. To my confusion, the code piece that I added never worked. I was confused to say the least. Why not? I did add the code and created the chunk.

That’s where I made a mistake. I SAVED the code instead of COMPILING it. Only when we compile a Dexterity Code, it gets effective. Saving the code won’t affect the business logic and it would not have reflected in the chunk on that portion.

So, SAVING a code is totally different from COMPILING a code.

VAIDY

Temporary Tables in Dexterity – David

Posted on by

Excellent post for all Dexterity Developers.

David walks us thru’ the Temporary Tables concept in Dexterity. It explains the types of Temp. tables and when to use what type.

Another simple and complete reference post from David for all of us.

Read it here: Working with Temporary Tables in Dexterity.

VAIDY

DexSense – Intellisense For Dexterity – Tool Updated

Posted on by

Before anything, this one’s got to be first.

For all of us, Dexterity Developers, this excellent tool is a boon. This tool has got an update and the new version is v1.8.

David’s article here for more details: Intellisense for Dexterity – DexSense 1.8 Released.
Mariano’s addendum here: Intellisense for Dexterity… the gift that keeps on giving.

Do start using it if you are already not. It certainly saves tons of time in typing.

VAIDY

Lock PO Number Field in PO Entry

Posted on by

There are several reasons for GP Users to disable PO Number field in PO Entry, in order to not override the Next PO Number sequence in POP Setup.

And there are several methods and tools (Dex, VBA, etc) in accomplishing that. I have tried my bit in getting this functionality extended in PO Entry form.

Please find & download the chunk here: Disable PO Number in PO Entry

PRODUCT DETAILS:
1. Version: 10.4.4
2. Name: PO Number Disable
3. Product ID: 1983
3. Dictionary: POD.DIC
4. Forms Dictionary: F1983.DIC
5. Reports Dictionary: R1983.DIC

COMPATIBILITY:
1. Compatible GP Version: Dynamics GP 10.0 SP4

IMPORTANT:
1. This chunk is not a part of Microsoft Dynamics GP Products. This is a Custom Chunk developed by me.
2. I will be more than happy to improve this based on Users Feedback, but I cannot assure that all feedbacks would be met immediately or within a desired time.
3. This particular functionality works only in PO Entry Form.
4. Test this once in your Test Environment before using it on your Live Environment.
5. Please make sure that you have read the Limitations section in this post completely and you have understood that.

FUNCTIONALITY:
1. Once user selects a PO Type (Standard, Blanket, etc) and bring the focus to PO Number field, this chunk will allow GP to generate the Next PO Number from the POP Setup.
2. Then it immediately locks the PO Number field.
3. Then it takes the focus back to Buyer ID field.
4. Once you save the PO, it again releases the field.

LIMITATIONS:
1. Since the PO Number field had to be locked from user changing the PO Number value, users won’t be able to enter any PO Number directly on the PO Number field.
2. For instance, if a user wants to open an existing PO Number which he/she knows readily and does not require a Lookup, this functionality may prevent them from entering that PO Number.
3. In a nutshell, to edit an existing PO, user must use PO Number Lookup at all times.

I will update this post with an upgraded chunk as and when a feedback is addressed. I will also update the link above by adding a Readme File explaining the removal of this product from GP Folder and Dynamics.set.

VAIDY

RW_DateToString – David

Posted on by

The first thing a Dex Developer would do once he/she learns Dex programming is to start becoming curious and write their own functions / procedures to meet the requirements.

I am certainly not against it and I myself started off my programming career like that. But we must also understand that when we have in-built functions that can do what we want, we don’t have to lose our time in recreating the same logic.

RW_DateToString function would certainly save us lot of time. And it does have almost all much used formats to display a Date on the report.

David details this function in his article: Display Dates in Any Format On Report.

VAIDY

Currency Values Returned By VBA To A Report – David

Posted on by

Such a weird issue, but since it’s said to be known, we can’t do much about it. But David gives us an alternate option to tackle this.

Read it here: Currency values returned by VBA to a report are multiplied by 10 or 100.

Must read for Developers.

VAIDY

DexSense – Intellisense in Dexterity by Tim

Posted on by

Read it on your own to know what it is and how it got visualized:

Intellisense for Dexterity – Ask and You Shall Receive (David)
DexSense: IntelliSense for Microsoft Dexterity (Mariano)

AWESOME product. Not long ago, we were voting for this. Even before we got over that voting, we are having a product with basic and most required functionalities, which does what we want.

Go ahead, get it, test it and give your constructive feedbacks to get this evolving.

VAIDY

Carefully Place Variables Assignment in Dex

Posted on by

This post is right after a coding correction done in one of my customizations.

There is a form which needs to be opened from both SOP Entry & SOP Inquiry. Based on the source, I had to either lock or unlock certain fields, exactly like how SOP Entry & SOP Inquiry windows work.

I created a GLOBAL field called “SOPSource” and created two Startup trigger scripts, namely SOP_Entry_Open_Addl and SOP_Inquiry_Open_Addl on SOP_Entry and SOP_Inquiry respectively. Inside each script, I wrote a piece of code like below:

open form SOP_Additional_Info;
SOPSource of globals = “ENTRY”; {“INQUIRY” for SOP_Inquiry trigger script}

And once my form is opened, in the Window_PRE event script, I had validated the SOPSource GLOBAL field and made sure that I locked or unlocked the appropriate fields.

Now, can anyone guess what was wrong with the above piece of coding?

Mistake: I wrote the GLOBAL field assignment after “open form” statement.
Reason: The above piece of code first opens the form and then assigns the SOPSource Global field with some value. By the time, it assigns the value, the form is already open and WIN_PRE event is already executed. Due to which, my “SOPSource of globals” will always contain an empty string value.

DUH…

Correct Way of Writing:

SOPSource of globals = “ENTRY”; {“INQUIRY” for SOP_Inquiry trigger script}
open form SOP_Additional_Info;

Those who are new to Dex programming, understand that as soon as a “open form” statement is executed, the form is immediately opened and do not wait for the rest of the calling script’s statements. If there is any dependency in the opened window for other statements in a calling script, we must ensure that these statements are written before we open this window.

VAIDY

Displaying 3rd Party Series’ Reports in Report Template Maintenance – Patrick

Posted on by

Boy, I never thought this “3rd Party” series would have such an impact (be it simple or silly or critical).

Patrick explains us one such very important but simple issue: Using 3rd Party Series Reports in the Report Template Maintenance Lookup Window

I have to now check all my customizations’ resources which are created under this 3rd Party series.

And when I reassign the series for those resources, I am not certainly going to place it in PROJECT series. As Patrick quips in his post in one place, if you read it completely.

VAIDY