Wizard pages are working on a revival from being almost forgotten. They were first introduced as form objects in Navision 3.0 as part of CRM. I instantly fell in love and started to create them for my own add-on.
Wizard pages have a few great advantages to normal pages and let’s go over them.
We almost lost wizard pages when Microsoft introduced the Role Tailored Client. There are only a few of them in the standard Application and the ones that do exist were in a part of Navision that Microsoft could not care less about since someone in Redmond had this briljant idea of replacing NAV CRM with Dynamics CRM which resulted in the name change of our module ro RM.
Fortunately for us some large partners had quite a few wizards in their ISV solutions and Microsoft “hacked” wizards in last minute using the Navigate page type.
Then we almost lost them again with the introduction of the Web Client. Again the Navigate Page was outscoped and the “Navigate Page” was changed to a Worksheet leaving only wizards as Navigate Pages.
Are you still with me here?
Now as part of the Saasification (a word that I hate) of NAV they are back and as always Microsoft is talking about it as if they’ve invented the freaking wheel, but they are over a decade old and the design pattern has not changed. Another proof of how smart the “old” patterns of NAV are and their validity.
Enough Navision history, get on with it…
For my ForNAV App I also wanted to make a Wizard page, just to prove how easy it is to make them and to be able to write this blog. I also firmly believe that wizards have nothing to do with “Saasification” but should be a normal part of any ISV solution.
Step 1 – Copy with pride
Wizard pages are suprisingly simple. The page itself is built on the table that you want to populate with the “SourceTableTemporary” property set to yes.
This gives a few restrictions. You cannot just build a wizard page on any table since many of the normal NAV tables have code in Validation triggers that assume you are doing something for real. If this is the case, or if you have a more complicated wizard you can make a decidated table and use that for your wizard.
DO NOT ABUSE TABLES! I cannot stress this enough. I tell it in every patterns class that I teach. Never, ever abuse any table as temporary table. Even for bespoke customer scenarios just create new ones. They are free, because Microsoft won’t check the customer license. We are not writing data to SQL.
For my wizard page I’ve stared with the Email Setup Wizard page (1805). This is a two step wizard page that has the base plumbing you need and if you copy it you make your life easier than starting from scratch.
Step 2 – Clean Up
The next step is to change the SourceTable property to your table (ForNAV Setup for me) and clean up the fields you don’t need. There is a bunch of stuff you don’t need and the compiler will help you find it.
After this step you should have somthing like this:
You now have a clean wizard with two steps. The images are already there but they only show up in the Web Client.
Step 3 – Change the descriptions
You need to change the explanations in the wizard. You don’t want your wizard to say, “Hey, welcome to email setup, let’s make it work”. You rather want something like this:
Step 4 – Change the code
You need to write C/AL code, which is cool, because C/AL is a great language.
First of all, you need to read the current values so the user get’s a headstart.
And you need to comment out some code temporarily until you’ve figured out what you want to do instead
Step 4 – Add your fields
In this step you need to add your fields and you need to decide how many steps you need. In my case two steps are fine, but the standard naming of the two steps in the email wizard are specific so I decided to simply rename them to Step1 and Step2. This allows me easier to copy and paste stuff to next wizards and makes the pattern more repeatable.
In my case I have two fields I want to setup
Step 5 – Add other stuff
In case of the ForNAV App I also want to change the values in the Report Selection so the Sales Invoice changes to the ForNAV Sales Invoice. This is an optional step although it does not make a lot of sense not to do it.
To add this in the wizard I need to create a variable and put that on a step
Step 6 – Finish and Store
The last step is to store the data in the real table and execute aditional code. In my case I need to replace the reports when this option is selected.
Off course, ReplaceReportSelection is a method of the Setup table, and those of you who were in my workshop will know that (TRUE) means HideDialog.
Step 7 – Assisted Setup
Wait, you said that Step 6 is the last! True for this blog, but you can also connect your wizard to the Assited Setup for Dynamics 365. This will be another blog.
The result is a nice step-by-step wizard that allows you to easily setup the App with some guidance.
In my previous post I’ve created a Notification and I want the notification to run the wizard. I also want to run the wizard if somebody imports the fob file and runs the report from the object designer.
Lastly I want to have a default setup so I don’t want to go through the setup each time I do some playing around.
For this I’ve created an interface codeunit that I can run from everywhere. It asks me if I want to use default values or run the wizard.
This Codeunit I run from each ForNAV report and from the Notification.
So here you go! You have the wizard pattern. Enjoy! Any feedback is appreciated.