Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
From years when you needed to write any confirm message or an error message in a code there was nothing complicated. But in Business Central there were introduced new functions for both of those messages. One was already there from some time but the error handler is brand new thing which is added in Spring Release 2019.
Writing simple CONFIRM was very easy so will not discuss it deeply. However did you always add before If GuiAllowed() then ? I bet not always you remember about that.
As I see Microsoft now is changing CONFIRM messages in the system and instead of that, uses special function. Therefore there is a new codeunit Confirm Management which contains only two functions ConfirmProcess and ConfirmProcessUI.
And if you would look into the standard code there are many places where that functions are already used – I found over 340 (mostly in Codeunits).
First one, ConfirmProcess, you should use if you want to return the default value in case that the gui is not allowed. Second one you should use if you always want to return False in case that the gui is not allowed.
Here is example of standard code which uses the function from that codeunit.
I should start that writing an error message in most cases stays as it was. However there is quite a big change if we want to handle error during posting. I will give you an example with not allowed posting dates. Till now (here is code from cumulative update 3 for previous on-prem release) there was only FieldError.
Users see a normal error message when posting document with the posting date which is not in an allowed range.
In the newest release the same message looks totally different. You will see a list of all errors when you will try to post the sales order (or other document). This will give an user possibility to fix all issues before trying one more time.
How does it work? First of all there had been added two new Codeunits – Error Message Handler and Error Message Management. Also there had been added new table which stores temporary records for the error messages – Error Message.
There is also a change in function SendToPost which now allows to catch all errors which will occur during posting of document. As you see at the end of the function – if errors exists then they are shown.
To catch and store an error there is used a function in Codeunit Error Message Management – LogContextFieldError. Example how to use it you can see below.
To show you how you can use it I prepared small and very useful functionality. I added a field in the Sales Header called Always True and decided that if the field is false I should block posting. So here is a field.
Next I added a new subscriber to the event OnAfterCheckSalesDoc which you can find at the end of the function CheckAndUpdate in the codeunit Sales-Post. As you can see I did not add a simply Error() but I used function LogContextFieldError.
So now user, until mark the field Always True, will see, not only error related to allowed posting dates, but also my new message. And since I added a RecordId to Sales Header after clicking an action Open Related Record user will see my Sales Order.
I must say that I really like the idea to show all errors at the same time. It can save user a lot of time and will allow to fix all in the same run of posting.
Business Applications communities