All around NAV dev and test
[See the first part of my review here.]
I guess Arend-Jan and I are going to play some kind of ping-pong over this. I should have been finished way before his post this afternoon! Continued reading last Sunday I did finish the book last Monday already. Nevertheless I am happy that Arend-Jan stepped in today as I fully agree with his first observation on Alex' book:
... this book intends [to] give the user an insight of the world developers are in .. [which] makes the book unique.
Indeed for the price of this book, including the tips on how to install it "... for (almost) free", it's a efficient and fun-to-do way of getting to know NAV and have insight in the NAV developer's world. Next to that I typically would advice any starting developer and consultant, be it technical or functional, to pick up this book and run through it, performing every step Alex points out.
Well done, Alex.
But next to all this halleluja some criticism: wanna learn something about NAV reporting, even be it basics, buy another book.
Being Dutch getting the opportunity to get a free copy, I willingly volunteered to Albert Augustine's call for reviewers on LinkedIn. And with me - note mostly none Dutch! - 20+ also did.
That's one.
Need I have more reasons?
Well actually, yes. There are many books I would like to read; or should I say: of which I would like to get to learn the content; i.e. the message. But then the challenge of setting priorities and finding time to do it comes around. Then getting a free copy and in return writing a review gives me some more direction.
Makes two.
No, let me be honest. These two probably triggered me for sure. Nevertheless, the ultimate one is the author of this book, Alex Chow. I believe he's my senior as Dynamics NAV MVP. And only since I became an MVP myself I come across his name every now and then. During MVP online meetings, on the forums, reading his blog. However, we never met live; at least not that I am aware of. Now getting this call, seemed a good opportunity to somehow get to learn more about Alex and meanwhile possibly picking up up some useful tips and tricks.
Now with the (1) free copy and (2) somehow resetting priorities and finding time, this made three. So I better deal with this banana ...
... but time passed by much faster than I hoped. Darn. [Excusez-le mot.] Still managed to read the first two chapters so far and will continue this afternoon on this shiny Father's Day.
Then why bother to start writing, Luc?
To be the first; at least I hope.
Sucks. Give me a better reason?
Do I need one? ... Sorry, just thinking out loud. OK, here it comes: I really loved reading these two chapters. For sure because of the writing style of Alex. It's fun reading. Feels like sitting next to him, while he's giving you useful and valuable tips on how to get NAV installed (Chapter 1) and how to get started with it (Chapter 2). feels reading more, .. and more. And that's what I am going to now.
And that's all for now?
Yes, I am sorry. Since I started reading I feel the urge to go and sit down and continue reading, so let me stop here for now and do that. Will return hopefully soon, having been able to finish the book.
OK, one more for the road.
About the content: as Alex describes it himself: It’s a book that teaches new users, whether end user or beginner, on how to create an application in Dynamics NAV 2013 based off of a real project that I’ve done in the past. These 2 chapters indeed live up to this.
Now don't wait before I finish reading the book, go out there and get a copy and start reading it yourself. Dare to say that it will be worthwhile.
[to be continued]
Only this week I found out that we lost some standard behavior of the MESSAGE function, on the road to NAV's new 3-tier architecture. Anybody noticed?
Most probably you know perfectly well that a CONFIRM and MESSAGE are functionally not quite the same. One has a Yes and a No button, where the other has the single OK button. But they also have - let us call it - a technical difference. One of main importance. During my NAV development courses I use the following multiple choice question to "challenge" the students at this:
Which of the following statements is true with respect to the dialog functions MESSAGE and CONFIRM?
Having mentioned a technical difference already, answers 3 and 4 can be neglected leaving us the first two options. If you still don't know by experience, unveiling the logic behind can help you out:
Where a CONFIRM is wanting, and waiting for, input from the user it should be displayed immediately, a MESSAGE's use is only to inform the user and therefor there's no need to display it at the spot.
I.e. it can wait and will be pushed on a message stack to be released as soon as the system is ready for. This can be when the active process is finished or as soon as a - next - CONFIRM is being executed.
Or as the Developer and IT Pro Help for Microsoft Dynamics NAV 2013 says:
The MESSAGE function executes asynchronously, which means that MESSAGE is not executed until the function from which it was called ends or another function requests user input. The function is useful for notifying the user that some processing has been successfully completed.
I guess all experienced NAV developers know this by heart. Including the mortal sin of placing a CONFIRM inside a transactional process potentially making a whole company waiting for the Yes or No button to be pushed to free the lock on a table being modified.
Nothing mysterious and well known. But something has changed running on the 3-tier architecture. Grasping the meaning of the title of this blog?
Indeed on RTC (or Windows Client as it is called for NAV 2013) MESSAGE isn't always like it used to be. To mimic what I came across try this piece of code on both Classic and RTC and see what happens:
Window.OPEN('Indicator\@1@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@')WHILE i < 10000 DO BEGIN Window.UPDATE(1,ROUND(i,1)); i := i + 1; IF i MOD 1000 = 0 THEN MESSAGE('This is message for i = %1',i); SLEEP(5); // to enable the user to see the indicator progress and possibly push Cancel buttonEND
When does it show a message the first time?
Well as expected the first message appears after the indicator disappears, when finished.
Exactly as the Developer and IT Pro Help for Microsoft Dynamics NAV 2013 says: ... MESSAGE is not executed until the function from which it was called ends ...
Hold on: MESSAGE is displayed at he exact instance when it is called in the code!
Note that as long as the OK button is not being pushed the indicator stays at 10%! Does this mean that MESSAGE is halting my process, just like a CONFIRM would do?
I was stunned. Not in the least by the fact that I could not find any communication on this. Nothing on the forums. Hadn't anybody encountered this before? Ouch, if my thoughts were right, this would be a painful change of behavior. MESSAGE is halting my process being a potential performance degrader. This is clearly not what we want MESSAGE to do.
But I also noticed something strange. While still staring somewhat dismayed at my screen time passed by. And when I clicked the OK button in no time the indicator rushed to 20%, as if struck by lightning, and the second message popped up. Pushed OK ... 30% ... 3rd message ... OK ... 40% ... 4th message ... OK ... 50 % ... 5th message ... OK ... ... ... ... Ah, progressing to 60 % at normal speed! The indicator had to make for time lost and simultaneously the messages would emerge. Even though in this case there appears to be no message stack at the end of the process where the messages will be released from, the process only seems to halter due to call on MESSAGE. However, meanwhile the underlying process continues.
I even checked this by changing the code as follows using a newly build table having two fields, Code and Description:
Table.DELETEALL;Window.OPEN('Indicator\@1@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@')WHILE i < 10000 DO BEGIN Window.UPDATE(1,ROUND(i,1)); i := i + 1; IF i MOD 1000 = 0 THEN BEGIN Table.Code := FORMAT(i); Table.Description := STRSUBSTNO('This is message for i = %1',i); Table.INSERT; MESSAGE(Table.Description); END SLEEP(5); // to enable the user to see the indicator progress and possibly push Cancel buttonEND
Having two RTCs running, making sure that the above code(unit) is running on one client (right, below) and a page showing the Table data on the other (left, below). After having waited sufficient time I could see the inserted records in the page even though the indicator and message had not yet all passed by.
Click on the images to get a full view that's readable.
Saved by the bell ... MESSAGE wasn't halting my process, even though the UI is giving this impression. Whew!
Makes me wonder still, why MESSAGE isn't doing what it is supposed to do or what we at least are used to. In the above case it's surely misleading the user.
Having waited some time at the 3rd, or whatever message, click OK and then, while the indicator progresses, push the Cancel button on the indicator dialog. See what comes around ...
So how should I introduce this guy to you? I had never heard of Gary untill almost 2 years ago when the PRS initiative introduced itself on the NAV Techdays in Antwerp. The small and clear voiced guy next two those two lowlands "Giants", Eric and Mark. Had never come across any posts, at least that I could recall. And could not find a blog written by Gary, which felt like something missing as it was really worthwhile hearing him talk and give voice to his ideas; expressing his insights that clearly appeared to be based on experience.
And now he has emerged in the Dynamcis blog-o-sphere! So go out there and read what Gary has to share with us. Welcome, Gary. Glad you joined in.
@Gary: can't help thinking of you being the Ringo Star of the PRS Fab Four, now Vjeko has also joined in on the PRS initiative. Are there more similarities between you and Ringo apart from you being the smallest and Hamburg?
Some years ago I wrote a series on validating data in NAV. The second post in this row, called Validating Data #2: Using VALIDATE, addressed the use of the AL function VALIDATE. From recent experience I would like to update some part of this post as this seems missing in any documentation on VALIDATE, including the Developer and IT Pro Help for Microsoft Dynamics NAV 2013.
For reading ease I'll rephrase some parts. Let's start with the syntax:
Where Record (data type: record; subtype: any NAV table) contains the field Field you want to validate. The optional parameter NewValue is the value to be inserted in Field.
Using the NewValue parameter calling VALIDATE we can kill two birds with one stone, as:
is equal to:
Well, this is said so. And yes, from an assignment point of this is a valid perception. However, from the Rec vs. xRec perspective this isn't true at all.
Let's make a code example like the one used in the Developer and IT Pro Help for Microsoft Dynamics NAV 2013 and have a closer look.
that corresponds to:
[Note that I have changed the code to get it work and comply to coding standards which the example clearly doesn't.]
And we make this run together with the debugger and see what happens.
See what I mean?
Using the code as in example 1, combining an assignment statement and a call to VALIDATE in one, sets the value of "Resource No." field to 'JAN' but clearly leaves xRec."Resource No." empty.
However with example 2, both Rec."Resource No." and xRec."Resource No." are set to 'JAN'.
This gives you the possibility to call VALIDATE differently as given by example 1 and 2. Where in the first case Rec and xRec will differ, while in the latter they will be the same.