Developing for Dynamics GP

Blast from the Past - The Inside Track - January 2001

David Musgrave — Wed, 30 Dec 2009 01:00:00 GMT

This is article 5 of 10 from the Blast from the Past - The Inside Track Series.

This newsletter from Karl Gunderson was sent out in January 2001.

The Inside Track
"COM See, COM Saw"
January 2001

If my titles get to be too cute, blast me some e-mail. That said I really like the title this month. You see, I remember only about a half dozen phrases from the French I learned 30 years ago and this phrase has stuck in my head. "Comme ci, comme ça" which is a response to the question "How are you?" The answer means "so, so". I've mangled the spelling for this month's title to reflect the topic COM (Component Object Model).

Inside ~~Great Plains~~Microsoft?

I'm betting that you've noticed that while my column is called "The Inside Track", almost all of the technologies I've been talking about are straight out of the Microsoft playbook. So, you say, why didn't I just call this column "The Outside Track"? By now you've heard that Microsoft has signed an intent to acquire Great Plains so I could just argue that the outside is becoming the inside. Wouldn't that be a copout? And the truth is that I heard about the acquisition on December 21^st just like everyone else. Oh, I heard one person with a rumor a week or two before, but I dismissed it. I'd heard that one before!

No the real reason that I've been focusing on Microsoft technologies in this column is just what I said in my first column. At Great Plains, we are building our next generation products on Microsoft's family of technologies called .NET. Nonetheless, I've started to feel that I need to bring some of what I've been writing about together with what we are doing in development at Great Plains.

COM in Common

When two programs talk to each other its called Inter-application Communication (IAC). All of the .NET languages run in the Common Language Runtime and use the .NET Framework class library. I haven't delved into the IAC part of .NET myself, so I don't know much about the specifics except one. When the two programs are on different machines, the preferred IAC mechanism is XML over HTTP using a defined format called SOAP (Simple Object Access Protocol).

Today, we can use COM for the same task. COM defines how two chunks of code communicate. If one chunk is in an .EXE and the other in a .DLL, this is call in-process COM. If both chunks are in .EXE's then this is called out-of-process COM. If both chunks are in .EXE's but on differentmachines, its called Distributed COM or DCOM. You probably knew all that.

So DCOM and SOAP are intended to accomplish pretty much the same thing. While I think we can assume that Microsoft would have liked COM to be ubiquitous, the Internet has dictated that HTTP and XML will be the IAC mechanism of choice.

Just like any technology, there will be a time while COM continues to be the dominant IAC mechanism. So we'll need a transitional technology. What is it? It's a part of .NET that Microsoft calls COM Interoperability or COM Interop for short. So thinking about COM still makes sense today.

COM has existed in Dexterity for sometime now. Continuum is based on COM. Of course Continuum is about an external application reaching into Dexterity using COM. Dexterity has been able to use outgoing COM via VBA (Visual Basic for Applications). And we know how useful that is!

But SanScript programmers have been left out of the picture. You could always figure out a way to pump data from Dynamics or eEnterprise into a mail merge in Word or an Excel spreadsheet, but it hasn't been as clean as you (or we) might like. Well take heart because here comes SanScript based COM. That's right boys and girls, COM right from within native Dexterity scripting.

Now you may see why I had a lot of fun with this month's title! COM is the tool we see today, but it's not the tool of choice in a .NET/Internet world of tomorrow. While COM will be with us for a while, in the future COM will be the technology we saw in the past. In other words a "so, so" technology. I know, way too cute.

Now that you've heard the good news about COM in Dexterity, let's look at how it's done.

Binding and Type Libraries

There are two basic ways of talking to a COM component (or ActiveX if you prefer): early bound and late bound. In Visual Basic you use early (compile time) binding by adding a reference (menu Project->References...) to your project and then using the name of the component to declare a variable:

Dim rs As ADODB.Recordset

In this example, ADODB refers to a type library that contains a description of the RecordSet component. A type library tells your development environment which components are available and the components properties, methods and events. You may remember last month when we talked about how the new .NET language C# handles these issues. A Visual C++ programmer creates a type library by compiling a .MDL (short for MIDL the Microsoft Interface Definition Language) file into a .TLB (type library) file. If you write a component in VB (ActiveX .EXE or ActiveX .DLL project type), VB builds the type library for you. Sometimes the type library is a separate file and sometimes its included right in the .EXE or .DLL (or .OCX). Wherever it comes from, if you're using early binding, the type library is used by the VB compiler to construct the correct call to the COM component. Because this work is carried out at compile time, its fast at runtime.

On the other hand, if you declare a variable as:

Dim rs As Object

Then the type of the component won't be known at compile time, this is known as late (at runtime) binding. Because constructing the call to the COM component must now take place at runtime it's slower. If you've used a scripting language (VBScript or JavaScript), you've used late binding, it's the only choice.

COM in Dexterity

Dexterity handles referencing a type library with the new "import" statement on the first line of a script.

import "<filename>";

or:

import "<GUID>[,version]";

For example:

import "shell32.dll";

or:

import "{00000205-0000-0010-8000-00AA006D2EA4}";

In Dexterity you can also use either early or late binding. If you use the import statement, you can declare a variable of a specific type and create an object of that type for early binding:

local GPData.Customer Cust;
Cust = new GPData.Customer();

Similarly in VB, you would write:

Dim Cust as GPData.Customer
Set Cust = New GPData.Customer

To use late binding in Dexterity no import statement is needed and you declare the variable to be of type "reference":

local reference Cust;
Cust = COM_CreateObject("GPData.Customer");

In VB no reference is needed and the variable type is "Object":

Dim Cust as Object
Set Cust = CreateObject("GPData.Customer")

Calling a method in Dexterity is easy:

b = Cust.Load('(L) ID');

In VB:

b = Cust.Load(txtID.Text)

Last is reading from and writing to a property. In Dexterity:

'(L) Name' = Cust.Name;
Cust.Name = '(L) Name';

In VB the terms are "get" and "let", but the syntax is very similar:

txtName.Text = Cust.Name
Cust.Name = txtName.Text

For the advanced student, there is a COM_GetObject() function in Dexterity that is similar to VB's GetObject() and you can specify the server in an optional second argument to COM_CreateObject() for DCOM.

Unfortunately, COM in Dexterity is not in the current product so you can't try my examples [Ed: It is now]. And my example is purposely simple to avoid some of the holes in the current partial implementation. To give you a little more context for the examples, I'm going to include the code for the VB COM component I used with Dexterity, the VB test program I used to test the COM component and then the SanScript for exactly the same program in Dexterity.

The VB COM Component

In VB, create a new ActiveX DLL project, name it GPData, paste the following code into the class module and name the class module Customer. NOTE: you will need to modify the ConnStr to refer to an appropriate ODBC data source name and you will need to add a reference to ADODB. ADODB is named something like "Microsoft ActiveX Data Objects 2.X Library" when you are in the References window in VB.

Option Explicit

Private Const ConnStr = "DSN=TWO;UID=sa;"

Private m_ID As String
Private m_Name As String

Public Property Get ID() As String
	ID = m_ID
End Property

Public Property Let ID(ByVal NewID As String)
	m_ID = NewID
End Property

Public Property Get Name() As String
	Name = m_Name
End Property

Public Property Let Name(ByVal NewName As String)
	m_Name = NewName
End Property

Public Function Load(ByVal LoadID As String) As Boolean
	Dim rs As ADODB.Recordset

	ID = LoadID
	Set rs = New ADODB.Recordset
	Call rs.Open("select CUSTNAME from RM00101 where CUSTNMBR = '" + ID + "'", ConnStr, adOpenStatic, adLockReadOnly, -1)
	If rs.BOF Or rs.EOF Then
		Load = False
	Else
		m_Name = rs.Fields("CUSTNAME")
		Load = True
	End If
	rs.Close
	Set rs = Nothing
End Function

Public Function Save() As Boolean
	Dim cmd As ADODB.Command
	Dim recs As Integer
	Set cmd = New ADODB.Command
	cmd.CommandText = "update RM00101 set CUSTNAME = '" + Name + "' where CUSTNMBR = '" + ID + "'"
	cmd.CommandType = adCmdText
	cmd.ActiveConnection = ConnStr
	cmd.Execute recs
	Save = recs = 1
End Function

The VB Test Program

