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?
CONFIRM vs. MESSAGE
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?
- The display of a CONFIRM is being postponed till all remaining code of the process running has been executed, whereas a MESSAGE is being displayed when called upon
- The display of a MESSAGE is being postponed till all remaining code of the process running has been executed, whereas a CONFIRM is being displayed when called upon
- There is no difference, the display of both is being postponed till all remaining code of the process running has been executed
- There is no difference, both are being displayed when called upon
What do you think?
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?
Classic vs. RTC
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 button
END
When does it show a message the first time?
Classic
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 …
RTC
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.
Fast as light
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 button
END
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.
Bonus
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 …