Partner Sauce

PartnerSource seems to be going through something of a revolution. If you use the Global English site, you have probably been using the new saucy version for a few days now. If, like me, you sign in to a localized version, you may be unaware of the changes that are coming.

So what is so good about the changes that warrant a blog post? I’ll tell you what, three little letters: R S S.

It is now possible to subscribe to an RSS feed for News, Sales & Marketing, Support & Deployment and Training & Certification, meaning you read the news in a Vista sidebar gadget, from within Outlook or on your mobile phone. But for me the ultimate feeds are the Most Recent KB Articles and Most Viewed KB Articles. Now you may think that getting excited about this is a sure sign that I need to get out more or at least get a hobby, but believe me this is going to make my life so much easier.

It seems that I am not the only one that has struggled to find out what is going on in the NAV world without a lot of digging around and checking PartnerSource every day, just in case there is something new. For more details on the changes to PartnerSource and a warm feeling of love from Microsoft, check out the link
Get Ready for Exciting, New Changes to PartnerSource

For some strange reason whenever I clicked on the RSS Feed links on the NAV product site, my Internet Explorer crashed – this was because of Skype and as soon as I uninstalled Skype on my machine it all worked fine. I will report this to the team to see if they can fix it up. The non-product site RSS feeds worked fine.

You can find the NAV-related product feeds on this page: https://mbs.microsoft.com/partnersource/solutions/nav/

Runtime Errors Suck!

I hate runtime errors. I think that functions in C/AL that can generate runtime errors should be deprecated where possible or altered in their function. Let me explain with an example.

Let's say you have two fields both called Description on two different tables. One of your tables is the Item table and the other is a new table called "New Item" (OK so I'm not going to win any prizes for imaginative table names in this example.) You want to make an assignment from one field value to another so you would do something like this:

l_NewItem.Description := l_Item.Description;

When your code runs the Description gets copied across and everyone's a happy bunny. But, let's say your customer says they want their item description to be made 20 characters bigger. What happens then?

Well let's assume that you increase the size of the Item Description field by 20 characters. Everything still works. Or so you think.

When NAV executes the line of code that previously worked fine on a record that has more characters in the new larger string than will fit in the other string, you (or more likely the first user that comes across that bit of functionality in your production system) will get a Runtime Error. Blurgghhh!

I have programmed in a few languages and C/AL is the only language I have ever come across that does this. What would other languages do? They would truncate the value and continue. They would assume, "hey, the programmer wants me to put a 50 character string in a 30 character string, he must know what he's doing, so I'll just give him as much as I can."

I like that, it's friendly, it makes me feel warm and fuzzy. Why can't C/AL do the same?

But there is a far worse function that can throw runtime errors and this should be banned altogether! TRANSFERFIELDS.

TRANSFERFIELDS is evil. It has to go.

What does it do? Well it, er, transfers, erm, fields (duh?) It is used to transfer fields from one table to another. Sounds cool doesn't it? How does it decide which fields should be copied? It uses the field ID.

What? The totally arbitrary field ID? Surely not, that would be crazy. Yup you heard it the field ID. NAV will attempt to make an assignment between two fields with the same ID, but different names and different types. And what do you think happens if the field types are incompatible?

Run Time Error.

The reason this function is evil is it lures the unsuspecting programmer into its little trap. It looks innocent. It looks like it may save you some time. Don't be lazy. Assign the fields one by one. Think about it, if you have 10 lines of code that assign each field from one table to another, anyone reading your code knows exactly what is happening. If you really want to be good, create a function on the table called CopyFromItem() or something similar. Then do the field assignments in the function so your code would look something like this:

l_NewItem.CopyFromItem(l_Item);

Now isn't that better?

So what prompted me to have this little rant? Well I am doing an upgrade from v3.70 to v5.00 at the moment and the damn thing just failed with a run time error. Some of the code in the standard upgrade toolkit gave me this error message:

The two fields below must have the same type:  
Field: JobTaskNo <-- Table 
Table: Temp Job Task Phase Step Comb. <-- Temp Phase Step Task Doc Line 
Type: Code20 <-- Integer

Can you guess what caused this error?

TRANSFERFIELDS!

So if the expert coders at Microsoft get caught out, what chance do we have?

Field Captions and the CaptionClass Property

