It's been a while and dust is collecting. Sun is shining, open windows and doors, time to do some cleaning again.

Today let's clean up the Development Environment Options Marquee Full Selection and Max. no. of XML records to send.

The first did only have a meaning when designing forms, the later is taken care of by the client setup (ClientUsersSettings.config).

No Options, uhhh, option today. Let's make our hands dirty, Vedbaek.

You might recall me writing on the new ShowMandatory property. The one you can now set on a page control showing a red astrix on the left side of the control. And that it will also shown when setting the NotBlank property on a primary key field.

By mere coincidence I ran into the following.

I created the following table having set NotBlank = Yes on the Primary Key field.

And a Card Page based on this table with ShowMandatory = TRUE on all non-PK controls.

You see? No astrixes for the Amount and Reference ID fields. Even though I did not enter any value, so from my perspective they are still empty.

It appears that ShowMandatory checks the content of the control itself and not the value of the field bounded to the control. Of course we could argue whether a zero Amount field is empty or not as zero is a value too.

Now if you want to have the asterix shown on these two fields you have to make sure that the control is empty.

1. This can easily be done by setting the BlankZero or BlankNumbers property (on either the table field or the page control), but only seems to work for the numerical data types, so ...
2. Won't work for the Reference ID field (GUID) out of the box. I recon you could do something with a control addin, but haven't tried it (yet).

Even though many of us are experienced developers, the FILTERGROUP record function isn't for each of us a well-known or understood concept. Because of this very reason the following question has been for years part of the quiz I start a course day with.

So get ready …

The default lookup page for MyTable is run by the following C/AL code:

MyTable.FILTERGROUP(2);
MyTable.SETFILTER("No.",’1000..5000’);
MyTable.FILTERGROUP(0);
PAGE.RUN(0,MyTable);

When the page is displayed, the user applies the table filter 6000..6500. Which records will then be shown?

a. No records because the filter will read: (1000..5000)&(6000..6500)
b. Records in the range 1000..5000 because the program ignores the filter applied by the user
c. Records in the range 1000..6500 because the filter will read (1000..6500)
d. Records in the range 6000..6500 because the filter applied by the user overrides the SETFILTER call

"OK ... a, b, c, or d?" ...

... I did ask the 13 Slovenian developers I was giving a NAV 2015 update course to the last couple of days. And yes, some knew, but most had a hard time with it.

Triggered by this question and the discussion following it, one of the attendants, Darko Grasic (he earns the credits), consulted the msdn help on FILTERGROUP and asked me about FILTERGROUP(-1).

FILTERGROUP(-1)?

Yep, FILTERGROUP(-1). Follow the link and see. Or just try the following code:

Rewriting the code somewhat so it opens a page the result looks like this (including my former MS colleague Hervé):

You get it?

So with FILTERGROUP(-1) we now have and OR filter that can spread several columns! Wow.

Two things to note

• running the page the filter didn't work straight forward. Had to mark the records to be able to show the result set in the page:

   

  WITH Customer DO BEGIN
    FILTERGROUP(-1);
    SearchString := '@*ou*';
    SETFILTER(Name, SearchString);
    SETFILTER(Contact, SearchString);
    SETFILTER(City, SearchString);
    IF FINDSET THEN
      REPEAT
       MARK(TRUE);
      UNTIL NEXT = 0;
    FILTERGROUP(0);
    MARKEDONLY(TRUE);
    PAGE.RUN(0,Customer)
  END

 

• Not sure whether a balancing call FILTERGROUP(0) is needed as the filter doesn't show in the UI

3/4 of a year NAV 2015 is on the market and nobody so far (at least that I could trace on the Internet) seemed to have noticed. I guess we all have sleeping. Seems including MS as it hasn't been fixed.

Did you read this?

Click on the image to go to the msdn help topic.

Great, so eventually code variables are treated the same as text variables with respect to their length.

Well ... bummer ... no. Try it yourself.

Clearly a bug, but the question is: documentation or implementation bug?

I go for the latter. 

Since a couple of years codeunits have a property called Subtype. Selecting a specific value for this property changes the behavior of the codeunit, one of them being an extra property added to functions, i.e. FunctionType (for Test Codeunits and Upgrade Codeunits) which defaults to a specific value depending on the Subtype value (see my post NAV 2015 Glance 4: New Functions are Local by Default?).

Now what happens when you change the Subtype of a codeunit? As FunctionType values depend on the codeunits Subtype C/SIDE cannot just leave the FunctionType as is. Let's try and see.

Scenario 1 - Changing a Test Codeunit to Normal

So we create a test codeunit with a test function:

And change the Subtype to Normal:

Now C/SIDE removes any test artifacts that do make sense in a normal codeunit:

Scenario 2 - Changing a Upgrade Codeunit to Normal

Let's do the same with a Upgrade codeunit:

I.e. change the Subtype to Normal:

Logically as the in previous case, C/SIDE removes any upgrade artifacts that do make sense in a normal codeunit:

This perfectly makes sense ... but for one fact: why aren't the functions set to local as is the default behavior in NAV 2015? I would prefer that as I wouldn't want any previous test or upgrade function being exposed outside of this codeunit by default.

What do you think?

BTW

Never observed this before, but this looks somehow awkward, doesn't it: Subtype v.s. FunctionType? Why is the first having a low cap t and the second upper cap T?