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?
Related
Recently, I tried to access to some subroutines and functions in an Excel file (in .xlsm format) that have been developed in the past.
Initially, I found that those subroutines and functions are not present under the module folder.
Instead, I tried to retrieve those subroutines and functions with object browser under "VBAProject".
However, I found that I am unable to view the codes of those subroutines and functions by double clicking those subroutines and functions.
May I ask if there are solutions to the access of the codes?
Thank you.
The situation in normal condition:
More details on 4 July 2022:
What I can see in the project explorer is a module (double clicking the module shows no codes.), while in the object browser, the Class is the module mentioned and the Library is called "VBAProject". I know there are some methods of hiding codes but I did not experience such situation in the past.
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.
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.
So I'm not sure if this question requires knowledge on the UiPath software in order to be answered or not. I have been developing a lot of Excel macros for my company, and as I get more and more macros, it's harder to manage them.
We have been working on some robots as well within the company, and I notice that the robot has an activity where you can invoke VBA code within an Excel application scope. This activity reads a .vb file with code and invokes whatever method you specify within that file as a macro in the activated Excel application.
Ideally I would want to extract all my VBA code into separate files, and have the robots execute the macros through this activity. This would make it a lot easier to manage the code.
My question is then, if it is somehow possible for me to also extract the modules I've created that contain utility methods that I repeat throughout many macros into a .vb file, and reference this in the other macro files?
I don't know exactly how this activity invokes the code and what restrictions are placed on it. Within Excel, I can store re-usable methods in modules and call on them from other modules. This is what I want replicated on a file level. If there was some way of adding import statements to the top of the code to retrieve methods from other modules, so I could call them within the file.
My worries (and assumption) is that the activity simply reads it as a text file, and just imports it as a macro right into Excel. That if I wanted to reference any modules within my method, the modules would have to already exist in the Excel application.
I could always paste the utility methods into every .vb file, but that sort of defeats the purpose of making it easier to manage.
Is there anything I can do here?
Thanks,
TRS
You definitely can reference external assemblies (.dlls) in UiPath. I haven't done it with VB.Net Projects, but I have done it with C# Projects which is in this case, the same thing.
Please, follow this tutorial: https://www.uipath.com/kb-articles/how-to-include-external-dll
To be able to generate the .dll, you will need to download Visual Studio Community Edition and follow a couple of tutorials on how to compile VB code.
All your VB code will exist in this .dll. This would be your general repository or main library that you would access every time that you need it. As I understand, this is your main goal anyway right? "To access utility methods".
I don't know if inside your macros, you use specific Excel references that could lead to compilation issues. So, be ready to reference everything that you need inside the code.
At the end, to access your custom methods, you would need to reference the .dll and use the activity called: Invoke Method.
I hope this helps.
I have an Excel 2010 macro application that is made up of several workbook files.
FileName (ProjectName)
VFApp.xlsm (VFAppVBA)
VFReportClasses.xlsm (VFReportVBA)
VFImportClasses.xlsm (VFImportVBA)
VFDataClasses.xlsm (VFDataVBA)
ZShared.xlsm (ZSharedVBA)
Shared is referenced by all the other workbooks.
Data is referenced by App, Report, & Import.
Report and Import are both referenced by App.
I'm trying to close all the referenced files when the App file is closed. This works for everything except ZShared.xlsm. For it I get the 'This workbook is currently referenced by another workbook and cannot be closed.' error.
The only semi-helpful info I found online was http://support.microsoft.com/kb/211856
and http://support.microsoft.com/default.aspx?scid=kb;en-us;159794. I added some logging to all the classes in ZShared. All instances of it's classes are getting correctly terminated and I don't have any workbook objects pointing to ZShared.
I even tried renaming the files like (http://www.allquests.com/question/3996335/Upgrading-Add-ins-from-XL2003-to-XL2007.html).
The weird thing is, if I manually open VFDataClasses.xlsm before opening VFApp.xlsm, then ZShared will close out correctly without error. If I just open VFApp.xlsm and let it open all the other referenced files, I get the above error.
Anybody have any suggestions for figuring out why Excel thinks the workbook is still referenced?
Clairification:
Each workbook references the others via Tools -> References.
ZShared consists of public classes and modules with public subs, functions, and constants as well as 3 global variables.
I'm not, that I know of, doing anything to reference ZShared's workbooks or other Excel objects.
The global variables are in ZShared so I don't have to recreate them in each App that references ZShared. They are handled via public InitializeGlobalClasses and TerminateGlobalClasses
I added an m_InstanceId to every class and debug logging to all Class_Initialize and Class_Terminate so I am 100% certain that all instances of the classes are being terminated correctly.
I wonder if it is possible Excel is creating some hidden reference to the workbook based on using a With statement or some such that isn't being cleared correctly. On the other hand, it makes no sense that this would only happen if ZShared was not already open when the App started.
I never found an answer to why Excel thinks the file is still referenced. As a work-around I ended up doing 2 things.
Hid the ZShared workbook in Excel so normal users can't see it.
Set ZShared to Read Only so I can replace the file with an updated version even if people still have it open.
If anyone knows of a way to peer into Excel's internals to see why its reference garbage collection is not working, I'd love to know.