I have searched the internet and Stack Overflow, but couldn't find an answer to my problem.
I defined a UDF in Excel, it's saved in a module in an .xlam Add-In. The UDF works perfectly fine on my computer. Now I'm trying to use the workbook which uses the UDF on another computer (in a different language) with the same .xlam Add-In active. However Excel suddenly references the entire path to the add-in file as an "absolute path" instead of only showing the function name itself. The result is a #NAME? error because Excel doesn't find the UDF.
How I have written the VBA Code
How it should look
How it looks on another computer
Has anyone had this issue and found a solution for it? I could try to find a workaround without the UDF function but I'd prefer that it works this way. Another time the situation might be more complex ...
The problem with your UDF is the location of the .xlam file. You can find information on dealing with that by following the link in the comments above provided by Christofer Weber.
Having said that, I think it may be more beneficial for you to use the built-in formula that excel has for this which is EOMONTH()
EOMONTH() can be used to return both the last day of a month and the first day of a month (by finding the last day of the previous month and adding 1)
You can find more information on EOMONTH() here https://support.microsoft.com/en-us/office/eomonth-function-7314ffa1-2bc9-4005-9d66-f49db127d628
Related
I have Excel 2010. A couple of months ago I wrote some UDF's and got them debugged and working. Today I changed a value in the spreadsheet, and suddenly all the UDF's displayed #NAME?
Ultimately I decided to start from scratch. I created a new workbook with just one UDF. Here it is, in it's entirety:
Function say7() As Integer
say7 = 7
End Function
I then went to Sheet1 and in box A1 entered "=say7()". I got "#NAME?".
If I type "sa", the dropdown shows "say7". I can press tab or enter and it fills in the function name. And then it says #NAME?.
I understand that Excel 2010 is no longer supported. Did Microsoft do something to break UDFs?
My XLSM was working a few weeks ago. Indeed, the file where I made the change was a copy of the original spreadsheet. I went back to the original, changed a value in one cell that should have forced a recalculation, and it said #NAME?. I didn't change the code, I didn't change any settings, nothing. The only thing I changed was one data value and somehow that makes the function name not be recognized anymore.
Update: Several posters have pointed out that "say7" is not a legal name for a function in Excel and that using this name would produce a #REF? error. True. But my problem was that I was getting a #NAME? error, not a #REF? error. In my attempt to create a simplified scenario -- to make sure that the problem wasn't some error within the function -- I created a new, deliberately very simple function that got the same #NAME? error. Yes, I gave this function an illegal name, which muddles my question. I apologize for the confusion. Explaining why say7 is an invalid name is interesting and useful information, but sadly does not solve my original problem.
When you are writing the function then there are conventional rules of naming it. One of them says
You should not use any names that are identical to the functions, statements, and methods in Visual Basic because you may shadow the same keywords in the language.
The name Say7 while it looks innocuous enough, clashes with a column numbered 12895 which is named as SAY. So in principle, below works for me but I do not have Excel 2010 to see and confirm.
Public Function SaySeven() As Integer
SaySeven = 7
End Function
Edit:
After reading OP's own answer post and other details over, I can think of one more situation where we may encounter #NAME error. This can be reproduced fairly easily.
Step 1: Create a UDF and save the workbook. When you do so, it should not be saved at Excel's trusted locations and the file shall not be identified as trusted. If it is trusted then Excel doesn't prompt for enabling active content. At the point of creation, Excel will produce results without any error. Now close the workbook.
Step 2: Reopen this workbook. You will be prompted with below message.
Ignore this message i.e. do not press "Enable Content" button. OP may have missed this message somewhere.
Step 3: If the UDF was implemented in the previous session and it has returned a valid result then it will not return any error upon recalculation. However, if you enter this UDF in a new cell then Excel will return #NAME error. In below snapshot, both green cell and yellow cell contain exactly the same formula i.e.
=dist3()
But the outcome differs.
So in conclusion: UDF name dist3 is valid and it should work as cited by OP in his later postings. However, in above specific case, one may encounter error of this kind. It will, however, apply to all UDFs and not just dist3.
I have tested this in Excel's Office 365 version but I don't think there will be any major differences in this behavior across versions.
I eventually partly figured it out. At least enough to get it working.
Excel normally blocks you from running UDF's unless you explicitly give it permission. When you try to use the first UDF it pops up a question at the top of the window asking for permission, and if you don't give it, then UDFs aren't recognized and you get #NAME? errors for them.
Apparently -- and this is the part I'm not sure about -- the message telling me that support for Excel 2010 had expired was displayed on top of this message so I couldn't see it. Or something like that. I copied the file to another computer that had a newer version of Excel and I got the message. I clicked OK and the UDFs worked. I then saved it and copied it back to the original computer and it worked fine.
As I had previously clicked Ok on this and this answer is apparently saved with the file, I'm not sure why it asked again. Maybe some changes to the file invalidate the previous answer? I'm not sure.
I created a new file and saw the message about "UDFs ok?" on that one. So maybe my theory that the message was covered by the expiration notice is not correct. I guess it's possible that the message was there all along and I was just blind and didn't see it. That seems unlikely as I was searching for some explanation, but, etc.
In my first version of this post I said that the function name "say7" worked. This was incorrect. When I got the spreadsheet to work I had gone back to my original spreadsheet, where the function that was referenced in the spreadsheet was called "dist3", which works. (There were other functions but they wee all called from within dist3.)
In any case, before I created "say7" I was trying to get it to work with a function called "dist3" and that was also failing with the #NAME?. And as I said in the question, it worked a month ago and I didn't change any function names, so I knew that an illegal function name was not the issue. My attempt to create a simple function to test the problem was a wrong turn because I used an illegal function name that created different problems.
Seeing the logic of #shrivallbha redij's reply I changed the function's name to SAYG (with the idea that G defines the 7th column) and still got a #NAME error. However this can be avoided by passing an argument in the function call, even if the argument isn't used by the function or if it's blank.
=SAYG - returns an error
=SAYG(A1) - returns 7
=SAYG() - returns 7
I have one report which is all time updated and changed the file name. I want to know is it possible to make a formula (Except for Mecro code) to another worksheet without open this worksheet.
I am using indirect formula but it required to open worksheet.
Both of these sources indiciate that this cannot be done with a formula alone. However, they propose workaround solutions using vba code, as well as this stackoverflow answer
I strongly recommend to use PowerQuery. Though it uses M language, you can use it with GUI. If your version of Excel is prior than 2013, you must install the addon
I want to reference an external workbook that is open. If I type =path\[file] directly into the cell (even though I am still asked to 'Update Values',) I am able to get the data I require. However, I am using INDIRECT because the name of the file changes everyday (date). So, I am using CONCATENATE to create a filename daily and then using INDIRECT to the cell where the concatenated formulas is. If you paste values to see what is being generated formula, it is exactly the same formula as above, =path\[file]. However, I continue to only get #REF! error.
I read through this, https://support.office.com/en-us/article/control-when-external-references-links-are-updated-87861952-ca9d-4d2a-a986-4d672c908d0d, and I still can not figure it out. I had it working on my computer at home last night but today and work it is giving me trouble.
To clarify, the formula that I am trying to get to work looks like this =INDIRECT("'"&CONCATENATE($F$129,$F$130,F95)) which worked yesterday at home. Can someone lead me in the right direction?
EDIT:
I have tried two options, =INDIRECT(F121) and =INDIRECT("'"&F121). The contents of F121 have been =CONCATENATE("'",F191,F192,F157) and =CONCATENATE(F191,F192,F157), respectively. I have also tried =CONCATENATE("'",F191,F192,F157) in the destination cell. F191 = [Liquidity Risk Dashboard v2.03 -, F192 = =TEXT(E3,"yyyymmdd")&"]", and F157 = Calculations'!D122. If I write ='[BMI Liquidity Risk Dashboard v2.03 - 20170105]Calculations'!D122 am asked to update values but, 100% have both workbooks upon in same instance
If I understand what you really have in your cells, the problem is that you are not properly naming the source workbook.
Try changing
F192: =TEXT(E3,"yyyymmdd")&".xlsb]"
Replace .xlsb with whatever the file extension really is for your file. (eg: .xlsx, .xlsm, .xls)
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.
I am using a simple macro found in internet for Multiple Goal Sheek in Excel 2010. The link is here
The point is that the macro is working in the example test MultipleGoalSeek(KB19).xls.
given in that link.
But when I try to apply it in my excel sheet, it only solves the first Goal Sheek problem, leaving the others un-calculated. I have no idea why although the macro seems pretty easy (maybe because they are not integers?)
I attach my excel problem with the macro.
Thank you
Hmmm .... this is a very early piece of brettdj code, it dates back to my beginner days a decade or so ago. And it shows .... !
The issue is in the third last row of the code, contrary to the instructons in the file, it was designed to work over columns only (I was running a time-based inventory adjustment at the time)
Change
For i = 1 To TargetVal.Columns.Count
to
For i = 1 To TargetVal.Cells.Count
And it works fine on your sample
I will work on the orginal code to run with variant arrays.