Excel custom Add-In not loading when instance of Excel is opened by another application - vba

I have created a custom add-in for Excel and for the most this work fine without any issues.
However, we have a 3rd party application where we can select the option to "Open In Excel". This then loads a new instance of Microsoft Excel with a load of data populated from the application, but does not load the custom add-in.
If I go in to the add-ins option, I can see that Excel still seems to think that the add-in is enabled but I can see that it is not because the macros are not imported to workbook.
I can disable and then re-enable the add-in and it will work just fine. I can also open an Excel document or a new instance manually and it will work as expected. It only ever seems to be an issue when the instance of Excel is opened from this 3rd party application.
I assume that this is because the add-in is bound to my account and the process is being started by another account even though task manager sees it as being a process ran by myself.
If anyone has any ideas as to why this is happening or how to resolve it, I would be very grateful to hear.

Related

Resume Opening Workbook After Addin Interrupts

I've written an Excel addin that periodically checks a remote repository for data updates, including a check when the addin loads at Excel start up (during the addin's Workbook_Open event). If new respository data is detected, the addin asks the user for permission to proceed with the update. If the user clicks "yes", the addin successfully updates itself and everything is happy... except...
If Excel is not already running and the user selects an Excel file to open (e.g. via double-click in Windows), this sequence of events occurs and everything works, but the user-requested file opening is interrupted and not re-engaged. The Excel app is running, but with no workbook loaded (the workbook area is an empty frame).
I believe I have two options, neither of which I know how to accomplish:
Prevent the addin from completing its update check until the user-selected file has completed its open sequence and is fully loaded, or
Allow the addin to update itself and then somehow re-engage the user-selected file to complete the file open/load.
I have not been able to discover the filename/path of the user-requested file, so my addin isn't able to direct that file to be loaded.
My current workaround is a MsgBox telling the user to close Excel and re-open the selected file. Ideally, the addin update should occur and the original action should complete without requiring user intervention.
(Building on Option 1, I could start a delay timer for the addin to check for updates XX number of seconds after Excel starts, but this seems kludgy to me.)
Any guidance or ideas are appreciated. My interwebz searches aren't hitting the right combination of keywords for the exact scenario.
Instead of opening the new addin update file immediately you can use OnTime to delay it which should allow the other file to open successfully. See here: Process for updating Excel add-in?
In the answer you'll also see a reference to this package here which does everything you need. Autoupdates are hard so I would recommend going with someone else's solution.
http://www.decisionmodels.com/downloads.htm#addload
(Scroll down to Add-In Loader Version 2)

How to set Focus and Modal way on a Winform/WPF Application hosted in VSTO Excel 2003 Add-in?

I have 2 questions :
1) In my VSTO Add-in, I created a button. When clicked, it starts a STA thread, launching a WPF Window (which is in fact my real application).
The application is treating Excel Data, sending them to Web services, etc etc.
At a particularly moment, I call :
System.Diagnostics.Process.Start(filePath);
the path is like "C:\file.xls". Indeed, it opens an Excel file.
The problem is that the focus is beeing made on this file instead of remaining the focus on my WPF window.
I tried to set the focus to the Current process, but since the new file opened and my WPF Window are hosted in the same Excel process, it didn't solve the problem at all...
Any idea ?
2) As you can see, as my WPF application is launched in a thread, even using a modal dialog, I can still modify the excel file in background... which is not what I want at all...
How to fix this, blocking the excel file in background ? Is it possible to do this using the Workbook COM object that I can control ?
Ok I solved my problem not using a thread.
I launch my application directly in the VSTA_Main thread (the Add-in thread), causing a freeze on my button...
Since it's not another thread, my entire process in blocking.
For the second question, I launched another Excel process like that :
ProcessStartInfo info = new ProcessStartInfo("Excel.exe",filePath);
Process.Start(info);
I still have a little bug with the generation of the Excel file, but still solved my principal problem.

Excel addin deployment problem

I have created Excel addin.
Addin will never check for updates, User will update the addin.
Excel is launched from the c# application, after launching Excel uses addin to perform actions.
The problem is sometimes though Excel has updated version of the addin still it shows the "Updating Office customization" dialog box and will create the directory in AppData\Local\Apps\2.0 folder.
Why Excel is updating the customization though its having latest version of the addin.
i assume you are using VSTO, from which .NET version?
check the publish section of the project properties... on the "Updates" button, you should see the 3 options for an excel addin to update itself.
if you select the check whenever the addin is being executed. the Excel will check for an updated version every time.
now you haven't say if excel will actuall update the add in version or not. but please check the above first