Create a Standard EXE project, add the controls and set their names as given below. If you add the COM component and the test program to the same Project Group in VB, it's a lot easier to debug and you don't need to "make" either program to run it. You will also need to add a reference in the test program to the COM component as "GPData" in the References window. My version of the VB test program has 6 controls and 4 labels. The 6 controls are named: txtID, txtName, cmdLoad, cmdSave, cmdLoadUntyped and cmdSaveUntyped. Here is what my form looks like at run time:

If you have used exactly the same names for the controls, you can open a code window for the project and paste the following code in directly.

Option Explicit

Private Sub cmdLoad_Click()
	Dim Cust As GPData.Customer

	Set Cust = New GPData.Customer
	If Cust.Load(txtID.Text) Then
		txtName.Text = Cust.Name
	Else
		txtName.Text = ""
		MsgBox "Customer ID not found"
	End If
	Set Cust = Nothing
End Sub

Private Sub cmdLoadUntyped_Click()
	Dim Cust As Object

	Set Cust = CreateObject("GPData.Customer")
	If Cust.Load(txtID.Text) Then
		txtName.Text = Cust.Name
	Else
		txtName.Text = ""
		MsgBox "Customer ID not found"
	End If
	Set Cust = Nothing
End Sub

Private Sub cmdSave_Click()
	Dim Cust As GPData.Customer

	Set Cust = New GPData.Customer
	Cust.ID = txtID.Text
	Cust.Name = txtName.Text
	If Cust.Save Then
		txtID.Text = ""
		txtName.Text = ""
		MsgBox "Customer Saved"
	Else
		MsgBox "Customer ID not found"
	End If
	Set Cust = Nothing
End Sub

Private Sub cmdSaveUntyped_Click()
	Dim Cust As Object

	Set Cust = CreateObject("GPData.Customer")
	Cust.ID = txtID.Text
	Cust.Name = txtName.Text
	If Cust.Save Then
		txtID.Text = ""
		txtName.Text = ""
		MsgBox "Customer Saved"
	Else
		MsgBox "Customer ID not found"
	End If
	Set Cust = Nothing
End Sub

The Dexterity Test Program

The Dexterity version looks almost the same as the VB version.

There are 4 scripts on the form, one for each button. If you were actually going to run this program, you would need to know the GUID created by GPData.dll replacing mine (hint: use OLE View in Visual Studio Tools) or put the path (either relative or absolute) to GPData.dll in the import statements.

First, the "Typed Load" button.

import "{0E0B0D9E-A85D-4248-85BD-ECC2B3C0A8F3}";

local GPData.Customer Cust;
local boolean b;

Cust = new GPData.Customer();
Cust.ID = '(L) ID';
b = Cust.Load('(L) ID');
if b then
	'(L) Name' = Cust.Name;
else
	'(L) Name' = "";
	warning "Customer ID not found";
end if;
Cust = null;

The "Typed Save" button:

import "{0E0B0D9E-A85D-4248-85BD-ECC2B3C0A8F3}";

local GPData.Customer Cust;
local boolean b;

Cust = new GPData.Customer();
Cust.ID = '(L) ID';
Cust.Name = '(L) Name';
b = Cust.Save();
if b then
	'(L) ID' = "";
	'(L) Name' = "";
	warning "Customer Saved";
else
	warning "Customer ID not found";
end if;
Cust = null;

The "Untyped Load" button:

local reference Cust;
local boolean b;

Cust = COM_CreateObject("GPData.Customer");
Cust.ID = '(L) ID';
b = Cust.Load('(L) ID');
if b then
	'(L) Name' = Cust.Name;
else
	'(L) Name' = "";
	warning "Customer ID not found";
end if;
Cust = null;

And last, the "Untyped Save" button:

local reference Cust;
local boolean b;

Cust = COM_CreateObject("GPData.Customer");
Cust.ID = '(L) ID';
Cust.Name = '(L) Name';
b = Cust.Save();
if b then
	'(L) ID' = "";
	'(L) Name' = "";
	warning "Customer Saved";
else
	warning "Customer ID not found";
end if;
Cust = null;

Talk Again Later

There you have it. While we build the new road with .NET, we are building bridges that will bring us all forward into that wonderful new Internet based world. I hope you're feeling better than just "so, so" about .NET. It will be an exciting and challenging trip, but even in software development, the fun is in the trip not the arrival.

Until next month, signing off,

Karl Gunderson
Technical Evangelist

The original newsletter is available as a pdf attachment at the bottom of this article.

David

Blast from the Past - The Inside Track - December 2000

David Musgrave — Mon, 28 Dec 2009 01:00:00 GMT

This is article 4 of 10 from the Blast from the Past - The Inside Track Series.

This newsletter from Karl Gunderson was sent out in December 2000.

The Inside Track
"See Farther, See Sharper" [Ed: Should be Further :-) ]
December 2000

Do you have a favorite ax? You know, musicians call their instruments an "ax". The equivalent for a programmer must be a programming language. I've used a lot of languages in my career, I'm sure you've used a few yourself. The progress of programming languages is a long and interesting topic but a bit esoteric for this column. I have an ax or two that I turn to repeatedly. Learning a new language is fun. OK, my wife tells me I'm a bit strange too. But I think its fun to see how I can write better programs more quickly with a new language.

As part of the .NET technologies, Microsoft has created a new language. C# is the name. C# introduces a number of interesting language innovations while preserving familiarity. While C# is almost as completely an object oriented language as the prototypical OO language SmallTalk, it talks and walks a whole lot like C++.

Before getting into some details about C#, let's take a quick look at the alternatives. Microsoft could have just enhanced C++ or VB or Java. In fact, if you look at .NET you'll see that there is something called Managed C++ and Visual Basic 7 (or VB.NET for short). The extensions to C++ are ugly since they were added using the double underscores that are required by the C++ standard for vendor specific extensions.

Likewise, the new VB.NET has the flavor of VB6, but there are LOTS of new features and concepts to make VB fully object oriented that make it more of a new language. The differences are even greater than the VB3 to VB4 transition.

Java could have been an alternative. Microsoft has been limited legally by lawsuits and technically (you can't call it Java if it doesn't follow certain strict limitations) in their effort to extend that language. However, JavaScript is one of the .NET languages, so you don't need to feel left out if you're a Java maven.

C# is more evolutionary than revolutionary, built on that rich language history. Borrowing the syntax of C++, C# integrates new concepts in a clean, modern language making C# an extremely productive language for writing real applications.

Common Language Runtime

One of the features of the .NET technologies is the Common Language Runtime (CLR). The CLR is similar to the Java Virtual Machine (JVM). Like the JVM, the CLR is an execution environment for your program that is machine and operating system independent. Programs destined for the CLR are compiled into Intermediate Language (IL) the "machine" language of the CLR.

Unlike the JVM, the CLR was conceived of as an execution environment for any number of languages. This isn't an original idea to Microsoft, compilers have been built that produce code for the JVM and cross-compilers are as old as the hills. And what is a compiler of not a translator from one language to another? The CLR currently has implementations for a number of languages and, not surprisingly, so does the JVM. The difference is that the CLR was designed to support a broad cross-section of language features; the JVM was only designed to support Java's features. To enable multiple programs to interoperate, the Common Language Specification (CLS) says which features of the CLR a program may use and interoperate with other programs running in the CLR. For instance, C# and the CLR support an unsigned 64 bit integer, but the CLS says that only signed 64 bit integers MUST be supported. The CLS reduces the burden on language developers and implementers that wish to allow their languages to interoperate.

One of the really nice things Microsoft has said about the .NET technologies is that they will be open and follow standards. And C# would not be very standard if it was only under the control of Microsoft. Microsoft, Hewlett-Packard and Intel submitted C# to the international standardization body ECMA (see http://www.ecma-international.org/ and http://msdn.microsoft.com/en-us/netframework/aa569283.aspx [Ed: Broken Links fixed]).

Components

I explain this much of the CLR so that you'll understand the significance and motivation for the language changes and extensions made to .NET languages and to motivate the real topic of this month's The Inside Track. Let's look at how C# supports building components!

What is a component? It's a piece of a software system. As a piece, it must work with other pieces. You need rules to allow pieces to work together. So now you see way the CLR and CLS are so important. If developer A wants to develop a component of a software system with C++ (say a heavy duty server component), another with VB (say a chunk of business logic) and another with JavaScript (say some code to handle Web pages), then they need well defined rules to allow all these parts to work together. Has this been possible in the past? Sure! Was it easy? Not on your life! Will it be tons easier with .NET? Yup, you just got your life back!

