I created an Excel VSTO add-in, which users can install. However, after using the add-in, the next time Excel is started, the add-in is no longer loaded automatically.
The user can resolve this by enabling the add-in, but it happens every time, and I would like to stop that.
What happens is that in te registry, the key:
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\TiaGenerator\LoadBehavior is set to 2, which means inactive by default. I can change it back to 3 (load on startup), but after running Excel, it is changed back to 2.
Edit:
As #Cindy Meister said: Excel should change load behavior to 3 after startup, so there must be a problem. After some searching, it turned out the problem lies within the constructor of a self made class called ErrorWriter. The problem seems to be within this call:
Public Class Errorwriter
Inherits IO.StreamWriter
Sub New()
MyBase.New("C:\tmp\newLog.txt")
End Sub
End Class
Does anyone know why this causes Excel to change the load behavior?
Thanks to the comment of #Cindy Meister, I was able to dig a little bit deeper and here is what I found:
Apperantly, Excel changes the load behaviour of an Add-in if it encounters an unhandled exception during startup.
In the startup routine, I create a new instance of an 'ErrorWriter' object, which inherits from 'StreamWriter', and uses a reference to this file.
What happens is that Excel is loaded, an locks this file. Upon using some functions of this add-in, a second Excel instance is started in the background, which tries to use this file as well. This results in an unhandled exception, but because this second instance is not visible, this error is never shown to the user (nor the programmer).
Because the ErrorWriter is not needed in the second instance of Excel, it never becomes clear that the error occeured in any way.
This causes Excel to change its load behavior.
It is fixed by moving the offending code into a seperate function, which is only called upon invoking add-in functions.
I have thoroughly investigated the problem and found a solution. Changing the "LoadBehavior" is the right way of doing it, but you have to be careful about one thing. Both Outlook or Excel restore the previous settings for each add-in. BUT not at the start of the add-in but AFTER the add-in's start up.
In other words if you attempt to change the LoadBehavior in Windows Registry as part of the startup it will never work. You have to do it afterwards.
I hope this will help.
Thank you, VJ
Related
I have to call the below line to save my workbook from another file:
Application.ActiveWorkbook.Save
For the needs of my project, this code needs to be and run in a different file than the one I have open and active.
When this code runs from another workbook, the file that I have it open and actived calls the SaveAsUI to save the file again, even if he was already saved.
Afther run of the code above, the original workbook is losted. I cannot save anymor the active workbook, manually or by macros, and I don't want to save as my original file. Several errors occur, such as:
random filename in the SaveAsUI
Unespected Error, AutoRecover Disabled
Share Rule Violation (PT/BR)
Sorry, I cannot catch this erro in english. Here its translation:
"Your changes could not be saved in 'File' due to a sharing violation. Try saving to another file."
I noticed that this error started after I enabled auto-save for the first time*. I don't know if it is something related to the cloud and Excel gets lost when saving. Also, testing saving the original file outside the network the problem did not appear
I haven't found anything like it on the internet and it has never happened before either.
PS: The workbook with I have enabled AutoSave has nothing to do with those that are giving error. That was a workbook without macros for a much simpler project.
I was able to find what was causing the problem. I initially thought it was the VBA macro part and the "ActiveWorkbook.save" command, but in the end the problem was much deeper.
It turns out that in the same macro that contained the save command there was a call to another function that updated the queries.
the error would stop when going into PowerQuery Editor, going into the spreadsheet query that would later give the share violation error, and in the steps remove the action of promoting the headers.
I have no idea why this is the error. But I tried several other ways in several other places (like every tip in this link1, or this link2, or this link3), the only way that resulted in the solution was this above (that I don't find in any place).
But the promotion of the headers is necessary, so to continue without giving problems I needed to go into the advanced editor and change the second parameter of the line below from "null" to "true" (which is basically to promote headers at the query stage).
let
Source = Excel.Workbook(File.Contents(FilePath), true, true),
With this, everthing now is working fine.
In this link, it says that
During development and testing, you can manually clear your computer's cache of registration metadata by deleting the folder <user>\AppData\Local\Microsoft\Office\16.0\Wef\CustomFunctions.
I then make a test as follows:
I load a manifest.xml pointing to the original customfunctions.js in my server in a workbook. After closing the workbook, a file is automatically saved in ...\Wef\CustomFunctions\V1.
I modify manually customfunctions.js in my server by replacing Excel.Script.CustomFunctions["CONTOSO"]["ADD42"] by Excel.Script.CustomFunctions["CONTOSO"]["ADD42NEW"].
I open a new workbook, in a cell, after enter =contoso., the IntelliSense shows me contoso.add42 rather than add42new. After entering =contoso.add42(5;4), the cells shows #GETTING_DATA and does not return a value. That's understandable because it works on a function which does not exist anymore.
If we click on another cell and enter e.g., =2+3, we see the workbook is refreshed, and #GETTING_DATA becomes #NAME?. And now IntelliSense shows contoso.add42new rather than contoso.add42.
To conclude, I think there may be a bug: when we open a workbook, IntelliSense should give the updated list of custom functions defined in the current customfunctions.js.
Actually, what is ideal is that the custom functions in workbook always keep aligned with what are defined in customfunctions.js. If there was not this bug, today we still needed to close a workbook and reopen one to get updated. Does anyone know if there is a workaround to make custom functions in an opened workbook keep updated on the fly? Is there a refreshing trigger that allows us to make custom functions in an opened workbook update from the current customfunctions.js?
Thanks for the question! As you've discovered, custom function definitions are currently updated only on-demand rather than on every single document-open event.
We've received a bunch of feedback in this area and so we're considering some changes to how registration works so that the list of functions in IntelliSense/autocomplete gets updated at the beginning of a session instead of in the middle of one.
I don't have details to share right now, but be on the lookout for some changes here in a few months.
Working with PowerBuilder, I'm using an OLE object to make some changes in an Excel document, but when I disconnect the object, the Task Manager shown that it's still running. Also, if I open another Excel document, I can then open the Excel document that I made changes in.
I've tried just about everything I have seen on here, but most are using C# or something other than PB. The code that I've see and tried, doesn't run in PB.
Any ideas?
ole_excel = create oleobject
ole_excel.ConnectToNewObject("excel.application")
ole_excel.application.quit()
ole_excel.DisconnectObject()
In Task manager, I see the following:
EXCEL.EXE *32
Thanks,
Queue
Sometimes the process remained for whatever reason, I code a
Garbagecollect()
and the process vanishes.
Take care.
Georg
The issue:
Similar to this issue but unable to find a solution I am trying to figure out how to fix this bug:
Viewing an object in Locals or Watch window causes excel to crash
The custom class is as wrapper for ADO execution allowing us to use a separate class to maintain our SQL code and execute it within the wrapper to keep error handling for MS Access ADO execution in one neat place.
This has been great for logging and debugging purposes until a few days ago I noticed trying to expand the node for the custom class in the Locals or Watch windows in the VBA editor cause Excel to silent crash after a 5 second hang and restart with the file recovery window.
Unfortunately the code is company sensitive so I may not be able to paste any in but if there are any ideas as to what might cause it I may be able to find the source and report back.
Has anyone else experienced this issue?
Update: New symptom - During debugging and comparing the text between an older build and the new one I found that the Locals window goes empty (clears of all objects) just after the hang stops and before the crash occurs.
Fixes I have tried:
Rebuilding VBA project and fixing all known compile errors (to eliminate simple vba errors)
Exporting all classes and modules - reimporting into new workbook (to eliminate the workbook file being corrupt)
Copying class and module text into notepad and clearing all formatting - pasting into new workbook (in an attempt to remove corrupt class data)
Disabling any reference to other custom classes to narrow down to a single class.
I appreciate your help and hope my issue can shed some light on it for others.
You can try below things. I hope any one of them work for you. If it still it does not works i request you to
simulate the similar issue for demo and share the code.
Possible issues with add-ins. Try to remove your addins (uninstall
the com addins) and run the code and check if you are still having
the issue.Disabling add-ins is a good test because it let you narrow
the choice of which add-in is causing the crash.
Check whether your antivirus software is up to date or is conflicting
with Excel. If your antivirus software is not up to date, Excel may
not function correctly.
Kindly run the macro on single instance of excel and check if you are
still having the issue. By single instance i mean when you go to task
manager processes tab where only one image name with excel.exe should
appear.
Verify/install the latest window updates
Try to run the same macro on other pc or other version of excel
Use mztools andin and review your code
This is a very common problem when Excel Worksheet or Chart is embedded into Word or Powerpoint. I am seeing this problem in both Word and Powerpoint and the reason it seems is the COM addin attached to Excel. The COM addin is written in C# (.NET). See the attached images for error dialogs.
I debugged the addin and found a very strange behavior. The OnConnection(...), OnDisConnection(...) etc methods in the COM addin works fine until I add an event handler to the code. i.e. handle the Worksheet_SheetChange, SelectionChange or any similar event available in Excel. As soon as I add even a single event handler (though my code has several), Word and Powerpoint start complaining and do not Activate the embedded object.
On some of the posts on the internet, people have been asked to remove the anti-virus addins for office (none in my case) so this makes me believe that the problem is somewhat related to COM addins which are loaded when the host app activates the object.
Does anyone have any idea of whats happening here?
UPDATED 21-JUNE-2010
Found out that both Events and changes to ComAddIns collection creates problems when the embedded object is activated. I have now used the Excel::Application::UserControl property to check whether Excel is in embedded state and then skip any OnConnection(...) and OnDisconnection(...) code.
One solution to Events problem can be to move all the application level events to VBA code and call into .NET. Thereby removing all event handlers from .NET code.
There may be even more scenarios where an embedded object might fail to initialize so I choose to disable the COM addin i.e. skip the code in OnConnection(...) and OnDisconnection(...) methods altogether.
Here is what I did to get rid of this annoying problem:
Remove all event handlers in the .NET code and rely on the VBA Application Events i.e. Instead of handling Excel::Application::Worksheet_Activate(...) event, handle them in a VBA module and call into the addin when an event is received.
The .NET event handlers seems to corrupt the state somehow.
Disable any code that interacts with the addin in OnConnection(...) using the flag in custom param. See the following link for details on the flag:
COM AddIns in Detail
I mentioned about the Excel::Application::UserControl property but it is not reliable in some cases. We need to consider the following cases and the custom array param is OnConnection(...) is the most reliable:
Excel started as independent application
Excel started as embedded app in some other application
Excel started through automation e.g. CreateObject(...)
I preferred disabling the addin totally when Excel is in embedded mode. It depends what code you are executing in your OnConnection(...) and how other applications respond to it when executed. Point #1 has to be implemented to solve this issue.
If anybody has a better solution to this, please let me know :)