herilane

The exact scenario you have outlined is, as you put it, totally impossible. The closest you could get is a menu option or a toolbar button that asks the user for the parameters and does the thing.

Perhaps we should all take a step back... What do you really want to achieve?

There is a fundamental difference between "normal" procedures - invoked by the user, or by events, or by other code - and worksheet functions (traditionally known as UDFs or User-Defined Functions in the Excel world). A UDF must not change anything in the worksheet or the application. It may only return a value. To put it differently, functions called from a worksheet cell must not have any side effects. This makes perfect sense, really. Imagine if calling a simple function like =MAX(A1:A5) could change totally unrelated cells in a worksheet. Complete chaos would ensue.

No, there is nothing inherent in COM Interop that prohibits changing an Excel workbook. (If that was the case, that would make COM Interop rather useless.) 1) Check that you actually have an open workbook at that point. 2) Which line of code actually fails? Are you able to get the worksheet object? Are you able to get the range object? Are you able to read cell values?

The OnConnection event (of the IDTExensibility2 interface, which you add-in must implement) has a parameter called Application which gives you a reference to the Application object. http://support.microsoft.com/?kbid=302901

In my experience, the great fundamental truth is simply that automating Office from .NET is unpredictable. One thing that is missing from your code (and one of MS's examples - though it is present in another) is closing the workbook. Quitting Excel should normally take care of that automatically, but not always. oBook.Close() The other thing you can try is break down all calls to the Excel object model and do them one step at a time, as outlined in the first of the KB articles you link to. I don't know what the logic of that rule is - sounds about as logical as wand-waving and incantations to me. But it sounds to me like some part of the COM Interop process just can't do two things at a time and needs things to be simple. That would explain (in a very broad sense of the word) why uncommenting that ToString makes things break down.

Office applications are simply not made to be run on a server... This could be a permissions issue, or it could be an unfixable problem with automating Word on a server. I've seen this problem mentioned before, but never seen a solution being proposed. Articles that you should read: INFO: Considerations for Server-Side Automation of Office How To Configure Office Applications for Automation from a COM+/MTS Package How to configure Office applications to run under a specific user account How to configure Office applications to run under the interactive user account

From the code you've posted, it looks like the range you're trying to sort only has 1 row (A1:D1). Sorting a single row wouldn't really be visible. Redefining oRng so that it covers the entire range might solve the problem. In any case, if you're not sure whether the sorting is failing, or whether the saving is going wrong, just make the Excel application visible and step through the code line by line, and look at what Excel does.

Worksheets in an Excel workbook are equivalent to tables in a database. Have a look here for examples of retrieving table information.

Since this isn't about automating Excel but inserting data into an existing Excel spreadsheet using ADO.NET (I presume), the macro recorder won't help you - you simply cannot record a macro that performs this action... Shaitan00, does the table already have data, or is this the first row? The reason I'm asking is that the Jet driver for Excel uses existing records to determine the data type for each column. When the table has no data, all columns are assumed to be text. This MSDN KB article has more information about this. (The article is about ADO and not ADO.NET, but the driver is the same, and none of the "ADO.NET + Excel" articles I found covers all the nitty-gritty as well as this one.)

Well, here's what's going on: // workbook is created; 1st sheet is active. // do some stuff... oSheet = (Excel._Worksheet)oWB.Sheets["Sheet2"]; // oSheet now points to Sheet2 oSheet = (Excel._Worksheet)oWB.ActiveSheet; // since the 1st sheet was active ( = ActiveSheet), // oSheet now again points to what started out as Sheet1!So lose the oSheet = (Excel._Worksheet)oWB.ActiveSheet; line and it should work fine.

The number of rows in an Excel spreadsheet is always 65,536... I assume you are actually trying to get the number of used rows? UsedRange might return a single row if you enter data only in, say, cell A5 and don't touch A1:A4 (no formatting, no data). Rows 1 to 4 would then not count as used. Have you checked ws.UsedRange.Address - does that offer any clues? Have you checked that ws is the right worksheet? For any more specific help, I think you'll have to post a sample workbook that's causing trouble, and more of the code that you're using.

The legend entries are based on the series names. As far as I know, you cannot edit the legend entries directly; you'll have to change the series names instead.

First: 'this should be without the New keyword, because you'll be opening an existing doc: Dim wdXml As New Word.Document 'should be Dim wdXml As Word.DocumentSecond: are you sure that the document has two tables? If you're not 100% sure, check wdXml.Tables.Count before proceeding.

Have a look at this KB article: http://support.microsoft.com/?kbid=319398