Hippo Man

Well, I found the answer here (look for the words Registering an Addin): http://www.codeguru.com/cpp/misc/misc/microsoftofficeoutlook/article.php/c3797/

[PLAIN][sOLVED] Forcing ext_cm_Startup for a C# interop Excel AddIn[/PLAIN] How can I force my C# interop AddIn for Excel to be invoked in "connect on startup" mode (i.e., with the connectMode parameter to OnConnection to be set to ext_cm_Startup)? By default, it runs as "connect after startup" (connectMode comes in as ext_cm_AfterStartup). I understand that this is controlled by some sort of registry setting, but I haven't been able to figure out which registry item gets set to which value. Thanks in advance for any pointers to documentation that you can give me.

Yep, based on the earlier discussion here, that's what I surmised. Thanks again for all your help.

Well, what I already have is a C# Add-In which has been developed using COM Interop. It provides a number of functions that return a matrix of data. I currently return these matrices via an Object[,], and as long as the user invokes them with Ctrl-Shift-Enter after selecting a range of cells, the results nicely fill these cells. The user asked us if we could enchance the functions so that they could fill a range of cells that are specified as extra arguments to the function, and without using Ctrl-Shift-Enter. This is where I embarked on my quest to see if it's possible to do what the user wants. If this turns out to be totally impossible, it's not a problem for me to get back to the user and tell him so. Whatever we do, these functions have to be supplied via a DLL for an installable Add-In, with no macros or any other Excel objects involved. That's because it will become part of a standard desktop build that our company creates (for several hundred users), and the intention is that the Add-In will be available to all Excel users, without them having to install any special packages or run any special spreadsheets. Thanks.

Well, that explains my problem. I now see that there is no way to do what I want, and therefore, I can now throw in the towel, in peace. Thanks to all of you. This has been quite enlightening.

Well, it does indeed work. However, in that code, a brand new workbook is being created. This doesn't work for us, however, because we want our Add-In to be used within existing spreadsheets. The creation of a new workbook covers up all of the existing data in the spreadsheet. However, if I run this same code from a function within a cell, it fails. I created the following function: public String foo() { MessageBox.Show("foo(): entering."); // xlApp is already saved in a private attribute from within the OnConnection method. MessageBox.Show("Application object: " + xlApp); MessageBox.Show("Excel Version = " + xlApp.Version); Excel.Workbook wb = xlApp.Workbooks.Add(System.Type.Missing); MessageBox.Show("Workbooks.Count = " + xlApp.Workbooks.Count.ToString()); Excel.Worksheet ws = (Excel.Worksheet)wb.Worksheets[1]; MessageBox.Show("Worksheet.Name = " + ws.Name); Excel.Range rng = (Excel.Range)ws.Cells; int cc = 10; //ws.UsedRange.Columns.Count; for (int c = 1; c <= cc; c++) { rng.set_Item(10, c, "test"); } MessageBox.Show("Range.Value's have been set."); MessageBox.Show("foo(): exiting."); return ("success"); } Then, I execute =foo() from within a cell. That COM exception gets thrown on the set_Item call. Do I perhaps need to declare foo() differently (maybe with some sort of appropriate decorator) in order for this to work? Hmm ... could this be due to the fact that we're running Excel 2002 SP3 here? Thanks!

Thank you very much for all of this! It turns out that the code you supplied works fine if run it as an Automation app and create my own Excel.Application object; however, when I run it in my orginal Add-In configuration (i.e., using the Excel.Application object that is passed to me in the OnConnection handler), I still get my original exception. This happens both when I use set_Item and set_Value. I'm wondering if my worksheet is indeed protected. If so, how can I un-protect it from within the C# add-in? [P.S. - I just checked, and my worksheet is definitely not protected. What sort of incorrect installation of Excel could cause my problem to occur? I need to know what to tell the sysadmins here, in case they need to reinstall it in a different way.] Forgive my ignorance: this is all fairly new to me, and I'm learning as I go.

Thank you very much for your reply ... I indeed do. For example, from within my C# COM Interop code, I am able to retrieve any and all data from all cells on the worksheet. I gave two examples above of specific lines that fail. Look at my first message in this thread. I show excerpts of the code that I have written. The line applicationObject.calculateFull() fails. Also, the line range.set_Item(10,c,"test") fails in the same way. As I mentioned, both cause the HRESULT 0x800A03EC exception to be thrown. Yes, yes, and yes. It is only when I try to change values on the worksheet that I get failures. Note the following: I am not creating an application or workbook from within my COM Interop code. Rather, I am using the code as an Add-In and accessing an already existing application and worksheet. That is where the problem lies. In other words, if I use my COM Interop code to create a new application and worksheet, I can change whatever cells I want to change within that newly created worksheet. However, if I am using my COM Interop code as an Add-In to access an already existing application and worksheet, that is when the HRESULT 0x800A03EC exception gets thrown. This seems to suggest that it is not possible for a COM Interop Add-In to change any data on any worksheets on existing application objects, and that COM Interop code can only change data on worksheets of application objects that it creates, itself. Could that be the case?

I have a C# AddIn for Excel in which I get the Excel.Application object as follows: private Excel.Application applicationObject; public void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom) { applicationObject = (Excel.Application) application; } I can get all sorts of information about the spreadsheet via methods on applicationObject, but I am unable to change anything on the spreadsheet through this object. If I do this ... applicationObject.calculateFull(); ... or this ... Excel.Worksheet ws = (Excel.Worksheet) applicationObject.Worksheets[1]; Excel.Range range = (Excel.Range) ws.Cells; int cc = ws.UsedRange.Columns.Count; for (int c = 1; c <= cc; c++) { range.set_Item(10, c, "test"); // row 10 starts out empty and unlocked } ... or anything else which attempts to change the contents of the spreadsheet, I get an HRESULT 0x800A03EC exception. I've searched around the net, but I can't find anything which helps me get past this error. Some people have talked about localization as a possible cause of errors like this, but if I do the following before making the offending calls, I still get the same exception: System.Threading.Thread thisThread = System.Threading.Thread.CurrentThread; thisThread.CurrentCulture = new System.Globalization.CultureInfo("en-US"); Therefore, I don't think that localization is the issue. Could it be that COM Interop doesn't permit me to change anything on the spreadsheet via that Excel.Application object? If so, is there any other way to accomplish this within a COM-Interop-based AddIn? Thanks in advance.

Thanks! This is exactly the information I was looking for.

P.S. -- I want to do this without any auxiliary macros or VBA code in the spreadsheet. I want all the logic to exist within the AddIn DLL that gets built from the C# COM Interop code, assuming this is possible. Thanks.

I have written an AddIn for Excel using C# and COM Interop. It is working fine, but there is something that I want to do that I haven't been able to find any information about. I want to access the Application object for the current, existing spreadsheet from which the AddIn is being invoked. I know that I can do this to get an Application reference for a new Excel instance: Excel.Application app = new Excel.Application();However, I don't want a new instance; rather, I want the existing Application object that represents the Excel instance from which my C# AddIn is currently being invoked. How do I get this current, existing Application instance from within the C# COM Interop code that implements my AddIn? Thanks in advance.