I recently needed to have a field that had a changing field caption based upon some conditions. I knew I had seen this in the standard system for sales orders where the Unit Price field changes between “Unit Price Incl. VAT” and “Unit Price Excl. VAT” depending on how you tick the “Prices Including VAT” field so that is where I started.

If you look on the Unit Price field properties on the Sales Line table you will see that the CaptionClass property is set to GetCaptionClass(FIELDNO("Unit Price")).

That looks like a function call so I take a look in the functions on the table.

GetCaptionClass(FieldNumber : Integer) : Text[80]
IF NOT SalesHeader.GET("Document Type","Document No.") THEN BEGIN
  SalesHeader."No." := '';
  SalesHeader.INIT;
END;
IF SalesHeader."Prices Including VAT" THEN
  SalesPricesIncVar := 1
ELSE
  SalesPricesIncVar := 0;
CLEAR(SalesHeader);
EXIT('2,' + FORMAT(SalesPricesIncVar) + ',' + GetFieldCaption(FieldNumber));

Well this seems to be returning either ‘2,1,Unit Price’ or ‘2,0,Unit Price’ depending on whether the Sales Header has the “Prices Including VAT” field set to TRUE or FALSE. How weird is that? Clearly that is not what is displaying on the form.

If you take a look in the C/SIDE Reference Guide (select the option from the Help menu of the application,) there is an interesting line that says “The expression is then interpreted by Trigger 15 in CodeUnit 1.”

Let’s take a look at that codeunit trigger.

CaptionClassTranslate(Language : Integer;CaptionExpr : Text[80]) : Text[80]
CommaPosition := STRPOS(CaptionExpr,',');
IF (CommaPosition > 0) THEN BEGIN
  CaptionArea := COPYSTR(CaptionExpr,1,CommaPosition - 1);
  CaptionRef := COPYSTR(CaptionExpr,CommaPosition + 1);
  CASE CaptionArea OF
    '1' : EXIT(DimCaptionClassTranslate(Language,CaptionRef));
    '2' : EXIT(VATCaptionClassTranslate(Language,CaptionRef));
    '3' : EXIT(CaptionRef);
  END;
END;
EXIT('');

This is one of those funny functions that gets called by the system whether you like it or not – you don’t pass the parameters to it but you can guess that what the values contain. I am guessing that in my example the CaptionExpr will contain either ‘2,1,Unit Price’ or ‘2,0,Unit Price’.

On examining the code, I can see that we are pulling out a number from the start of the string into a variable called CaptionArea (which in our case is 2) and using that to either run a new function or return the part of the string that appeared after the number. In our example we are calling VATCaptionClassTranslate(Language,CaptionRef).

So, let’s take a look at what this function does:

VATCaptionClassTranslate(Language : Integer;CaptionExpr : Text[80]) : Text[30]
CommaPosition := STRPOS(CaptionExpr,',');
IF (CommaPosition > 0) THEN BEGIN
  VATCaptionType := COPYSTR(CaptionExpr,1,CommaPosition - 1);
  VATCaptionRef := COPYSTR(CaptionExpr,CommaPosition + 1);
  CASE VATCaptionType OF
    '0' : EXIT(COPYSTR(STRSUBSTNO('%1 %2',VATCaptionRef,Text016),1,30));
    '1' : EXIT(COPYSTR(STRSUBSTNO('%1 %2',VATCaptionRef,Text017),1,30));
  END;
END;
EXIT(''); 

This function starts by stripping out another parameter into a variable called VATCaptionType and the remainder of the string goes into CaptionRef. Then as you can see the VATCaptionType is evaluated and it returns either ‘Unit Price Excl. VAT’ or ‘Unit Price Incl. VAT’. To know this you have to know that Text016 and Text017 contain ‘Excl VAT’ and ‘Incl. VAT’ respectively.

So that’s it. A good example of how to achieve dynamic field captions using the standard application.

But just to round off, what if I wanted to have my own field with a dynamics caption? Well if you go back to the CaptionClassTranslate function in codeunit 1, you’ll see that option 3 will simply return the value that you passed it back to the caption for the field. This is how you would do it.