XLAM / XLA Addins: is there a better way?

This post is about installing XLAM's without creating links. (Everyone hates links). Consider the trivial addin:
Public Function UDF_HELLO(x)
UDF_HELLO = "Hello " & x
End Function
Put this code and nothing else into a Module and save as "Hello.xlam" on the Desktop (and NOT in the default excel addins folder). Next, while HELLO.XLAM is still open, create a new XLSX workbook with the formula
=UDF_Hello("world")
in cell A1, which simply displays "Hello world" in that cell. Save the workbook and exit Excel. Now, if you reopen the workbook without the XLAM, Excel will complain about "links to other sources ...". Whether you click "Update" or "Don't Update", Excel will mangle the formula in cell A1 like this:
='C:\Documents and Settings\tpascale\Desktop\Hello.xlam'!UDF_Hello("world")
Very often this "forced-linkage" is NOT desirable. In my computing environment there is a lot of ad-hoc analysis and it makes no sense to impose an install regimen on every XLAM we throw together to solve the problem of the day. I just want to hand out XLAM files to users and let those users open them when they need them, WITHOUT having to worry about the slightest mis-step causing their formulas to get mangled.
QUESTION:
Is there a way to instruct Excel to NEVER construct external links for UDFs, and simply to use UDFs if they're loaded and return #VALUEs otherwise ?
I don't know of a way around this with .xla/.xlam add-ins.
But this issue does not occur with .xll add-ins.
These can be created in C using the Excel 2010 SDK, or in managed languages like VB.NET or C# using the free Excel-DNA library.
(Disclaimer: I'm the developer of Excel-DNA. This issue is one of the reasons I went with the .xll interface for making managed UDF add-ins.)
You can have them open the .xla file and have an Auto_Open procedure install the add-in.
http://www.vbaexpress.com/kb/getarticle.php?kb_id=693
After excel closes you can have the add-in uninstall itself.
oAddIn.Installed = False
You can give your add-in a setting for the user to not uninstall after every use by using a worksheet named something then have cell A1 equal to true or false.
I haven't tested this but hopefully it works for you.
This should work to resolve your issue though it does not instruct Excel regarding external links. I have tested it myself by creating the XLAM, saving it to my desktop, installing it in the Excel add-ins and then using it on a new workbook.
Steps:
Once you have saved the add-in, close it.
Go to Excel Options-->Add-Ins
In the Manage drop-down select Excel Add-ins and press 'Go'
In the 'Add-Ins'dialogue that appears click 'Browse' and navigate to
the add-in you just created. Select it and hit 'Ok'
If prompted to save the add-in in the add-ins folder, select 'No'.
Selecting 'Yes' may cause an error if the add-in file suffix does
not match the version of Excel being used.
Your add-in should appear in the 'Add-Ins available' scrollbox,
check its box and hit 'Ok'
Your add-in should now be active whenever you open Excel.
Test this by opening a new workbook and try using your UDF.
Best,
I usually solve this problem by:
Saving an XLA/XLAM file (outside Personal folder, of course)
Connect to it in Tools - Addins
Write pseudo macros in your current Excel file that links to those macros / functions in the XLA/XLAM file.
See the detailed instructions in my reply here.

Deploy Outlook UserForm

I made a userform to give out to colleagues.
The installation procedure goes approximately like this:
allow unsigned macros
open VB Editor
add 2 references by manually navigating to the .ocx / .tlb files (needed for Treeview control)
import form
create a new module
copy a procedure into that module (hook for button, contains essentially MyForm.Show)
run another proc to create toolbar button
save, restart
My plan was to make an install script; but I found Outlook's VBProject is sealed tight against any automated access.
How can I make that installation procedure simpler?
As microsoft wrote here:
https://support.microsoft.com/en-us/help/290779/managing-and-distributing-outlook-visual-basic-for-vba
If you are developing a solution that you intend to distribute to more than a few people, you should convert your VBA code into an Outlook COM or VSTO add-in or an Office add-in for Outlook.
Outlook macros are not made to be deployed so you will always have troubles deploying them to users as they will need to make too much actions as you described.
To avoid that, I recommend you to look at VSTO add-ins and ClickOnce. Here are the links:
VSTO
https://learn.microsoft.com/en-us/visualstudio/vsto/getting-started-programming-vsto-add-ins?view=vs-2019
ClickOnce deployment
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-clickonce?view=vs-2019