As I've mentioned before, Great Plains plans to build its next generation of products using Microsoft .NET technologies. At this point you may have guessed that we plan to write those products in C#. C# takes all the learning from VB, C++, Java, Delphi, COM and undoubtedly a lot of other source (hey, I don't work for Microsoft, I have to guess just like everyone else) to come up with a clean, new language for building components. I'm going to talk about 3 basics of components: properties, methods and events. If you've written a COM component (any language), written any VB or used an ActiveX component (.OCX) then you know why properties, methods and events are the key.

Properties represent the state of a component to the outside world. Methods are the means that the outside world uses to ask a component to perform some action. Events are the way a component lets the outside world know that something interesting has just happened. These three mechanisms are about 95% of what components use to work together to implement a software system. So lets look at how C# makes implementing and using each of these mechanisms effortless.

Methods

A method is nothing more than a function. Functions are basic building blocks of any software system. When writing a large software system, you have parts of the system you want exposed to other parts and parts that you don't want exposed. You might call these parts "public" and "internal". The public parts are those that another component in the software system may use, and the internal parts are those that they may not. The internal parts are part of your implementation of your component. In object-oriented terms, the public part is your interface. Encapsulation is the object-oriented concept that says you hide the internal details of your implementation. In the same sense then a component should expose a specific interface to other components and hide the internal details of how it implements that functionality. C# supports exactly this concept. Take a look at the following C# class definition:

public class TaxCalculator { public TaxCalculator(Location location) { this.location = location; } internal decimal TaxRate(TaxableType taxableType) { return TaxRate(DateTime.Today,taxableType); } internal decimal TaxRate(DateTime when, TaxableType taxableType) { TaxInfo taxInfo = new TaxInfo(when); TaxTable taxTable = taxInfo.RateTable(location); TaxRate taxRate = taxTable[taxableType]; return taxRate.Rate; } public decimal TaxAmount(TaxableType taxableType,decimal taxableAmount) { return TaxRate(taxableType) * taxableAmount; } Location location; }

The TaxCalculator class defines a public constructor called TaxCalculator () that sets the location. A constructor is used to initialize the state of a new object. The public method TaxAmount() relies on two internal methods to complete its work. The first TaxRate() method takes TaxableType and uses the current date to call the second helper method. The second TaxRate() takes two parameters and uses those parameters along with the location passed into the constructor to find the correct tax rate. If TaxCalculator where built into a .NET component, you would only see the two public methods, the internal helper methods would not be accessible outside the component.

By the way, having two TaxRate() methods is perfectly legal. Its called method overloading and C# knows which method to call based on the number and type of parameters used by the caller.

Properties

Properties of a component represent the data values that a component supports. Just like methods, properties can have the same visibility attributes. In addition, properties may be read/write, read-only or write-only. Components may need to react to a new property value or returning a property value may require some processing. To support these behaviors, C# includes syntax just for properties. Consider the following C# class:

class Temperature { public double Celsius { get { return (Fahrenheit - 32) * 5 / 9; } set { Fahrenheit = value * 9 / 5 + 32; } } public double Fahrenheit; }

The Temperature class allows the user to save and get a temperature in either Celsius or Fahrenheit and always returns the correct value. Strictly speaking C# calls Celsius a property and Fahrenheit a field. However, if Temperature were built into a component, two "properties" would be visible. Temperature works by always keeping the temperature value in Fahrenheit and converting to and from Celsius as needed. Though this is a very simple example, you can see the power to transform values, perform processing in response to changes and obtaining values. Perhaps getting a value might be implemented by reading a database!

Events

The last component technology that we will look at in C# is the event. Events, as I mentioned, can be used by a component to signal to the component's client(s) that something interesting has happened. Think about this: you have "customer" implemented by a component. You would like to notify the credit department whenever a customer has exceeded a credit limit. Good object oriented design says that Customer and CreditDepartment should be separate objects (components) that use well-defined interfaces to communicate. You don't want them tightly coupled. You could have your Customer component call a method in the CreditDepartment component, but that means that the Customer component must "know" about CreditDepartment objects. Not good, that's tight coupling. Alternatively, you could have your CreditDepartment object check the credit limit and current balance properties on each Customer object. The question is how often? If you have lots of customers, that's a lot of wasted effort. The solution is events! The Customer object could implement an OnOverCreditLimit() event or even an OnBalanceChange() event. Then the CreditDepartment object could "register" with the Customer objects its interest in being notified when the customer goes over his credit limit. Let's see how
this would look:

using System; public class Customer { public delegate void OverCreditLimitHandler(Customer customer,decimal amount); public event OverCreditLimitHandler OnOverCreditLimit; public Customer(int id,string name,decimal creditLimit) { this.id = id; this.name = name; this.creditLimit = creditLimit; this.currentBalance = 0; } public bool Purchase(decimal amount) { if(amount + currentBalance <= creditLimit) { currentBalance += amount; return true; } else { if(OnOverCreditLimit != null) OnOverCreditLimit(this,amount); return false; } } public int id; public string name; public decimal creditLimit; public decimal currentBalance; } class Test { static void Over(Customer cust,decimal amt) { Console.WriteLine("Customer {0}:", cust.name); Console.WriteLine("\tTransaction Amount = {0}",amt); Console.WriteLine("\tCurrent Balance = {0}",cust.currentBalance); Console.WriteLine("\tCredit Limit = {0}",cust.currentBalance); } static public void Main() { Customer cust = new Customer(100,"Karl Gunderson",100m); cust.OnOverCreditLimit += new Customer.OverCreditLimitHandler(Over); cust.Purchase(50m); cust.Purchase(60m); cust.Purchase(120m); cust.Purchase(50m); } }

I've included a complete working program in this case. I've implemented the Customer class as described, but not the CreditDepartment. The first thing to notice is the line that starts "public delegate". What's a delegate?? A delegate is a pattern for a method. You'll notice that the delegate is used in the next line to declare an event. The delegate describes the parameters of the event method. The event method is the method that will be called when the event is triggered. In this example, the method is called Over() in the Test class. Notice how the parameters of the Over() method match those of the delegate.

The next interesting piece of this program is the line in Main() that starts "cust.OnOverCreditLimit +=". This line subscribes Over() to the OnOverCreditLimit event. Now look at the Purchase() method in Customer. The second "if" statement checks to see if there are any subscribers to the OnOverCreditLimit and if there are, it calls them with two parameters: this and amount. This refers to the current object, the current Customer object in this case. You can see that the first "if" statement checks to see if the purchase would exceed the credit limit and either completes the transaction or triggers the event. Pretty neat!

Do it Yourself

I'm sure you're as excited as I am about the prospects of writing component-based software with C#. So go to http://msdn.microsoft.com/net/ where you'll find the ".NET Framework SDK Beta 1" download. The download contains everything you need to compile the code in this column. If you're more ambitious, you can visit: http://msdn.microsoft.com/vstudio/nextgen/beta.asp [Ed: Broken Link and Visual Studio .Net is already released] where you can order then entire Visual Studio .NET Beta 1 (including the Framework SDK if you don't want to download 111 MB!) on CD-ROM for the price of shipping, $12.99. [Ed: I don't think the offer still stands, but if you want to send me money....]

See sharper and see you next month,

Karl Gunderson
Technical Evangelist

The original newsletter is available as a pdf attachment at the bottom of this article.

David

Season's Greeting 2009

David Musgrave — Fri, 25 Dec 2009 01:00:00 GMT

Today I am definitely not working, but due to the magic of scheduling blog posts in advance, I can wish everyone a safe and happy holiday season.

Thank you very much for your support over the years and in particular during 2009.

David and the Developing For Dynamics GP blog team

Blast from the Past - The Inside Track - November 2000

David Musgrave — Wed, 23 Dec 2009 01:00:00 GMT

This is article 3 of 10 from the Blast from the Past - The Inside Track Series.

This newsletter from Karl Gunderson was sent out in November 2000.

The Inside Track
November 2000

