-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xll functions are not recognized by excel #10
Comments
yeah I noticed the same thing... ugh the woes of trying to compile 64 bit stuff.... |
okay is this still an issue for you? |
To fix this for x64, first remove the two #ifdef _WIN64 portions from xlcall.cpp and the corresponding #endifs. |
While the above fix works for x64, it doesn't work for Arm64EC, which is the platform required for excel addins in Windows on Arm. The following implementation of Excel12f seems to work everywhere: template<typename... E> |
I git-cloned the CompFinance repo, built the solution with visual studio 2022 without any issue -- I just had to upgrade the windows SDK etc. (I built in debug x64 and my office 365 excel is x64 as well.)
Then I added the XLL to a blank excel file, in which I opened the test spreadsheet xlTest.xlsx.
Then, I see "#NAME?" in any cell using a function of the XLL in a formula.
These functions do not seem to be recognized by excel. (The same problem happens when building the debug xll in x86.)
I then put a breakpoint L1261 in the xlLExport.cpp file (the "entry point" of the XLL) and attached visual studio to a blank excel spreadsheet process, spreadsheet to which I added the debug x64 XLL. It indeed broke at the breakpoint I put.
The L1263 call to Excel12f worked like a charm. The L1265 call to Excel12f led to a #ifdef _WIN64 when one return(xlretFailed); Clearly, the code is x86 designed ...
The explains why all the XLL functions are not recognized by Excel, for the x64 XLL.
The #else of the #ifdef _WIN64 seems to have valid code, so I have redone the very same that preceeds, but in x86. Here, I didn't even break in the entry point ...
As I am no IT nor an XLL expert, I would be glad would someone point to a valid correction.
The text was updated successfully, but these errors were encountered: