Hi,
I want to upgrade certain reports that were written to drive Excel output. These reports used the Excel Automation functionality in the 2009 classic client as we needed more control over the Excel output than could be achieved using the Excel buffer table e.g. merging columns, setting column widths.
With NAV2013, it seems the Automation works the same with a small change to the CREATE function. However, all the press indicates it is a lot faster to use the dotnet functionality. I have been trying without success to get this to work and wondered if there is any help out there on this subject.
The typical Automation variables that I am used to setting up are:
xlApp
xlWrkBook
xlWrkSheet
etc.
The typical functionality that I use in the existing code with Automation is:
XlWrkSht.Rows.Range('1:6').RowHeight := 20;
XlWrkSht.Range('B:B').ColumnWidth(17);
XlWrkSht.Range('A2:A3').Merge;
XlWrkSht.Range(PassedCellRef).HorizontalAlignment := PassedHorizAlign;
XlWrkSht.Range(PassedCellRef).VerticalAlignment := PassedVerticalAlign;
XlWrkSht.Range(PassedCellRef).WrapText := PassedWrapText;
etc.
The equivalent dotnet functionality seems to be there in the Microsoft.Office.Interop.Excel assemblies but I cannot seem to get them to work.
The first issue is that I am getting error messages when trying to create an "Application" variable - the message says:
".NET interop: internal error, bad id '27 : 1'."
This happens when creating a dotnet variable of subtype "Microsoft.Office.Interop.Excel.Application" or "Microsoft.Office.Interop.Excel.ApplicationClass" in Office 2013.
If you look in table 370 this Application variable exists but if I try and copy and paste it (even into the same table) I get the error message. In Office 2010 it errors on Application and in Office 2013 it errors on Applicationclass.
If I experiment with code in table 370 (trying to use the dotnet equivalents of xlWrkBk and xlWrksht) I invariably end up with a message telling me that the dotnet variable has not been instantiated.
I can see that in table 370 there is a line of code to instantiate the Application variable in the PreOpenExcel function
XlApp := XlApp.ApplicationClass;
This uses a configurator but in Office 2013, there is no configurator for Application but there is for Applicationclass so I assume it is used differently there.
If I try the above and then try and work with the workbook and worksheet variables, I get stuck on the instantiation message.
The new excel buffer table (370) seems to have been re-written with some NAV specific dotnet functions (Microsoft.Dynamics.Nav.OpenXml.Spreadsheet) . This leads me to believe that the developers have add to build specific assemblies and that the old functionality we used to have with Automation may not be so readily available??
I am not sure if we are supposed to use the OpenXML methodology now to do what we used to with the Automation method?
So, in summary, can anyone point me in the right direction as the best way forward to convert these reports using dotnet variables or should I just continue to use the Automation?
Thanks!
](*,)
0
Comments
I'm not a hero in OpenXML either but it seems that all the tweaks we made in table 370 have to be redone.
Reasons for the change are performance and the fact that Automation is a relatively old technology.
On this blog it is explained how to do this with NAV2009.
http://www.kauffmann.nl/blog/index.php/ ... t-interop/
Yes, you can go back to Automation, but that will only run on the client side and have poor performance. Likely in the future this feature will be removed eventually.
I would like to help you since i already done an excel import with plain interop, but i don't understand what exactly your problem is.
Here is an example of my import, let me know if this helps you and where you still have problems:
Important is the EnumToInt Function, its a function to get the integer value from an enumeration , i explained it on my blog: http://devch.wordpress.com/2013/01/18/net-interop-using-enumeration/
You can skip that and just pass the integer value of xlWindows but for me this is a lot more readable.
I was pointed to this question by Luc van Vugt, because my blog was mentioned here, and he was wondering if I had a solution for the .Net interop error.
After some investigation I found out a workaround. It is a very strange one that I cannot explain. But it is working:
Steps to overcome the .Net interop error:
1. Ignore the errors when creating the .Net variable of type ApplicationClass. (There are two errors, bad id 27 and 29).
2. Save the object without compiling
3. Export the object to text
4. Import the object from the text export
5. Compile it
Again: I can't explain this behaviour, it sounds very strange to me, but it definitely works. :-#
The ApplicationClass is needed because the constructor of this class returns the Application object, which is the Excel application that can be made visible to the user.
My blog
Here they are.
Multiple Sheets Font Size Backgroundcolor (preferably HTML coded) Foregroundcolor Hyperlinks
http://dynamicsuser.net/blogs/mark_brum ... uffer.aspx
Do you have more?
Wrap Text
Column Width
Merge Cells
Cell Justify
In addition to what's been mentioned to the excel buffer table:
Font Size
Font Name
Horizontal Align
Vertical Align
and have used the following calls for pictures and pivots
XlWrkSht.Shapes.AddPicture
XlWrkBk.PivotCaches.Add
XlWrkSht.PivotTables
PivotField := PivotTable.PivotFields
PivotField.Orientation
PivotField.Function
I use the following commands in the ClosedXML. I want the Excel document to be properly setup for printing and viewing.
Gunnar Gestsson
Microsoft Certified IT Professional
Dynamics NAV MVP
http://www.dynamics.is
http://Objects4NAV.com
By the way: I've implemented font & color with pure C/AL & .net Interop, the code can be found in the tips&tricks section:
http://www.mibuso.com/forum/viewtopic.php?f=5&t=57925
1.Download ClosedXML for .Net Framework 3.5.
2.Unzip the file and copy ClosedXML.dll to the Add-ins folder of your Classic Client and the Service Tier.
3.Download DocumentFormat.OpenXml.dll. (Part of the Open XML SDK 2.0 for Microsoft Office, you can download and install the complete SDK as well)
4.Locate the downloaded (or installed) DocumentFormat.OpenXml.dll and copy it to the Add-ins folder of the Service Tier
I have done #1 and I have copied it to C:\Program Files (x86)\Microsoft Dynamics NAV\70\RoleTailored Client\Add-ins,
but I do not have a clue for the rest Would someone please provide a little more instruction.
I know the Service Tier referres to NavServ, NavSQL and NavClient(listed above)
How can I find out wher the Add-in folder is on NavSQL and NavServ?
I really need this addin. It is just what I have been looking for.
Please help.
I am sorry of I hijacked this thread, but I am also trying to replicate the Excel Buffer using plain dotnet interop.
[url="http://forum.mibuso.com/discussion/65275/import-to-nav-from-excel-using-interop#latest[/url]
Looking at DevCh example, I am getting stuck on the XlRange part of the code, getting the error:
Any help is appreciated.