Catching errors - cleaning

Denis_Vitse

Hi all,

I know this subject has been tackled several times before but I'm not sure if one of the provided solutions could apply to my particular case:

I'm using the 4.x mapping Excel to import from several jetreport Read/write files. That is people use the xls to extract data with Jet, then modify data in Excel and finally execute some macro to generate mapping lines to be imported in a special manner (custom processing of mapping).

What I need is to know if there is a testfield or error that breaks the execution of the import process I have a mean to clean Automation server instances in memory. Currently that's still based on "task managing" Excel manually ( ) each time there is a runtime error, which doesn't looks pretty...

I know there is no exceptions management in Nav but can I at least point to some trigger somewhere? Could I use the IF codeunit.RUN workaround in my case?

Thanks in advance and best regards,

Denis

ta5

Hi Denis
It should be possible to use the "if codeunit.run" construct, then clearing the automation variables.
What might be easier: Open the xls from within Navision and set the Excel-Application object to visible. If something fails, the user can safely close the excel window.
Hope this helps
Thomas

Denis_Vitse

Hi,

Concerning giving back control of the file to the user, it would not fit: I unprotect files before beginning the import as we don't want the user to have access to what's generated "behind".

I will test the codeunit.RUN.

Thanks Thomas,

Denis

Denis_Vitse

Hi,

after trying hard the solution advised, I'm still unable to properly uninstantiate Excel when a runtime occurs in Nav code.
Here is my code to command the codeunit. I access mapping functions through the prototype in text compared in a CASE statement and a Variant array for parameters :

// XlApp, XlBook, XlBooks are local variables passed by ref (VAR) to the different functions here

IF CONFIRM(Text002) THEN BEGIN
CLEAR(ParamTab);
CLEAR(MappClass);
ParamTab[1] := Rec;
ParamTab[2] := '';
ParamTab[3] := FALSE;
ParamTab[4] := FALSE;

// Instantiation through a local function
CreateBook(XlApp,XlBook,XlBooks);

MappClass.SetFuncName('ImportDataSingleSheet',ParamTab,TRUE,XlApp);
CLEARLASTERROR;
IF NOT MappClass.RUN() THEN
MESSAGE(GETLASTERRORTEXT);

// uninstantiation
CloseBook(XlApp,XlBook,XlBooks);
END;

when a runtime occurs during MappClass.RUN(), the code continue its execution and goes to CloseBook(). This is a good point.
Here is its code:

CreateBook(VAR XlApp, VAR XlBook, VAR XlBooks)
{
XlBooks := XlApp.Workbooks;
XlBooks.Close();
XlApp.Quit;
CLEAR(XlApp);
}

but this code can't clean Excel instance that stays in memory, even with the Quit ](*,)

Any idea would be greatly appreciated...

Denis

Denis_Vitse

OK, I'll answer to myself :whistle:

I found my problem was more due to acting the right way when cleaning Excel automations than a real Nav problem. It looks like it's now working, thanks to some debug, meaning I can "catch" runtime errors and do whatever cleaning I need... But what a pain in the A!!!

Denis

jlandeen

thanks for sharing your experience...I always find these error trapping exercise a true test of working with Navision. Error handling is not something that works very well with Navision and the If Codeunit.Run contrstuct really is about the best we have....at least now we have Getlasterrortext!

Denis_Vitse

Exactly!
Thanks to these new System functions clearlasterror and getlasterrortext. But I'd rather work with real exception handling! Let's hope it won't too much longer before M$ gives us a way to get in real object oriented programming in Nav.

Denis

ta5

Yes, but hopefully the implicit transaction handling (rollback, etc) keeps as save and easy as it is...
Thomas

jlandeen

I generally find that the current error handling procedures in Navision are "good enough" given the existing object model and architecture. As they transition to a 3 tier architecture and work in a more .Net centric environment (i.e. object oriented environment) this will hopefully change...but I do hope Microsoft treads carefully and preserve as much of the simplicity of the development environment when they do.

Denis_Vitse

True! The implicit transaction side is a nice thing to have but can sometimes become a pain as well.

Anyway, as it's been said so many times before, it is not a general programming environment but a dedicated one and we already have several nice features included but from the time some precious and needed one could have been added (prog language and dev studio), it's hard to wait and keep on writing boring lines of code.
I must recognize we have nice features though like callbacks entry points from automations, recordrefs, fieldrefs and soon the webservices...