Did you see the Blondie comic on September 11, 2000? Check it out on www.blondie.com. In case you don't have a browser just handy, I'll sketch it out for you. Frame 1, Dagwood is in bed and Blondie tries to wake him up with a gentle call "DAGWOOD!" Frame 2, Dagwood sleeps on, so Blondie calls more insistently, "DAGWOOD BUMSTEAD!!" Frame 3, Blondie is having no luck waking Dagwood. Blondie is fed up, so she calls "DAGWOOD BUMSTEAD DOT COM!!" Dagwood flies up vertically off the mattress saying "OMIGOSH! THAT MEANS BUSINESS!!"

So, after 70 years, Blondie and Dagwood have entered the Internet age. Have you? And of course while .COM indeed means business, there is no more important technology to the future of business on the Internet than XML. Yes, XML. Say it again, memorize it, make it your friend, and love it from the depths of your little programming heart. XML, it just rolls off the tongue!!

OK, so you've heard about XML (hopefully not for the first time just now) the Extensible Markup Language and you've got an idea XML is important, everyone says it is. Let's have some details.

XML is very simple. XML is complex. No contradiction here. Think about computers, they push around things called bits, just zeros and ones, nothing simpler in existence. It's the same with XML. XML is very simple, it's what you do with it that makes it complex. XML and HTML (Hyper Text Markup Language) both derive from SGML (Standard Generalized Markup Language). Like HTML, XML is text. XML looks a lot like HTML. XML uses a tag-like structure similar to HTML. Unlike HTML, XML is very carefully defined. Because XML is so carefully defined, it is easy for a program to parse. Because it's so simple, XML can be hard to understand. When was the last time you converted an integer represented as 32 binary digits to decimal in your head?

If you have a chunk of text that follows the rules of XML, you have an XML document. Here is one now:

<PEOPLE Type="not real">
<PERSON FirstName="Blondie" LastName="Bumstead"/>
<PERSON FirstName="Dagwood" LastName="Bumstead"/>
</PEOPLE>

If you want the formal definition of XML, I suggest you check out www.w3.org/xml. I hope you have several hours of free time! For an incomplete and less rigorous definition I'll give you some rules:

