Visual Studio Tools for Dynamics GP – A Weird Flaw/Limitation


I must first admit that I faced this issue (or may be flaw…!?!?!?!) only now after all these years of VS Tools development expertise.

The issue is this: I want to write a custom code on two events; SOP Entry Print Button and POP Entry Print Button. When I initialise the event method for SOP Entry Print Button, following is how it generates the code:

Snip20130221_4

And the event method gets created as follows (if you use TAB to create the methods automatically):

Snip20130221_5

After above, when I try to initialise an event method for POP Entry Print Button, following is how it generates the code:

Snip20130221_6

When you try to press TAB to create the event method automatically, it takes you to previously created method.

Because, print buttons on both windows (SOP Entry & PO Entry) have same name technically, which is WindowPrint, VS Tools doesn’t understand both are from different windows and it just goes on to refer to one single method instead of two.

But you are not stuck there forever. Simple solution is to manually name your method initialisation with logical names, like below:

Snip20130221_7

And like below:

Snip20130221_8

Visual Studio Tools for Dynamics GP does not restrict you from using only names that it suggest.

VAIDY

Developing Microsoft Dynamics GP Business Applications – Book By Leslie Vail


DMDGBA

UPDATE: Author of this book, Leslie Vail, has got a post on her blog (Dynamics Confessor Blogspot). Link now added here to her own post: Published at last! Developing Microsoft Dynamics GP Business Applications.

I had the privilege to be a part of the technical reviewing of this amazingly informative book: Developing Microsoft Dynamics GP Business Applications.

This book is penned by one of the most experienced GP personality and multiple times MVP, Leslie Vail. Packt Publishing has published this book.

I strongly recommend this book to all GP developers/consultants who would like to know how to develop anything with regards to Dynamics GP; be it a new feature addition, a feature modification or just a cosmetic enhancement.

Thanks Leslie Vail for this wonderfully written book with every single important concept being covered.

VAIDY

OFF TOPIC: Please Do Not Learn To Code


This is an interesting post on Coding Horror site.

Jeff Atwood expresses his thoughts on why we should not advocate learning to code for the sake of learning how to code.

Quite nice post up there for a read.

VAIDY

Choosing a Development Tool for Microsoft Dynamics GP


Microsoft had published a white paper on choosing a development tool for Microsoft Dynamics GP, at the time of GP 2010 release.

Though it’s pretty old, it’s still valid even now to refer to this white paper.

Download it here: Microsoft Dynamics GP 2010 White Paper – Choosing a Development Tool

Soon, we would all be getting ready for Microsoft Dynamics GP 2013 and I am sure, this white paper would still be valid. 🙂

VAIDY

Adding Customer Item User-defined Fields to SOP Invoice – Mariano


Another excellent post up there on Mariano’s blog, which explains how to add customer item user-defined fields to SOP invoice.

The customization is done using Support Debugging Tool (SDT) to achieve this.

There is an interesting point which Mariano mentions there, which is not about the topic itself, but about how clients have started demanding things from us, consultants, which shows how much clients are aware nowadays.

Modifier with VBA would have been the BEST and easy option for any developer or consultant for this functionality. But looks like the client was strictly against it because *it’s not supported on Microsoft Dynamics GP 2013 Web Client*. 🙂

But that demand indeed had led to another superb piece of customization using SDT.

VAIDY

eConnect Vs GP Web Services – Chris Roehrich


This is an awesome post from Chris Roehrich on Developing For Dynamics GP blog.

The post explains very neatly (and in detail) about the differences between eConnect for GP and Web Services for GP.

And which one to use or not to, is up to you after you read this post. There are some interesting short discussion on the comments section, so do read the comments as well.

That’s an excellent post, Chris. That surely would have answered several questions from users/consultants across the world.

VAIDY

Perils of Using of DEX_ROW_ID on Customization / Integration – David


This one is certainly a nasty issue, if we are going to use DEX_ROW_ID value on customization or integration.

I have personally fallen into a trap by using DEX_ROW_ID on my customization. But now, it’s all wisdom out of that bad experience.

Only time when I normally depend on a DEX_ROW_ID is to sort records to understand which record was entered last in the table. That itself may not be always correct. So we may have to add other logical fields that are relevant to a particular record.

For instance, if I have to list out transactions entered on a particular day and check in the order in which the records are created, I would use the Transaction Date and DEX_ROW_ID as SORT ORDER.

There are many other reasons, but restrict yourself to use DEX_ROW_ID only for selecting records and analyze it.

VAIDY

Data Types Matter – Steve Jones (SQL Musings)


Another article which stresses on using relevant and optimal Datatypes instead of regular and unnecessary ones. There is an illustration which explains realtime.

The article, Data Types Matter, is written by Steve Jones on his blog SQL Musings.

Must read for all Developers out there.

VAIDY