The other day I had the task to customize the Import Budget from Excel and Export Budget to Excel batch jobs. To incorporate changes made in Financial Management as part of a major add-on we are building. Although the add-on is directly implemented for RTC, I decided to first get the batch job working on Classic as it would enable me to easily debug and stay as close as possible to standard code. Unexpectedly I got the whole thing working very easily, so I set off in a very good mood for RTC.
Of course I had clicked the error away before I could have read it well, probably thinking that I had done something wrong. So another run and ... error:
Typically a programmed error and apparently now, on RTC, code was touched that wasn't on Classic.
Help, I need a debugger!
Up till now I had managed to circumvent debugging RTC using Visual Studio. But clearly from now on no way to get around it, unless I would drop the whole customization task on someone else's desk. Well ... no option, really. And, honestly, if someone in our team should pick up learning to debug RTC I think all fingers would point at me anyway.
So I roamed around looking for info on how-to. And it showed not that difficult at all. Well, OK, I am not a fluent C# reader, but I seem to manage; not in the least through the original C/AL code lines having been inserted in the .cs files as comments.
Equipped with this knowledge and VS set up right I went off going through the code step by step, meanwhile
But all to no avail.
Every time the code execution stopped at the same error. Out-commenting the error throwing code made the import batch job stop at other code throwing errors; and another, and .... All code not touched in Classic Client.
Because of other tasks planned I had to let loose of the issue for a couple days, returning to it last Monday in high spirits.
Started RTC and opened the budget page to execute the import again.
%&!^$&!#)(*$!$&!#_*
Patience, Luc. Was that my guardian angle?
OK, I will.
So I went into a more detailed analysis mode with less data in the Excel file and I analyzed the import in all aspects seeing the code translate the Excel structure into a set of records. Understanding exactly what the code was doing. And of course in Classic Client as the batch was working fine there.
RTC, here I come. Lucky Luc! (I truly was hoping)
Set up VS. Started RTC. Ran the process as before. Error again.
So now I wanted to watch the ExcelBuf variable and see whether the Excel data were transfered right into NAV records. It showed what I expected. Same details as I had seen on Classic Client.
And as all Excel cells where copied to NAV I hit F5 to let the process continue to the end without stepping through the cod,e awaiting the well known error. Waiting ... progress indicator continued ... waiting ...
?!?!?!?!?!?!?!?!
Well, let's click Yes.
?!?!?!?!?!??!?
Just running the debugger in a somewhat different mode solved the issue. Well, at least gave the desired behavior.
Now I did rerun the process a couple of times and the result was OK every time. Wonder what will/can happen at customers once you would go live with this.
When they call because of an issue should we suggest to turn on VS debugger, select a variable to watch and run it again. Problem solved!
Hey, you, C# experts! You, VS wizards. Any idea why this is happening like this? And .. can I trust NAV (RTC) to run well from now on?
So there I was sitting, stuck on a process running on RTC, throwing errors that typically did not occur on Classic. No RTC specific debugger (yet). But ... never to young to learn!
Unless C# is like cipher to you, it's not to difficult to get things working and go for it using these links:
Some interesting forum posts to read:
Yesterday a good post on the NAV Team blog was released:
The 3rd DDC event has been planned for May 19. So mark it in your agenda. As before you are welcome at 18:00h. After a joined meal we will kick off around 18:45h with a keynote followed by two parallel sessions. Session topics will be based on your input to a new poll on our website. Niet that, as the website is being updated, the poll still has to be published. More details will follow on our blogs, on website, on LinkedIn and in our newsletter.
For those who had themselves enlisted for the previous events: we will be sending you the newsletter by mail.
For others interested to receive the newsletter: send a mail to info@dutchdynamics.net to request it.
If you already want to subscribe to the 3rd event, send us a e-mail: events@dutchdynamics.net with the following details:
A recent question posed to me regarding the subject brought back a lot of memories on how I came around learning about this. I still remember the day that *** (Ben McDakkie) and I drove down south to our Belgian Navision sister company. Herman would learn us all about the insides of Online Help (OLH) creation. Those around NAV already for some while may recall that, with Navision Solutions, HTML Online Help was the successor to WinHelp and introduced a much better and nicer Online Help system, but also a bit more complex. I seem to recall that both *** and I found it too complex. For sure it took another two years, already the MS era, before we converted the existing NL OLH into HTML Help; not only after Jan had build a C/SIDE based OLH tool called C/Help that was provided to NL partners and that surely filled a gap. I still regret that, so far, it did not get a successor. It was a very intuitive tool that automated a lot of tasks and made the threshold to start writing OLH tremendously lower. For about 5 years this was one of the main OLH tool in the MS Dynamics GDL team.
One of the things that C/Help made easy was the creation of index entries. So actually I didn't have to think about it a lot, but restless mind I can have, I was trying to get to understand (and sometimes even improve) the nuts and bolts anyway.
The index gives the user the possibility to search the OLH based on specific terms. HTML Help does this based on a list of catchwords that have been provided by the one who has build the OLH project. Basically you have two options for creating (storing) index entries:
To me the first option is the best as you do not have a separate to maintain when making changes to various topic files. Think of the case where a topic file that has become obsolete. Deleting the topic file (that contains the index entries itself) does not need any additional action for the .hhk file.
So how does that look like? Let me use the topic displayed in the screen shot above: Creating New Account Schedules. If you right click on the topic it will give you the menu option to view the source of the topic:
These are index entries stored in this topic:
Various hints and rules on how to phrase and select words for index entries can be found in the references.
In the past the Online Help tools were released as part of the NAV Tools CD and contained are very detailed guide called Online Help Guide for Microsoft® Business Solutions–Navision® (NOHG.pdf). With the introduction of the new Microsoft Dynamics NAV Help Toolkit the information has been compiled in an accompanying help project. Unfortunately it does not give you as much information, so if possible get hold of NOHG.pdf.