Let’s say that we are implementing NAV for a client that wants three addition fields on the Customer Card, the currently have them in their old system called “User Field 1”, “User Field 2” and “User Field 3”. Don’t you just hate that sort of thing? Anyway they say that they want to change the caption to something more meaningful but they can’t decide on what to call them (it’s a lame example I know but it’s late so stick with me.) Being a cunning NAV developer you decide to create three setup fields on the Sales & Receivables Setup table called “Field Caption 1”, “Field Caption 2” and “Field Caption 3”. You can then let the users type the caption they want in these fields and use them for the field captions for the new fields you will add on the customer card.

First of all, you create the fields on the Customer table as “User Field 1”, “User Field 2” and “User Field 3”. Then you create a little function on the Customer table that will take an integer parameter (valued as 1, 2 or 3) and will return a Text value that is the right caption. Let’s call our function “UserFieldCaption”. It might look something like this:

UserFieldCaption(p_FieldNo : Integer) : Text[80]
l_SalesReceivSetup.GET('');
CASE p_FieldNo OF
  1: EXIT(l_SalesReceivSetup."Field Caption 1");
  2: EXIT(l_SalesReceivSetup."Field Caption 2");
  3: EXIT(l_SalesReceivSetup."Field Caption 3");
  ELSE
    ERROR('UserFieldCaption function on Customer table called with invalid field number of %1',p_FieldNo);
END;

Now on our User Field 1 on the Customer table we would set the CaptionClass property to

'3,'+UserFieldCaption(1)

The other two User Field CaptionClass values will be similar – hopefully you can figure this out yourself.

Once you have compiled everything, set the values of the captions on the Sales & Receivables Setup and Open the Customer table from the object designer. There you should see the caption for your new fields using the value you entered on the setup table.

Try Catch in Dynamics NAV

This has to be up there on my list of "all time desirable features" for NAV. As you probably know NAV has an ERROR function that is used to, well, throw errors. It will abort the current transaction (and roll back to the point of the last commit) and display the text message that you selected in an error dialogue box.

The thing is, sometimes you don't want it to do the abort and rollback. For example if we are importing a file or maybe a series of files, we may just want to log the error somewhere and carry on with the next file. You can do this in NAV 5.0 using the new GETLASTERRORTEXT function.

Here's an example of how to do it.

First of all, create a simple codeunit that, when run, will throw an error:

OBJECT Codeunit 50000 ThrowError
{
  OBJECT-PROPERTIES
  {
    Date=09/04/08;
    Time=[ 9:34:55 PM];
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=BEGIN
            // Call a function that throws an error.
            DoSomething();
          END;

  }
  CODE
  {

    PROCEDURE DoSomething@1000000000();
    BEGIN
      ERROR('Hey Look I threw an error.');
    END;

    BEGIN
    END.
  }
}

When you run this codeunit you get the following error message displayed.



Now create another codeunit that will call the first one and trap the error it generates:

OBJECT Codeunit 50001 Test Throw Error
{
  OBJECT-PROPERTIES
  {
    Date=09/04/08;
    Time=[ 9:35:58 PM];
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=VAR
            l_ThrowError@1000000000 : Codeunit 50000;
          BEGIN
            IF NOT l_ThrowError.RUN THEN
              MESSAGE(GETLASTERRORTEXT+ ' - or did I?');
          END;

  }
  CODE
  {

    BEGIN
    END.
  }
}

When you run this second codeunit, even though it calls the first codeunit, you don't see the error message. Instead you see this:



You'll need to make a COMMIT before trying to trap the return code from running the codeunit but if you have uncommitted transactions you'll get a run time error telling you this. Unfortunately this only works when you Run a codeunit so you either have to use lots of codeunits or write some kind of clever dispatcher that allows you to set the action on the codeunit first and then run it.

So my most desired feature would require some language additions to C/AL. Introduce a TRY CATCH language construct – it would work similar to an IF ELSE statement. Here is an example:

TRY
  BEGIN
    DoSomething();
    DoSomethingElse();
  END
CATCH
  BEGIN
    MESSAGE(GETLASTERRORTEXT);
  END;

I have put the BEGIN and END in the CATCH part to illustrate how it work in a similar manner to the IF ELSE construct but it wouldn't be needed. The neat thing about this is you would not need to use a codeunit just to be able to trap the error. The same rules regarding commits, etc. would apply.

I guess I'll just nip over to the Connect site and suggest this little beauty for the product team to ponder over.