Excel VBA UDF Add-in function #Name error - excel

I have a UDF I wrote and put in an add-in. I put it there (with a library of others) so that I can change functions and just deploy an updated add-in, thereby eliminating the need to modify hundreds of workbooks which invoke the subs/functions should I need to change them. This is all being done in Office 2007.
It had worked well until recently when users started moving to Windows 7. Now, only on Windows 7 (XP is still okay) there are #Name errors in cells. This occurs under specific conditions (only a problem for Scenario D below). In short, I have two workbooks each invoking, let’s call it, “FunctionX”, so let’s say cell A1 of each has “=FunctionX(parmA, parmB)”:
Scenairo A – If I open either workbook separately (All is well)
Scenario B—I open both workbooks at the same time (All is well)
Scenario C—I open both workbooks separately, one after the other, in different instances (All is well)
Scenario D—I open one workbook, then the second, in the same instance of excel (#Name errors in cells of first workbook invoking FunctionX)
I realize the work-around is to only operate via Scenarios A-C, however I keep getting users complaining about D. If they go into any invocation of FunctionX on the #Name offending cells and hit enter, the #Names go away, but a programmatic forced recalculate does not do this (my initial attempt at a band-aid). Is my only recourse to write a procedure that loops through all open workbooks, goes into a cell with my function forcing a code-driven enactment of what the user is doing, or am I missing something?
Thanks…any/all advice appreciated.

Related

Renaming worksheet gives 'Out of Memory'; CurrentRegion property fails

My employer has recently upgraded from
Excel 2013 (15.0.4805.1001)
MSO (15.0.4919.1002) 32-bit to Excel for Office 365 MSO (16.0.11328.20362) 32-bit
There are no active add-ins (other than referred to below when loaded).
An Excel add-in (xlam) that I have created no longer functions correctly.
The add-in works with an open workbook and formats a lot of 'raw' data as tables (listobjects) and creates a number of PivotTables and Charts in a dashboard-style layout. During the process some blank sheets are copied from the add-in to the open workbook, and renamed as required.
For the most part, everything works fine (pivots created, dashboard created). At the end of the process I create an index sheet by copying a blank sheet from the add-in, and re-naming it (as ...Index). This is where things go wrong. Excel just seemed to 'hang'. On investigation I discovered that the sheet was not being renamed (so further processing stopped).
Delving into this further with error-trapping turned off, if I try to rename the sheet using the immediate window, I get
run-time error 7 Out of Memory
Further, if I manually rename the sheet (Excel interface) and then set the code running from that point, I've discovered that I can't use the CurrentRegion property (some sorting is done on the newly inserted sheet). Any attempt to use CurrentRegion results in
Unable to get the CurrentRegion property of the Range Class
This also applies to using the immediate window on ANY open workbook (e.g. ?Activesheet.range("A1").CurrentRegion.Rows.Count)
These errors persist during the current session of Excel (that is, I can create a blank workbook and try to rename a sheet using VBA but get an error; manually renaming a tab is OK). If I restart Excel everything is fine.
I require to use some global/public variables but (given that everything worked in Excel 2013) can't see that these would be the problem.
Any ideas?
After a further couple of hours looking into this, I established that the error was related in some way to a module which added slicers to the dashboard. The slicers were, in fact added (and stepping through the code no errors were generated).
Adding the slicers in a slightly different fashion appears to have got around the problem, although I am still none the wiser as to why it actually occurred in the first place (the original code for the slicers worked fine in Excel 2013).

Dynamic Workbook Name changes and cell references - Is it possible?

my question is a pre-code question, as I would like to verify if and which is the best option to go about this - either formula, VBA or not possible.
I have a main workbook with an array of codes inside cells in sheet 1 - all in the format HXXX-XXX-XXX where X is numbers ranging from 0-9. Each code has an associated revision number as shown in the attached picture.
The workbook itself is named in the format: 'HXXX-XXX-XXX-YY Example Title' where YY can be any number starting from 0 to infinity (in theory). Only YY is subject to updates in the title. If changes are made in this workbook, then a new version is saved, with the YY changing in the title to the next consecutive number - Nothing else changes.
From this main workbook there are a large number of other workbooks (around 50) which share the same codes and revisions. My goal is to link all these workbooks up so that I only have to update a core main workbook and the rest of the codes (HXXX-XXX-XXX) revisions in all the other linked workbooks update accordingly.
The problem is that the other linked workbooks have a dynamic name in the format: 'HXXX-XXX-XXX-YY Example Title 2' where YY can be any number starting from 0 to infinity. YY gets updated to the next consecutive number if a change is made inside the document and this document is then saved as a separate document using Save As. NOTE: not all workbooks will get updated at the same time, as it all depends on which codes and therefore revisions are changing.
My question is firstly, is this possible with current excel functions to update links with ever-changing workbook links, which are saved as different files each time in the same folder?
Secondly, I have read about the INDIRECT function, but it is limited only to having the required workbooks opened at the same time as the updates to the main workbook, hence I am unsure that Formulas will work (I will be linking 50 workbooks to the main workbook) - From this I am gauging that VBA may be the best option, but I would like to double check this is possible before I begin attempting the code.
Of course the use of Formulas in the sheets would be much better, but because the file names are dynamic, and since the updated workbooks are saved as different files each time changes are made to it, I don't believe this is possible.
If I understand your problem correctly you need to differentiate between 3 things.
Using only Excel Formulas.
The problem with this is that formulas crossing workbooks have the big disadvantage, that you need to have the source-workbook open, otherwise manny formulas will not work correctly or update. You also have the disadvantage that saving the file needs still to be done automatically. The advantage is that you do not need VBA macros.
Using Power Query
With Power Query youmight be able to solve the problems with the dynamic names.You can even read a whole folder of files, combine them and do transformations without the need to open the files manually. But you still need to save new files manually and the files will only update once they are opened.
Using VBA
You can prettymuch do everything you asked in your problem description but VBA has its own disadvantages. Firstly the file-format ".xlsm" is not allowed by the IT department everywhere. Also to work, every user using the files needs to activate macros, otherwise the macros won't get executed. Therefore I think a VBA solution is better fitted if you only have a small circle of users or if you can execute the macros on your own (e.g. if the main workbook was updated, you need to execute a macro which opens, modifies and saves all affected files). After that you colleagues do not need VBA themself.
Possible solution:
To avoid VBA you could try to create a Power Query in each "other workbook". The query will read all filenames in the folder where the main workbook is located. Now you sort and filter for the workbook with the newest/highest ID/Titel automatically and load the result as an seperate Excel sheet (all that is possible with power query and without VBA).
Now you can use the "indirect" formula to use the ID/Titel to link to the newest main workbook. As mentioned above this will require that the main workbook is opened. Otherwise the indirect formula will not update the values. If that is out of the question, you probably need to go with VBA.

VBA and Excel running in parallel

This is a question that I have always had but never really gave it much though.
What I have at the moment is a worksheet that displays data, and the user refreshes whenever needed. So:
User triggers a VBA Function
VBA Function gathers data and analyses WHILE USER WAITS
VBA Function dumps the result on the spreadsheet
User continues viewing data
Since the data analysis is all done internally in VBA (No use of workbook, only recordsets, arrays, library etc.) I wanted to somehow be able to allow the user to continue viewing the original data, while VBA works on getting and analyzing new data.
I know you cant use the workbook AND run VBA at the same time, but you can however, have two excel instances and work on one workbook while the other runs VBA.
So could I somehow have my original excel instance call another excel instance and have it run the VBA while I work on my first instance?
Any Ideas?
(Also, not sure if the tag "Multithreading" is technically correct)
First thing - there is no multithreading for VBA in Excel.
Second thing - since Excel 2007, Excel supports multithreaded recalculation of formulas.
Therefore to approach multithreading calculations in Excel you can do at least 2 things:
Create a second instance of Excel (new Application instance! Not a new workbook within the same Application!) and execute the macro remotely.
Create UDF functions (User Defined Functions) in VBA. Unfortunately you cannot edit other cells using UDF but you can save the results of your computations in a Global variable and then print the results.
My recommendation - go with option 2.
I haven't been able to try this, but it seems like you can launch Excel from VBA using Application.FollowHyperLink. The hyperlink would have to be the local path to the sheet. You might have to use VBA to also make a copy of the sheet first.
Have you thought through the concurrency issues with having two copies?

How to keep reference to add-in UDF when workbook moved to different folder than add-in?

I wrote an Excel add-in that provides UDFs (user-defined worksheet functions).
All is well until one user sends his workbook using those functions to another user, or just tries to use the workbook on more than one computer, where the add-in has been installed to different paths.
Even if the only difference in the paths is the drive letter, when the workbook is opened on the other computer, the old full path appears on the formulas in front of all the UDFs, and the formulas return an error.
One way of dealing with that is doing a search & replace of all formulas in the workbook, replacing the path with an empty string. Then the formulas reset themselves for the add-in's path on the current computer. Sometimes I then have to go into the VBE and run a CalculateFullRebuild to get the formulas to work. Though it works, it's a lot to ask of the less technical users, and it's annoying to have to do it frequently for those users who move their workbooks around a lot.
Also -- do COM add-ins have this problem? My add-in is an xla. Though I'm curious about that, it's a moot point in this case since COM add-ins don't work on Macintosh Excel and I need this add-in to work cross-platform.
UPDATE:
As requested, here's a screenshot:
This screenshot shows what happens if Fred, who put the add-in in C:\Fred's Stuff\Fred's Excel Stuff\MyAddin.xla, sends his workbook to Martha, who put the same add-in in another path, such as C:\Martha's Files\Martha's Excel Files\MyAddin.xla, and Martha opens the file Fred sent.
If Martha deletes the path, leaving only "=MyUDF()" in the formula, Excel will find MyAddin.xla on Martha's computer in the path where Martha put it (assuming she had previously installed MyAddin.xla as an add-in in Excel), and resolve the formula correctly.
This is one of the many bugbears Excel developers need to face at one time or another, and there are a few work-arounds for it, but which one you choose will depend on your own circumstances:
http://www.jkp-ads.com/articles/FixLinks2UDF00.asp
In case the link dies, here is a summary of the three suggested methods:
Use fixed locations.
Instead of keeping your UDF code inside the addin, you create a facility that copies the UDF routine into each workbook that uses it.
Redirect the UDFs to the new location.

Excel VBA macro not found by worksheet, #NAME

I'm trying to get a simple VBA function to run in an excel (.xlsm) worksheet.
I created this function:
Function abc()
abc = 2
End Function
in Module2, and it worked.
But after I copied the spreadsheet to another system, it now just shows "#name" as if it can't find it. The function shows up on the available list of functions however.
This makes me think there is some kind of setting I need to enable, but I've enabled whatever I was prompted for. Any ideas?
I should've known it was in the trust center:
http://office.microsoft.com/en-us/excel-help/change-macro-security-settings-in-excel-HP010096919.aspx
Basically, hit the ball and poke around until you find "trust" and "enable macros" and select the least secure options.
And then close and re-open the spreadsheet.
I think we may need more information. What version of Excel are you using? Is it different from the destination system version?
You'll want to make sure that Module2 was in the Workbook you copied into the other system. Excel 2007 stores macros on a personal workbook by default sometimes so you'll need to check the the code is actually inside of the .xlsm file.
If you're still stuck and need a quick fix just copy the code text into the new system's Excel workbook directly without making a .xlsm file (create new module in the other system then paste).
If you would like to learn how to put together add-ins you can get started here or here.

Resources