Home |
Search |
Today's Posts |
#5
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
What happens if you run same code from a normal module in say Word on the
client machine, with no open instance of Excel. Include - If tempAddin.Installed Then s = tempAddin.FullName debug.? Dir(s) = tempAddin.Name, s 'open code Regards, Peter T "pagates" wrote in message ... Hello, Thanks for the replies. Here is some more information (sorry for the lengthy response). The Add-In file does exist, and that is confirmed by putting a call to "AddToDebugFile" (a sub that writes data to a file in the temp directory) with the Add-In filename before the open. As far as running "unattended," that is not quite true. This is an "all in one" box containing both client and server. It is running invisibly. The code that calls the Add-In is a VB6 ActiveX EXE, which in turn is called by another Active EXE, which in turn is called by a Standard EXE running as a service: Scheduler Service - Queue Manager - Excel Automation Manager - Excel I don't believe that it is the security settings (unless the automation security is different). We have added the registry settings that modify security to allow Add-Ins to work, and I have also set Macro Security to Low. When opening Excel as an interactive user, there are no warning dialogs. Stepping through the Workbook_Open code via the debugger produces no error dialogs, and behaves properly. However, I don't believe that we are even getting into this code, because we had added some debug code to create a debug file as the first step in that event. Adding the DoEvents around the open was a good idea; however, it did not help. There is still a dialog opening, invisibly. Hopefully, I've given enough information to show what is happening, and roughly how our application works (or doesn't work, in this case....). Unfortunately, this is "inherited" code that needs to live on. Thanks, pagates "pagates" wrote: Hello All-- Before I get to my problem, let me acknowledge that I understand what we are doing is not supported by Microsoft (KB257757). This thread is not intended to be a discussion on whether Microsoft should support a part of their product that is available for use. Anyhoo... We have an application that uses Excel Automation to run scheduled reports (that use an Excel Add-In). In order for the application to use the Add-In, it must open it during initialization. We do so as follows (simplified): Code:
Dim ExcelAPP As Object Dim tempAddin As Object Set ExcelAPP = CreateObject("Excel.Application") ExcelAPP.DisplayAlerts = False ExcelAPP.AlertBeforeOverwriting = False On Error Resume Next For Each tempAddin In ExcelAPP.AddIns If tempAddin.Installed Then ExcelAPP.Workbooks.Open (tempAddin.FullName) End If Next The problem occurs when we try to open the Add-In - it hangs there, with no error thrown. We know that it hangs on this line because we have put debug code in to put something in a file before and after it. We put some code into the Workbook_Open event of the Add-In that would put debug messages into a file, and also tried putting a Sleep in there. Sometimes we see the debug file, sometimes not. Sometimes it does hang when we try to open the Add-In, sometimes it does not. It is not consistent from machine to machine, or even on the same machine, making it seem like a timing issue. When running this code, we do hear a "beep," likely meaning that an invisible error or warning dialog is up, and cannot be acknowledged. If we could even see or find out what this dialog was, it may give us a clue to a fix. Thanks, pagates |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Excel 2003 c++ automation problem. | Excel Worksheet Functions | |||
Problem in graph automation in excel. | Excel Programming | |||
TypeConverter Excel-Automation problem | Excel Programming | |||
Automation Code Problem from Access to Excel | Excel Programming | |||
Problem with quitting Excel opened through automation | Excel Programming |