I currently have a single .xlam addin deployed and version controlled, and have been asked to split this into several separate code bases to version controlled and deployed separately.
Can Addin 'A' reference a function in Addin 'B' , or would I replicate the function in each?
I was thinking about loading in the vba from .bas files dynamically at runtime - however this still duplicates code all over the place.
Related
I am developing an Excel Add-in to help harmonize calculations done by my coworkers. It is basically a collection of industry-specific UDFs bundled together in regular and class modules.
There are a number of functions that are highly specialized and are used in only specific applications. As such, these functions would be included as a module in the individual workbooks where they will be used.
I would like to be able to re-use several "helper" functions from the Add-in to simplify these "external" functions. As near as I can tell, UDFs are not available across VBAProjects. I've tried to add a reference to the Add-In, but while the Add-in is loaded, Excel complains that
"Name conflicts with existing module, project, or object library"
which makes sense. It's trying to add something with the same name.
Removing the add-in and only adding it as a reference seems to give the desired result (workbook-specific UDFs can call add-in UDFs and Subs), but it only appears to work for that specific workbook.
Is there a way to call UDFs across separate VBAProjects?
Additional trial-and-error testing has revealed the error to me: I was attempting to add a reference to the add-in to itself, which would presumably be recursive and cause issues.
Selecting a module in the specific workbook allowed me to add a reference to the add-in and successfully use the functions it contains.
Hail, everybody!
In short, my problem is, I wrote an Excel Addin which reference another Addin which, in turn, holds functions common to 4 addins/projects of mine. Each time I open Excel and it loads the addins (the 1 to 4 application installed Addins plus the referenced one holding the common functions), it gives the error message This workbook is currently referenced by another workbook and cannot be closed. But none of my applications is trying to close the common one (neither on loading nor anywhere else in the code)!
Describing in more detail.
I have four kinda-complex Excel applications I'd had developed for my job. Each one is a VBA project, distributed as Excel Addins (.xlam).
There are some functions common to all four projects (mostly data validation functions, GUI related functions, and external database query handling functions). Whenever I changed something in any of these functions, I had to re-write it in all four different applications and upload each one into Git.
Thus I got these common functions and put them aside in a fifth project, referenced the common project in the other ones (via Tools -> References). So now, all I have to do is to call them as any API outside referenced function (commonProject.Function (arg1, arg2, arg3 etc)).
So, the users will have the Addins for their applications (most use only one of the four) plus one "invisible" Addin holding the common functions.
The problem is, each time I open Excel and it loads the addins (the 1 to 4 application ones plus the referenced one holding the common functions), it gives the error message This workbook is currently referenced by another workbook and cannot be closed.
But none of my applications try to close the common one!
I saw other posts about this popup, but they were about some referenced Addin actually being closed by another. I also saw this guy (https://answers.microsoft.com/en-us/msoffice/forum/all/this-workbook-is-currently-referenced-by-another/5c4fbf67-76f2-4870-a1da-9f9e4e72499d) with the same problem as me, but his conclusion was that it's not doable: he imported the common function module into the referer Addin.
Is this true? I can't have an Addin reference another without this annoying popup each time Excel loads? Does anyone know another means to reference external functions which will not have this bumming collateral effect?
I have created an Excel document-level customization in Visual Studio 2017 using Windows 7. The document provides a set of tools for charting and analyzing data that are contained in several worksheets within the document.
I would like to provide the end user multiple versions of this document without publishing each one separately. Each version differs only in the data that will be contained. All the code, classes, subs, and functions would be identical for each version. I was hoping they could
rely on the same assembly.
I tested this by publishing a document (named DocumentA) on a test PC (Windows10) and then copying an additional file (named DocumentB). Trying to open DocumentB in Excel produces the following error:
Could not load assembly "DocumentA", Version 1.0.0.0. Culture =Neutral or one of its dependencies. The System could not find the file specified.
I think I understand why this happens. However, if I save the original published document DocumentA as DocumentB1, I can open the renamed file
with no problem. Not sure why this works and the other case does not. The property settings for assembly name and location were identical for DocumentA and DocumentB.
Is there any type of work-around? Or must I publish each of these additional documents separately?
Thanks!
I would like to provide the end user multiple versions of this document without publishing each one separately.
You need to create separate document level add-ins then. Or you may consider developing a single application-level add-in instead. See Walkthrough: Create your first VSTO Add-in for Excel for more information.
I have a SAP Business Objects Web 7.5 Add-in in Excel 2007.
The add in itself is made up of a compiled .xll file (CtExcelLinksWeb.xll) and a number of dll's.
A bit of vba shows the xll is registered, and all of its registered functions.
However, when I try to use one of these functions in VBA using Application.Run(), I get
Runtime 1004 - Macro may not be available or may be disabled.
I have tried registering the xll within the same sub (Application.RegisterXLL ()) and upon registering a VBAProject called CtEmpty.csv is created
I want to be able to automate the use of this add-in using VBA as it does long winded repetitive tasks, and then I can work on figuring out how to use the functions
Any help will be appreciated
Are the DLLs on the PATH? It may be that Excel can't load the DLLs that the XLL is dependent upon. Dependency Walker (depends.exe) is a handy tool for troubleshooting this kind of issue.
Also, have you tried using File/Options/Addins to register the XLL, as well as VBA code?
I have some VBA code that I use across multiple projects - about 40 or so different data bases all use many of the same functions.
I try to use the same code in application each for consistency. Is there a way I can put all the code in one library and make it available to each data base? I'm getting tired of copying the code to a new data base every time I want to re-use it. I'm especially getting tired of maintaining it in multiple places when I want to change the functions.
I have the same question for Excel - can I create an Excel library and include it in all my workbooks?
If the VBA code works in VB6, you could create a DLL using VB6. The DLL would be a library of methods you could use across board just by referencing the DLL.
If it does not, you should create an Ms Access MDA file (add-in file) for all your reusable code, that can be added into any Access (or probably Excel) project.
Create one or many excel's per project, save those as *.xla. (Excel Add-In)
Go to your Excel Options and configure to load automatically those add-ins or thru VBA in your workbooks.
Using VBA Automation:
Application.AddIns.Add(XLA_Path)