An element begins with "<", an element name, zero or more attributes and ">", for example "<PEOPLE>".
An element ends with "</", the same element name used to begin the element and ">", for example </PEOPLE>.
A "child" element may be inserted between its parent element's start and end. No part of a child element may extend beyond its parent's end. This means you can't write "<A> <B></A></B>".
If an element has no children there is an abbreviation possible. Such an element will start with "<", have an element name, have zero or more attributes and end with "/>", for example <PERSON Name='Karl'/>.
An attribute consists of an attribute name, "=" and an attribute value.
An attribute value begins with a quote (single or double), has zero or more characters not including the same quote, or ampersand and ends with a quote matching the one that started the attribute value. Use "&", "'" and """ in attribute values to represent the ampersand, single quote and double quote characters, respectively. For instance <COMPANY Name=""Red" Smith&s Software"> would produce a company name of "Red" Smith's Software.
Element and attribute names are made up from letters, digits, periods, dashes, underscores and colons.
XML is case sensitive. Beginning and ending element names much match exactly. The attribute names "Name" and "NAME" are not the same attribute.
Every XML document must have a single "root" element.

That's about 95% of the important rules for XML. You can pickup the rest by imitation. I was once told by a professional instructor that the best programmers were excellent thieves. So look for examples and steal!

To make these rules a bit more concrete, lets look at a slightly larger example.

<PEOPLE Type="not real">
    <FAMILY LastName="Bumstead">
        <PERSON FirstName="Blondie" Gender="Female"/>
        <PERSON FirstName="Dagwood" Gender="Male"/>
            <CHILDREN>
                <PERSON FirstName="Alex" Gender="Male"/>
                <PERSON FirstName="Cookie" Gender="Female"/>
            </CHILDREN>
            <PET FirstName="Daisy" Type="Dog"/>
            <NEIGHBOR LastName="Wooley"/>
    </FAMILY>
    <FAMILY LastName=" Wooley">
        <PERSON FirstName="Tootsie" Role="Wife"/>
        <PERSON FirstName="Herb" Role="Husband"/>
    </FAMILY>
</PEOPLE>

The element with name "PEOPLE" is the root of this XML document. It has one attribute with a name of "Type" and the attribute's value is "not real'. There are two child elements both "FAMILY". The first FAMILY consists of PERSON's with attributes of FirstName and Gender. The FAMILY also contains CHILDREN, a PET and a NEIGHBOR. The second FAMILY consists of two PERSON's with attributes FirstName and Role.

Pretty simple! Cut-and-paste the chuck of XML above into Notepad and save it with a name ending in .XML, e.g. People.XML. Now open or drag-and-drop that file in Microsoft's Internet Explorer. Or better yet, download XML Notepad from:

XML Notepad 2007 [Ed: broken link fixed]

I'm sure you noticed that the Bumstead family identified members by Gender and the Wooley family identified family members by Role. Just like in real life, various companies might refer to its workers as "employee", "team member", "associate", "staff" or any of a number of other names and lets not even consider other countries!! One solution might be to have standards, but perhaps even better is XSL (Extensible Stylesheet Language), or it big brother XSLT (XSL for Transformations), which allows you to transform one XML document into another XML document or an entirely different type of document. We'll definitely be looking at XSL/XSLT in a future column. As a quick example, here is a chunk of XSL (note that XSL is just a special type of XML document!) that will change a PERSON's Role attribute to an appropriate Gender attribute.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

    <xsl:template match="/">
        <xsl:apply-templates select="*"/>
    </xsl:template>
    <xsl:template match="*|@*|text()|cdata()|comment()|pi()">
        <xsl:copy><xsl:apply-templates select="*|@*|text()|cdata()|comment()|pi()"/></xsl:copy>
    </xsl:template>

    <xsl:template match="PERSON/@Role">
        <xsl:attribute name="Gender">
        <xsl:choose>
                <xsl:when test=".[.='Husband']">Male</xsl:when>
                <xsl:when test=".[.='Wife']">Female</xsl:when>
        </xsl:choose>
        </xsl:attribute>
    </xsl:template>

</xsl:stylesheet>

The line containing PERSON/@Role selects the Role attribute of a PERSON. The following lines replace it with a new attribute named Gender with values of Male and Female instead of Husband and Wife, respectively. Neat! If you want to try this out, there are a couple of steps to follow. First add the following two lines to the top of People.xml:

<?xml version="1.0"?>
<?xml:stylesheet type="text/xsl" href="people.xsl"?>

These are called processing instructions. The second line refers to "People.xsl". This is the XSL file that will be applied to the XML document when it is loaded. So cut-and-paste the XSL above into a file called People.xsl" in the same folder as People.xml. You'll want to use Internet Explorer, IE, 5.0 or later. To see the result of an XSL transformation you have two options. One is to load a couple of nice extensions to IE found at:

http://msdn.microsoft.com/downloads/webtechnology/xml/iexmltls.exe
[Ed: Broken Link, not required in current IE versions anyway]

Because another use of XSL is to transform XML into HTML, normally you don't want to see any XML output from an XSL transformation. The transformation performed above does not display anything because it only produces new XML! After all, when you run a program you don't expect the source code to showup in the output do you? The extensions above allow you to view the output of an XSL transformation and to validate an XML document. So, once you have installed the extension, you can right-click on the browser page, select "View XSL Output" and you can see the new XML with Role transformed into Gender.

Another way to view this output would be to put it into a browser window but then we'd have to tell IE how to format the XML, a somewhat tedious task. Another alternative is to save the output from the XSL transformation into a new XML file and use the default formatting that IE provides. That's what the following VBScript does (the result is in "People2.xml"):

Option Explicit

Dim xmlDoc     'As DOMDocument
Dim xslDoc     'As DOMDocument
Dim xmlOut     'As String
Dim fso        'As FileSystemObject
Dim xmlFile    'As TextStream

Set xmlDoc = CreateObject("Microsoft.XMLDOM")
Set xslDoc = CreateObject("Microsoft.XMLDOM")

xmlDoc.Load "People.xml"
xslDoc.Load "People.xsl"

xmlOut = xmlDoc.transformNode(xslDoc)

Set fso = CreateObject("Scripting.FileSystemObject")

Set xmlFile = fso.CreateTextFile("People2.xml")
xmlFile.Write xmlOut
xmlFile.Close

Now you know a bit about how XML looks. Perhaps you have begun to see that XML is a really, really good way of describing data! We haven't even touched on DTD's, XML Schema's and SOAP, among other XML related technologies. I guess you'll have to trust me or find out for yourself just how true a statement that is.

As some evidence for XML's value, consider these points:

The XML 1.0 standard was published in February of 1998, see www.w3.org/xml.
XML has been supported since Internet Explorer 4.0 and will be supported by Netscape Navigator when 6.0 releases.
XML is a core technology in Great Plains new release 6.0 of eCommerce, see http://www.greatplains.com/search/document.asp?link=pressreleases/ecommerce_r6.htm. [Ed: Broken link, product discontinued]
Several industry groups, see www.BizTalk.org, www.openapplications.org (formed in 1995, Great Plains is a member) and www.xml.org (formed in 1993), exist to promote XML and develop standard XML documents to facilitate exchange of data via XML.
XBRL (Extensible Business Reporting Language) is an XML based standard for exchange of financial information, see www.xbrl.com. Great Plains is a member of this organization.
XML will be a core technology in Great Plains next generation products!

XML love it, but never leave it.

Leaving you for now,

Karl Gunderson
Technical Evangelist

The original newsletter is available as a pdf attachment at the bottom of this article.

David

Mariano Gomez, the man, the "Source"

David Musgrave — Tue, 22 Dec 2009 01:00:00 GMT

For those of you who were at the Microsoft Dynamics GP Technical Conference 2009 in Fargo, North Dakota, USA recently, you would have had a chance to meet Mariano Gomez (Microsoft Dynamics GP MVP and my co-presenter) in person.

For everyone else, if you want to get to know little bit more about the man recently called the "Source" in a newsgroup post, you can have a read of his DynamicsWorld interview.

Thanks Mariano for being such a great part of the Dynamics GP community.

David

Blast from the Past - The Inside Track - October 2000

David Musgrave — Mon, 21 Dec 2009 01:00:00 GMT

This is article 2 of 10 from the Blast from the Past - The Inside Track Series.

This newsletter from Karl Gunderson was sent out in October 2000.

The Inside Track From Here to There
October 2000

In the last edition of The Inside Track, I introduced Microsoft’s .NET, Great Plains Platform Services and myself. This time, I’d like to talk about where the technology infrastructure at Great Plains has been, where it’s going and how we’ll all get there.

I don’t have to tell you that working with technology is a tricky business. It’s a moving target. On the other hand, technology doesn’t just appear from nowhere. People have been thinking about and working on the underpinnings of the technologies we use today for quite a while. For me, understanding the roots of technology helps to calm the panic I feel when faced with a mountain of new stuff to learn. Saying that doesn’t make the mountain smaller, the devil is in the details as they say. Still it gives me hope that I can understand what the heck is going on. Given that a little background can go a long way, lets look back at the technology in Great Plains’ products.

Way back in the beginning there was Great Plains Accounting (GPA). The first 3 versions of GPA ran under the UCSD (University of California, San Diego) P-System. The P-System was its own virtual operating system (OS). This meant that a program written for the P-System would run on any computer that supported the P-System. Hey, portable code! While the P-System had its advantages, it was a whole OS and made the user learn a new set of operating commands. OK for programmers (I love learning a new OS don’t you?), but yuck for the user. Starting with version 4, we moved GPA to native compilers on DOS and Mac. The application code was portable, enabled by a portability library we built at Great Plains. By using a different portability layer under the application code, we could allow GPA to interact with its underlying operating environment more directly. Still, GPA was essentially a text-based product. The Mac with its graphical user interface was gaining favor fast; Microsoft even “announced” Windows in 1983 (really, checkout http://sambadance.com/squeegee/ [Ed: broken link fixed]) and finally shipped a useful version (3.0) in 1990. By the late 1980’s the handwriting was on the wall, Great Plains needed a GUI based product. Building on the idea of a portable layer, a small group in the research department began to build an Even Better (EB) system. EB became what we know as Dexterity.

With Dexterity, Great Plains had a portability layer that it owned. In fact, we owned just about everything! We built the development environment including debugger, profiler and source code control. Well OK, part of source code control. We owned the controls, the buttons, checkboxes, text boxes and such. Well, that’s partly true too since we largely preserved the native look and feel of each OS, Windows and Mac. I could go on, but the point is that while Dexterity did a lot, we did have to pick and choose just what we put our effort into. I’m sure each of you has a pet feature you’d like to see in Dexterity, right? As Great Plains grows, we feel the need to provide well-rounded tools that have all the features a diverse group of developers require in a complex world.

So it’s that technology mountain again. Even corporations can see it and have to deal with it. When Great Plains started out, we built our products on top of the P-System to provided portability because we couldn’t afford to build it ourselves. Today, our next generation products will again be built on top of another company’s products. You see where I’m going … .NET is that technology platform. But of course this is nothing really new either, we built Dexterity using C/C++ compilers from Microsoft on Windows and Metrowerks and Apple on the Mac. We used database technology from Pervasive and Microsoft. And we’ve incorporated a number of other technologies along the way.

Why .NET? In a word, Microsoft! Think big company with a huge research budget, lots of very bright people, extensive knowledge of compilers, browsers, web servers, security issues, databases and on and on. On the other hand, when it comes to software for managing the financial side of a company, think Microsoft Money! NOT. That’s where Great Plains shines of course. Easy, Microsoft provides the technology and Great Plains provides the application. Done deal. NOT again! Anytime any significant piece of software is written, there are always multiple levels of abstraction. That’s where Platform Services comes in.

To use an obvious but not simple example, take security. .NET provides a security mechanism based on Roles. But how those roles are defined and used will be quite specific to a financial management application. Platform Services will build a security model that masks some of the complexity where it is not needed, entirely hides security where that is possible and exposes it where it is needed in a way that makes sense. Microsoft builds a generic security mechanism into .NET, but Great Plains makes it useful within the context of our industry.

Let’s further refine the security example. Within the Great Plains application, including your enhancements and modifications, a lot of security information can be implied by the reporting relationships defined in a Human Resources module or in the structure of the Chart of Accounts. Based on this information, both user-specified and implied, it may be possible to automatically filter the data a user sees. By pushing the technology into the Great Plains platform, we can make applications more robust and developers, both within Great Plains’ four walls and within the virtual organization a lot more productive.

For a nice overview of Microsoft’s .NET technologies, check out: https://www.microsoft.com/net/Overview.aspx [Ed: broken link fixed]

The technology mountain is enormous but Platform Services will shave it down to size by providing an abstraction layer for all of our benefits. Same thing Great Plains has always done.

See you next time,

Karl Gunderson
Technical Evangelist

The original newsletter is available as a pdf attachment at the bottom of this article.

The 10^th November 1983 announcement of Windows is also mentioned in this cool "Key Events" document: http://www.microsoft.com/msft/download/keyevents.doc

David

Testing Date Driven Features in GP

Alice Newsam [MSFT] — Fri, 18 Dec 2009 08:00:00 GMT

Have you ever had a piece of functionality that is date driven that you wanted to automate a test for but couldn’t figure out the best way to control the dates in the system? Then this post will be very helpful for you! A common area I receive questions on when talking with partners and customers is around automating features such as MRP which is extremely date driven. This post is going to cover settings in the Dex.ini and Keys.ini files that will help you set the system to specific dates and times.

Dex.ini Settings
Several settings in the Dex.ini file control the application and enable more consistency to be driven into tests. The below settings will allow you to specify whether you want to use the Control Panel settings for date, time and currency values as well as allowing you to set the preferred format.

StdInternationalInfo	This setting allows the operating system settings for date, time, and currency formatting to be overridden.
TRUE	Use Dexterity standard formats for date, time, and currency values
FALSE	Use control panel settings for date, time, and currency values

StdInternationalInfoDateCentury	This setting allows control over the year portion of the date values used by StdInternationalInfo
TRUE	Four digits will be used for the year portion of date values
FALSE	Two digits will be used for the year portion of date values

StdInternationalInfoDateZeroPrefix	This setting allows control over the date format for SdtInternationalInfo
TRUE	Single-digit day and month values will be prefixed with a 0 (zero)
FALSE	Single-digit day and month values will not be prefixed

Keys.ini Settings
The Keys.ini file contains commands that are run at startup to configure various system behaviors. The commands in the Keys.ini are run only if the file is included in the command to launch Microsoft Dynamics GP. You create this file using a text editor such as Notepad. The Keys.ini file is typically stored in the Data folder of the Microsoft Dynamics GP installation. To work properly, the Keys.ini file must also have a blank line as the last item in the file. The following commands allow the user to set a static system date and time.

SetEbDateTo	This command specifies the system date value to use
'o/s'	Use the operating system date
date MM/DD/YY/DOW	Use the date specified, where MM is the month, DD is the date, YY is the year, and DOW is the day of the week Example: SetEbDateTo date 01/01/1965/3

SetEbTimeTo	This command specifies the system time value to use
'o/s'	Use the operating system time
time HH:MM:SS	Use the time specified, where HH is the hour (from 0 to 23), MM is the minute, and SS is the second Example: SetEbTimeTo time 4:15:00

Here is an example of a Keys.ini file:
SetEbDateTo date 01/01/2001/3
SetEbTimeTo 'o/s'

Once the above settings have been specified you will then be able to setup your starting data including specific dates for orders, items, etc to create in-depth testing for date driven features.

Have a great day!
Alice
GP Test Team

Blast from the Past - The Inside Track - August 2000

David Musgrave — Wed, 16 Dec 2009 01:00:00 GMT

This is article 1 of 10 from the Blast from the Past - The Inside Track Series.

This newsletter from Karl Gunderson was sent out in August 2000.

The Inside Track
August 2000

Welcome to a new column in the Solution Developer newsletter, The Inside Track. First off, let me tell you about myself. I’ve been working for Great Plains for a little over 6 years, most of that time as a developer on Dexterity. As such, I’ve written some C/C++ code and I’ve written a fair amount of code in Visual Basic and Delphi, too. I’ve also fiddled around with HTML and scripting. Prior to coming to Great Plains, I worked as an embedded systems programmer, an in-house programmer for a local business, a corporate developer for a large insurance company and I worked as a programmer for a VAR (twice!) writing custom business applications and modifying existing ones. While my VAR experience is a bit old, I remember well the kinds of pressures and wide ranging responsibilities a programmer in such a role experiences. My guess is that this is the experience most similar to yours.

The other thing you should know about me, is despite being married to a CPA and having written a fair amount of business software, I really don’t know anything about accounting. But that’s OK since this column isn’t about accounting it’s about technology. I hope to tell you about what’s happening in Platform Services at Great Plains. If you think of Dexterity as our current platform, then you’ll understand that Platform Services is the division within the company that will be building the platform of the future. This next generation platform will be fully web enabled to build applications that live happily on the Internet.

Speaking of the future, lets get started. I’m sure you’ve heard of Microsoft .NET. .NET was revealed to the world at the Professional Developers Conference in early July. .NET is a family of technologies for “programming the web”. At present, each web site is like an island with dotted lines that connect it to other web sites. The .NET technologies aim to turn those dotted lines into information conduits, making the web as much a development environment as the desktop is for traditional client/server applications. For instance, if you’re writing a business application that needs credit card authorization you will be able to use the web based services provided by a credit verification services company. .NET is based on existing Internet standards like HTTP and XML, but extends these basic mechanisms with additional technologies like Simple Object Access Protocol, SOAP, (SOAP has been submitted to the standards process) and ActiveX Data Objects+, ADO+. In future editions of this column, we’ll be exploring these technologies in more depth.

But, you ask, where is Great Plains in this picture? Glad you asked. Great Plains, and specifically the Platform Services team, has been working with early releases of the Microsoft .NET technologies under the heading of the “Fusion” project. We called this project Fusion because it brings together and builds on the technologies that are needed to create the next generation of Great Plains web enabled applications. As you’re well aware, Dexterity is a great tool for building LAN-based client/server applications like Dynamics and eEnterprise. Along with things like the Modifier with VBA and Continuum it’s also an excellent tool for extending and customizing such an application. But, Dexterity built applications tend to be rather monolithic. As a result, they don’t play well in a web world! Applications on the Internet need to be broken into pieces called components and delivered via a distributed services model. If you think about it, this is a lot like the way Great Plains the company is organized. The Great Plains virtual organization provides its distributed services via pieces called Partners, you.

We will be going into more depth about the Microsoft .NET technologies and how Great Plains plans to build its platform of the future and then build the applications of the future on top of that platform. Along the way, we may also examine some shorter-term technologies and techniques, but whatever it is you find here, it will be a technical peek from the inside track.

Until next time, Karl Gunderson, your technical tour guide and Great Plains technical evangelist, signing off…

The original newsletter is available as a pdf attachment at the bottom of this article.

David

Blast from the Past - The Inside Track Series

David Musgrave — Mon, 14 Dec 2009 01:00:00 GMT

As most of you know, before I worked for Microsoft, I ran Winthrop Dexterity Consultants. Well, I had a look at the old website recently and decided that it really needs to be updated.

Since Winthrop sold the Omni Products to Rockton Software over three years ago, this is really long overdue.

I suppose the reason for hesitating was that there are still some useful information and downloads on the site which I would like to leave available. So as part of the project to update the site I am going to move (and where appropriate... update) some of the best resources to the Developing for Dynamics GP blog.

The first part of this migration process is to bring across Karl Gunderson's The Inside Track series of solution developer newsletters. There were ten newsletters which were published between August 2000 and October 2001. I suppose if Karl was writing these newsletters now, they would have been blog posts.

I will be posting this articles over the next few weeks for you to read. There is still much value in what Karl had to say, but I should mention that there might be information that is no longer valid today. It took between one and two hours to reformat each post for the blog, but I believe it was worth the effort.

The table below lists the articles with their original dates as well as when they will be posted on the blog.

Please note that articles will only be available on or after the date shown.

Month & Year Description Post Date

August 2000 Introduction 16-Dec-2009

October 2000 Portable Code and Why .Net? 21-Dec-2009

November 2000 XML & XSL 23-Dec-2009

December 2000 CLR - Common Language Runtime 28-Dec-2009

January 2001 COM and inter-application Communication 30-Dec-2009

February 2001 XML Reprise 04-Jan-2010

March 2001 UML - Understanding Meta Language 06-Jan-2010

June 2001 Representative and Reactionary Programming 11-Jan-2010

August 2001 Please Step This Way, Part 1 13-Jan-2010

October 2001 Please Step This Way, Part 2 18-Jan-2010

Month & Year	Description	Post Date
August 2000	Introduction	16-Dec-2009
October 2000	Portable Code and Why .Net?	21-Dec-2009
November 2000	XML & XSL	23-Dec-2009
December 2000	CLR - Common Language Runtime	28-Dec-2009
January 2001	COM and inter-application Communication	30-Dec-2009
February 2001	XML Reprise	04-Jan-2010
March 2001	UML - Understanding Meta Language	06-Jan-2010
June 2001	Representative and Reactionary Programming	11-Jan-2010
August 2001	Please Step This Way, Part 1	13-Jan-2010
October 2001	Please Step This Way, Part 2	18-Jan-2010

Please note that articles will only be available on or after the date shown.

Note: Some of the links mentioned in the newsletters are no longer valid.

The series will conclude on 20-Jan-2010 with a summary post.

David

Determine SOP Type in SOP Entry using VBA or Visual Studio Tools

Patrick Roth [MSFT] — Fri, 11 Dec 2009 10:25:00 GMT

I think the most customized window in VBA must be the SOP Entry window.

If the customization is not saving custom data for the header/line items, then it is adding custom logic based on document type and any number of other factors.

In all of this - especially saving custom data to a parallel table - the SOP Number is important as it identifies the document. And, of course, to be unique your primary key would also include the SOP Type field - just like the SOP10100 table does in Dynamics.

Getting the SOP Number is easy - it is the string value from the window.

The SOP Type value is a bit more difficult with the introduction of Fulfillment Order SOP Type. This all would have been a lot easier if we would have just added this new type to the end of the SOP Type list. But I guess I can see it would go well with the Order type in Dynamics. So Fulfillment Order was added into the middle of the list - complicating things a bit when trying to determine if SOP Type = 3 (on the window) is an Invoice or a Fulfillment Order.

While getting the SOP Type is easy from Dexterity using the SOPTypeToInt function, that function cannot be called from Visual Studio Tools due to an anonymous field being passed to it and certainly not used from VBA since it natively cannot call Dexterity functions.

So where does that leave our enterprising VBA/VSTools developer? How do those developers get the true SOP Type value?

By referencing a hidden field added specifically for non-Dexterity developers.

Since at least 9.0, an invisible field called 'SOP Type Database' was added to the SOP Entry window. It is in the 2nd column of fields, 16 fields down off the bottom of the window. This field contains the correct "SOP Type" of the current document, the value that matches the SOP Type field stored in the SOP10100 table regardless of what the value SOP Type field in the SOP Entry would show. Just exactly what we need.

Using the field from Visual Studio Tools is easy - just reference the field as below:

C# Code Snippet Example

int sopType = 0;
sopType = SopEntry.SopEntry.SopTypeDatabase.Value;

From VBA it is a little more difficult because the field is off the window and invisible so not easily added to VBA without a bit of work.

To get at it with VBA, you must:

Using Modifier, locate the field and move it onto the visible portion of the SOP Entry window.
Make the field Visible property set to true.
Exit Modifier and save your changes.
Grant yourself access to the modified form (if necessary - you might already have that in your customization)
Open the window - this field should be visible.
Add the field to VBA.
Go back into Modifier and move the field back to it's original location and set the field Visible property back to false.
Exit Modifier and save your changes.

Now in VBA, instead of referencing the SOP Type field directly, reference this new field to get the actual value your code requires to properly save your parallel data.

VBA Code Snippet Example

Dim realSOPType as Integer
realSOPType = SOPTypeDatabase

Hope this help,

Patrick
Developer Support

Do we really want Windows Authentication for Microsoft Dynamics GP?

David Musgrave — Wed, 09 Dec 2009 01:00:00 GMT

Over the years, I have seen many requests for Windows Authentication support for Microsoft Dynamics GP, and I have to say I have mixed feelings about it. In theory, it sounds good, but in practice it may be a threat to your customer's financial information security.

Regardless of authentication method, users will still have to select a company to access which defeats the purpose of having a single sign-on.

If we have true Windows Authentication, then a workstation left unattended without being locked, could be used to access the financial system without the additional level of security of requiring a login. Also, if Windows Authentication is used, the password will not be encrypted (see article below).

The encryption of the passwords is what prevents access to the financial data using external tools to access the SQL Server. Having an encrypted password means that you must use the Microsoft Dynamics GP application to access the data and so are then subject to the application's security system. You cannot bypass the application level security as the password will not work from an external tool.

When a customer asks for Windows Authentication, I think we should not apologize and say that it is not supported. Instead we should sell the benefits of having an extra level of security provided by SQL Server Authentication with encrypted passwords. This extra level will protect the customer's valuable financial data.

Note: There are some third party ISV solutions which can synchronize the SQL user names and passwords with the Windows user names and passwords. While this simplifies the system by not having to remember more than once password, it is not true Windows Authentication.

For more information related to this topic, have a look at the following article:

Why does Microsoft Dynamics GP encrypt passwords?

Post a comment and let me know what you think?

David

11-Dec-2009: Added follow up comment:

Please don't get me wrong, I am not saying I don't want Windows Authentication, just that the extra layer of security with a second login and encrypted password can be a good thing.

I think we should sell the benefits of the way it works now rather than getting defensive when asked by a customer about Windows Authentication.

I would like to see both methods supported in future so that the customer can choose what they want.

The idea of this post WAS to start an open discussion on the topic.... so please keep posting your thoughts as comments.

What is the A4 Chunk?

David Musgrave — Mon, 07 Dec 2009 01:00:00 GMT

Recently on the newsgroups, I responded to two separate questions on the same day asking about handling A4 size paper with Microsoft Dynamics GP. So I thought a post about the A4 chunk would be helpful.

Background

Before the age of laser & inkjet printers (and after the daisy wheel and golf ball printers) the most common type of printer was the dot matrix printer. While dot matrix printers are capable of printing graphics or using graphic fonts, they were very slow when used this way. Historically, the dot matrix printer was used with a built in font which was non proportional (fixed width) and of a fixed style (eg. Courier, Helvetica, Times). If you had a good printer, you could print those fonts in bold and/or italic. The printers could printer either 10 (Pica), 12 (Elite) or 17 (Condensed) characters per inch (CPI) across the page and either 6 or 8 lines per inch (LPI) down the page. Unless you were lucky enough to have a wide carriage printer, your printer could print 8 inches wide (80 characters in 10 CPI mode ... the width of a text screen). The standard size of paper for this type of printer was 8.5 inches wide by 11 inches long. Sometimes it was a little wider and had tear-off sprocket holes... these were the holes on both sides of the paper that allowed it to be pulled through the printer.

So .... why the history lesson?

Well, because that standard size for computer paper became the standard size for paper in the USA, and is known as US Letter. OK, it might be possible that the paper size came first and the printers were made to match it.

On the other hand: A4 is an international standard (ISO 216) based on having an aspect ratio based on the square root of 2 (√2), or approximately 1:1.4142. The really cool thing about this is that if you fold or cut a piece of paper in half across its long side, the resulting sheet will have the exact same aspect ratio (just rotated 90 degrees). If you half an A4 sheet, you get A5. If you join two A4 sheets together you get A3. A4 size paper is the most common and is used in most countries outside of North America. Its dimensions in metric measurements are 210 × 297 mm.

For more information, you can see what Wikipedia says on its Paper size entry. The following diagram is from the Wikipedia page:

History

Prior to version 7.00 of Great Plains Dynamics and eEnterprise, paper sizes were not a major issue. This was because almost all reports were text based and were using the Best Text Fit option. This meant that when a report was printed the font used would be selected to ensure that the content to be printed would fit onto the printable area of the paper being used (based on paper size and the printer driver's margin settings for non-printable area). This automatically adjusting behaviour meant that most reports would work on either of the two main paper sizes without modifications.

With version 7.00 a number of reports which were previously text reports were converted to graphic reports and a number of new reports added as graphic reports. Graphic reports have a fixed size and do not have the option to automatically resize like a text report using the Best Text Fit option. So, graphic reports which have a layout based on US Letter sized paper do not fit well on A4 sized paper. Here is a summary of the paper sizes:

US Letter is 8.5" (216mm) wide by 11" (279mm) high.
A4 Paper is 8.27" (210mm) wide by 11.69" (297mm) high.

As you can see US Letter is wider and shorter than A4 paper. So in practical terms, if we look at the SOP Blank Invoice Form, when the US Letter version is printed on A4 paper, it will lose the right hand edge and the vertical lines will not join to the footer section to close the "boxes".

To help minimise the amount of report modifications that would be needed for an A4 based installation, a patching chunk was created to adjust graphic reports and some non landscape text reports so that the right hand edge does not have characters cut off. For graphic reports which have vertical lines, the lines were extended by 50 pixels to compensate for the longer paper size. This patching chunk is known as the A4 chunk (A4.CNK) and once installed it updates some 165 (approx.) reports in the core Dynamics.dic application dictionary.

The A4 chunk was original developed for Australian and New Zealand installations for v7.00 by the now defunct Asia Pacific Global Development Team which I was part of when I first joined Microsoft. The A4 chunk is now available for most country installations that would use A4 paper, United Kingdom, Australia, New Zealand, Singapore, South Africa, etc.

The following Knowledge Base (KB) article discusses the A4 chunk as it is a standard part of the Australian install:

Information about the localized code for the Australian version of Microsoft Great Plains (KB 910128)

Questions

So now that we know all about the different paper sizes and why the A4 chunk was created, what were the questions asked that prompted this article. Well, below are a list of frequently asked questions, including the ones from the newsgroups.

Q: When the A4 chunk is installed, I can't see it in Dynamics.set, why not?

A: The A4 chunk is a patching chunk that updates the Dynamics.dic file directly, you will not see it once it has been incorporated into the Dynamics.dic file. This is similar to how ??ERR.CNK files are used to update language and terminology.

Q: What files are updated by the A4 chunk?

A: The A4 chunk updates the Dynamics.dic file only.

Q: When I look at my report in Report Writer it has not been changed, why not?

A: The A4 chunk does not update the reports.dic at all. If a report already exists as a modified report it will not be updated by the A4 chunk. You would need to delete the modified report and then modify the original report again to get the updated version. Or you could manually update the report your self.

Q: What changes does the A4 chunk make to reports?

A: The changes vary depending on the report, the main changes are to shift the right hand columns toward the left a bit to allow for the narrower A4 page. For graphic reports with vertical lines, the length of the lines is increased by 50 pixels to allow for the increase in page length.

Q: How can I tell if the A4 chunk is installed on a system?

A: There is no version number or build number that can tell you that the A4 chunk is installed. Probably the easiest method is to open the SOP Blank Invoice Form and click on the first vertical line in the RH section. This line actually starts in the PH section but is easy to click on in the RH section. If the size is 0, 455 it is US Letter. If the size is 50 pixels longer, 0, 505 it is A4.

Q: Does the A4 chunk help with reports in 3rd party products?

A: No, the A4 chunk only updates the core Dynamics.dic application dictionary. Reports for products contained in other add on dictionaries will still need manual modifications.

Q: Can I have both US Letter and A4 reports on the same system at the same time?

A: Yes and no. You can have US Letter and A4 reports active in the same system, however, you will either need to install separate clients into separate application folders, or use separate reports.dic files. Most customers setup a US client folder and international client folder(s) as required.

Q: What reports are updated by the A4 chunk?

A: Attached to this post is a A4Readme.txt file which contains a list for v10.0.

I hope this article explains everything.

David

08-Dec-2009: Added Wikipedia links for the different types of printers.

Filtering eConnect Requester data

emily - msft — Thu, 03 Dec 2009 17:00:00 GMT

I wanted to tell you about a recent case I had where the Partner was trying to restrict the Microsoft Dynamics GP data they had selected with the eConnect Requester Setup Tool.

They were first importing some of their Sales Orders from an external system into GP with eConnect. Then when they fulfilled and shipped the Order within GP, they used eConnect Outgoing Queue to make the updates available to the external system. Their use of GP also includes manually entered Sales Orders and they did not want the updates to the manually entered Orders to be queued.

So, the way the Requesters work is that boxes checked on each SQL table in the Requester Setup Tool cause a SQL trigger to be created when you click the Update button in the Tool. These triggers will fire upon an insert, update, or delete operation on the SQL table and cause rows to be created in the eConnect_Out table. The eConnect Outgoing Service queries the eConnect_Out table on a regular basis and pulls the data into your queue. You can look at the triggers in SQL Server Management Studio by right-clicking on the trigger and Script Trigger as Create to New Query Editor Window.

If you have some data values that distinguish the GP entered ones from the eConnect ones, you can use that to filter. For example, if you use different Document Numbers in the eConnect Sales Orders than you do in the manually entered ones you could put an if statement before the insert into eConnect_Out... statement to make sure that the rows are only created that you want created. The following example assumes we want Sales Orders with a Document Number starting with the letters "EC"

Example eConnect_Sales_TransactionSOP10200_UpdateTrigger change

if (@SOPTYPE = 2 and @SOPNUMBE like 'EC%')
begin
    insert into eConnect_Out(
    .
    .
    .
end

The dots in the example are the rest of the insert statement that is already in the trigger, and you put your end statement after that.

One last thing: if you are using eConnect to update the Sales Orders instead of updating with GP, you will need to set the RequesterTrx element to 1 (one) for this to work.

Enjoy!

Emily
Dynamics GP Developer Support

More on Windows 7, bitmap fonts and DPI settings

David Musgrave — Wed, 02 Dec 2009 01:00:00 GMT

This post is a follow up to the previous post on the topic which discussed how you can use the registry editor to adjust the font files used for bitmap fonts to restore them to the default 100% DPI size. If you have not read the previous post, please use the link below:

Windows 7, bitmap fonts and Microsoft Dynamics GP

As I hinted at in this previous post, any older applications that use bitmapped fonts such as MS Sans Serif, MS Serif and Courier are likely to have this same issue.

I have already explained the logic behind the change in behaviour for Windows 7 which can automatically set the DPI to 125% during the install. What has not been explained is why the bitmap fonts are not restored to 100% DPI when the DPI setting is changed back to 100% via the User Interface. This is the subject of this post.

How we see Windows is controlled by two primary settings: The resolution and the DPI setting.

In Windows Vista (and earlier) the resolution could be changed for each user on a workstation, but the DPI setting was system based. This means that a user did not really have full control of the settings for their profile and if another user changed the DPI setting, it would affect all users on that workstation. Changing the DPI setting would require a reboot for the change to take effect and it would adjust the bitmap fonts as part of that change.

So Windows 7 introduced a change to allow the DPI setting to be set on a per user basis (only requiring a logout and login to make the change). It is important to note that the user based DPI setting only affects the scalable fonts which can be adjusted without a reboot.

The bitmap font DPI settings are still system based and would still require a reboot to change and would also affect all users on the workstation. To avoid the now user based DPI setting from affecting other users in the system, the bitmaps fonts are no longer changed when adjusting DPI via the Display Control Panel applet.

The bitmap font size is now set only once during the installation and not altered thereafter. As we now understand, the initial DPI setting used during the install will control how the bitmap fonts are set.

I am researching if there is a way to make Windows 7 always default to 100% DPI during the installation, or a way to keep the bitmap fonts at 100% DPI size. However, if you DO want the 125% DPI setting, you will then have the same issue but the other way around.

Thanks to Peter Constable from the Windows 7 Development team for his input.

I hope this clarifies what is happening.

David

Checklist for creating a new Dexterity Window

David Musgrave — Mon, 30 Nov 2009 01:00:00 GMT

Today, we go back to basics. It is always good to make sure that we have the foundations handled properly. When I teach the Dexterity, I always go through the standard checklist below for creating (or modifying) Dexterity windows.

This checklist is valid for Dexterity when creating new windows or editing existing windows which will become alternate windows. It is also valid when using Modifier to modify existing windows.

Check the User Interface (UI)

There are User Interface Guidelines in Appendix F of the Dexterity Basics training manual (see links below). These guidelines should be followed to ensure that your windows or changes to windows cannot be told apart from the original windows. Some common issues I find are:

1) 3D line under the Window Control Area (Toolbar) to cover the black line is missing, or the line is present, but has not been made wide enough to fully reach the right hand edge of the window.

2) Buttons in the Window Control Area (Toolbar) are not separated by 2 pixels with a 3D vertical line (starting at vertical position 3 with length 16) between each button AND after the last button.

3) When two fields are next to each other the borders create a double thick line between them. To fix, click on the fields to the left and press Shift-Right Arrow to increase the size by 1 pixel.

4) When creating Scrolling windows, turn the borders off for the fields in the scrolling window and draw new borders with the line tool. Make sure that every drawn line is set to 2D Border. This will prevent the 1 white pixel of a vertical 3D line breaking up the horizontal lines.
Link Prompts

For the prompts to be "greyed out" when the field is disabled, hidden when the field is hidden or to show in a different style for a required field, the field must be linked to the prompt.
Link Lookups

For lookups to be be disabled when the field is disabled, or for the Ctrl-L keyboard shortcut to work, the field must be linked to the lookup button.
Tab Sequence

To make your windows keyboard friendly, the tab sequence should include all fields as well as the main action buttons. The first field in the sequence should be the first field on the window, which is usually the primary key field. The tab sequence should then work right, across the fields in a column then down the lines to the end of the section. Then if the window has more than one column, the tab sequence goes back to top of that column and works down. When the end of the section is reached it starts back at the top left of the next section and repeats zig zagging its way through the fields. Once the last field is reached then it should go through the toolbar buttons and then finally any buttons at the side or bottom of the window.

Note: Remember to press Tab in between each field when setting the tab sequence, otherwise the tab sequence will be reversed.
Position Window

You should position the window away from the top left corner. If this window will be used with other windows, you can position it so that it will be visible or at least not completely hidden by the other windows.
Resizing

If the field includes fields that can be resized, such as lists, scrolling windows, treeviews or listviews, you might want to change the window to use per field resizing and then define the behaviour wanted for ALL fields, prompts and lines. Use the Ctrl-5 preview mode from window layout to test the resizing.
Compile

Always compile all the code when you think you have finished. Logical errors cannot always be avoided, but leaving syntax errors in code is completely avoidable.
Test

Everything you develop should be tested and tested and then tested again. By the way... did I mention that you should test your code.

Here are the links for the Dexterity training materials (which include the UI guidelines):

Dexterity Basics for Microsoft Dynamics GP 9.0

Dexterity Integration for Microsoft Dynamics GP 9.0

Note: The latest materials are for v9.0, but the content is applicable to v10.0 and later.

If you are new to Dexterity, this article will help you learn what you need:

Dex - How to get started with Dexterity

Hope you find this best practice checklist useful.

David