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.
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?
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.
Is there a way of storing VBA source code that's common and accessible to all Microsoft Office products..? I have a variety of functions which I use in both Access and Excel, and sometimes even Word. I modify and add to the the functions and modules frequently. The copying, pasting, and maintaining of code between projects can get tedious, and I inevitably overlook something.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
If there was a way to store VBA code in independent files, and open them with the VBA IDE in a standalone mode of some sort, that would be outstanding, but I know the IDE doesn't work that way...as far as I know.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
Unfortunately that's your best bet.
As you know VBA code is hosted, wrapped-up in a host document: a VBA add-in is still tied to its host document (.xlam, etc.), and as such can't be shared with another host.
In VBA-land what's meant to be shared between VBA projects, is type libraries - things you compile separately from the VBA project, and reference from as many projects as you like.
If you have a VB6 IDE, you can compile a 32-bit DLL that VBA projects can reference. The problem is that it won't work with 64-bit hosts - the solution is a .NET type library, written in the .NET language of your choice, made COM-visible. Note that COM-compatibility does restrict what you can expose in your API: for example you can't expose generics, and method overloads will look weird.
If a type library isn't an avenue you wish to explore, then your choices are rather limited, and IMO sub-optimal.
IMO the only thing that can "work" is a bunch of exported code files in some common folder, and the VBA projects that need to use that code need to literally import these code files. The risk here being, that if you make any changes, other VBA projects using an unmodified version of that code will not "see" these changes, IOW by doing that you're multiplying the number of times you need to fix a bug by the number of projects using that code.
Or you could have some code that uses the VBIDE extensibility type library to ensure the set of imported modules always match exactly with the exported files in that common location.
If you want to use VBA in the same Office program (e.g. one Excel file to another, or one Access file to another), you don't need to use any special kind of file. You can add a reference to an external database or worksheet with macro's enabled.
Navigate Tools - References - Browse - Excel/Access file - Add the file
See the following screenshot:
You can't use files across different Office applications this way, but you shouldn't. Each application has different built-in functions, so your code is likely incompatible anyway.
I have code written in Outlook 2010 VBA that I want to share with co-workers (an Outlook rule runs that calls the code, which saves the current e-mail to a network folder as a text file). What I would like to do is save the VBA code in a library somewhere on the network, and have Outlook call it there. This way, others can call the same code and there is one set of code that all instances of Outlook can point to. If you can point me to info on setting this up I would appreciate it!
I do a similar thing in VBscript programs, using executeglobal to basically run a file containing the functions (acts like an include file) and am looking for how to do it in VBA.
Well it seems its not as easy as I was hoping. After perusing the links supplied by MP24 (Thanks MP24!), I learned the Outlook OTM file is not really intended to be shared. It errored for a colleague when I saved it to a network drive and she tried to use it via tools/references. To share code, one can export it as a .bas file, and another user can import it. This will add it to their own code if some exists already. The proper way seems to be to write an add-in, but that is beyond the scope of what I need for what I am doing. So, if a colleague wants to use my code I'll export and they can import it. The trouble is if I change something they will have to delete it and re-import. Oh well.