I have used Excel Dna to create .NET xlls and use it in my addin and excel worksheet functions.
I also use ExcelDnaPack.exe to package my xll.
I was wondering if excel dna supports, any ways to generate documentation for my library API's.
Thanks,
Mani
Firstly, Excel-DNA allows you to integrate into the Excel function wizard with descriptions for the functions and the different arguments. These are added to your function using attributes:
[ExcelFunction(Category="My functions", Description="My useful function")]
public static double MyFunc(
[ExcelArgument(Description="is an important parameter.")] double param1,
[ExcelArgument(Description="is unimportant.")] double param2)
{...}
The function wizard also allows a help link for each function.
If you have a help file, say in .chm format, you can tell Excel-DNA to hook up the help link like this:
[ExcelFunction(HelpTopic="MyHelp.chm!102")]
public static double MyFunction() ...
How to get the help file? The C# or VB.NET compiler can generate an xml file from the xml /// comments in your code. This .xml file is processed by something like Sandcastle - here's a whole discussion on that part: Generating Documentation from C# XML Comments.
But Excel-DNA has nothing at the moment to automatically relate the functions and their topics. I'm not sure how hard it is to figure out the generated TopicIds from the Sandcastle output, or to set them from the code in the xml comment. If it's an issue, an automatic topic hookup or even a help generator tool might be a nice feature to add to Excel-DNA in future.
It is also common to add a ribbon to your Excel-DNA add-in with a button that displays a help file for the whole add-in.
Edit: There is now a user-contributed project that processes Excel-DNA to generate help files more easily. See https://github.com/mndrake/ExcelDnaDoc
Related
Are there any good ways of parsing Excel files in monotouch? Seems like most methods to work with Excel is based on using the Excel Object Library. Doesn't seem like that's even an option in monotouch? I read that objective-c doesn't have any native support for Excel-files, so don't know if that would change anything?
You would need to either
write your own
find an obj-c library that does it and write MT bindings for it
find a open source .NET library and port it to MT
If all you want to do is display a file, you can use the existing iOS document APIs to do it.
The newest Office formats are XML based, so depending on how complex the files are, writing your own parser might be feasible to do.
I ended up just writing the middle step, a web service that fetches the Excel file, parses it and serves up the content as xml/json.
I have code that worked in the VSTO version of an Excel Addin
Microsoft.Office.Tools.Excel.ListObject lo = Globals.ThisAddIn.VSTOWorksheet.Controls.AddListObject(r, "lo1");
lo.AutoSetDataBoundColumnHeaders = true;
lo.DataSource = dt; //some DataTable
I was using this API because its declarative databinding syntax. And the Excel.Interop API didn't have methods such as AutoSetDataBoundColumnHeaders..
If I can get Microsoft.Office.Tools.Excel.ListObject imported, how will I resolve the Controls collection on which I call AddListObject without the VSTO stuff inside Excel DNA ?
Any solution would be nice, even if it involves scrapping my code, but in general I'd like to understand when to use which API inside of Excel DNA in order to accomplish this databinding stuff.
VSTO adds some extensions on top of the Excel object model. I have no experience with VSTO, and for stuff like the ListObjects I can't tell where Excel's object model ends and the extended VSTO wrapper objects start.
The boundary is basically this: Microsoft.Office.Interop.Excel can be used from Excel-DNA (so this is the ListObject interface you can use: http://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.listobject_members.aspx). Microsoft.Office.Tools.Excel is part of VSTO.
Also, I really have no idea whether the VSTO libraries can be used together with Excel-DNA. The issue would be getting the VSTO libraries initialized and hooked up - it might be tricky.
It might be worth it for you to try to re-implement those object model extensions yourself, on top of the Excel object model. I don't think VSTO is doing anything you couldn't do yourself.
Does anyone know of resources that can help me export simple contents of a GridView to a native Excel 2007 format (i.e. the OpenOfficeXML format).
I've already seen solutions like Matt Berseth's, and in fact I have been using that for a while, but it comes with an annoying warning produced by Excel 2007 as documented here stemming from the fact that a native Excel file is not generated; rather it is HTML.
My initial research shows that, at the core, xlsx files are zip files, but I have no idea how to produce these or what goes in them.
Any suggestions (or tutorials) would be greatly appreciated.
CarlosAg has an ExcelXML writer which works really well. It isn't a native excel 2007 formatted file, but it will be readable in excel 2007.
You will need to write a little method to do the exporting manually, the API is very straight forward though. You will create a sheet object, then a row object, then a cell object. You can just loop through your data and output it. The examples on the site are pretty decent.
I prefer using Microsoft's own Open XML Format SDK. It is free, it is released by Microsoft and it creates real .xlsx files.
You can find the reference documentation here, as you can see, it is pretty straightforward to use.
SpreadsheetGear for .NET can read and write native xls and xlsx files and is easier to use (takes less of your time) than other solutions because it has an Excel like API so you don't have to learn anything about Open XML.
You can see some live ASP.NET (C# and VB) Excel Reporting examples here and download an evaluation version here.
Disclaimer: I own SpreadsheetGear LLC
How can I read an Open Office 3.0 spreadsheet (.ods) from Groovy? I'd like to select specific columns from a named worksheet. Ideally, it would be useful to add a 'where' clause, or other criteria clause.
I've never used it, but Open Office has a Java API, which of course you could use from Groovy as well. It looks like the best places to start reading are the Developer's Guide, the Java UNO Reference, and the samples in Java and (hey!) Groovy. Hope that helps!
Might be something here at Spring Factories or here at Groovy and JMX. There is a forum for Groovy and Open Office.
Could you export the table / spreadsheet as SQL entries then use that. You could also look at this plugin for goovy -- http://www.ifcx.org/
OpenOffice documents are ZIP files which contains the document data as XML plus some other files (style sheets for word documents). Details can be found here.
The main problem with calc is formulas. If you just have tabular data, then you can simply read the cell values and use that. So you can open the ZIP archive, read the content.xml in it and parse that with any XML parser.
But when a cell contains a formula, then you need to execute it. In this case, you will have to open the document via the UNO API. Here is the Java version. There is a link where you can download example code that explains how to open ODF documents and how to examine their content. There are also snippets but none of them show how to examine a sheet.
The main disadvantage of UNO is the documentation. Each method is explained somewhere but you have to find the method which solves your problem, first.
Since the title does not mention Groovy (only question specifics does), I didn't want to make this a new question.
How to generally read an Open Office spreadsheet document? There are tools for creating one (ooo-python) but not for reading one. They are XML but just bluntly diving into that and trying to get the right logic of extracting the data I want seems so sub-optimal.
What I'd like is features similar to Excel COM support, but from a command line tool (or scripting language).
We have an existing add-in that we publish to users via click once. We would now like to use this as a vehicle to publish some of our existing C# methods directly into Excel so that the users can call them as a UDF.
For example - I have an assembly called MyAssembly, that has a class called MyClass with a public method called MyMethod. I also have an excel addin which adds some item to the ribbon for some custom functionality. I would now like to publish MyAssembly with my existing addin so that a person who has the addin installed can enter =MyMethod into a cell and have my custom method run.
How would one go about doing this?
I solved this quite comprehensively by using ExcelDna, an open source XLL implementation which is very simple to use, and pretty much avoids the whole COM debacle all together. So far it has matched our requirements perfectly...
http://groups.google.com/group/exceldna
you have not been very verbose about what you want to do. What do you mean with "users can call them"?
If you mean that add-in methods should be exposed to VBA you can find two articles on that here:
http://blogs.msdn.com/andreww/archive/2008/08/13/comaddins-race-condition.aspx
http://blogs.msdn.com/andreww/archive/2008/08/11/why-your-comaddin-object-should-derive-from-standardolemarshalobject.aspx