|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Known Issues in Excel XLL Development
Last modified: March 13, 2009
Applies to: Excel 2010 | Office 2010 | VBA | Visual Studio
In this article
Unregistering XLL Commands and Functions
Argument Description String Truncation in the Function Wizard
Binary Name Scope Limitation
xlSet and Workbooks with Array Formulas
Circular References are Tolerated in Data Tables
Converting an Integer XLOPER12 to an XLOPER
Returning XLOPER or XLOPER12 by Modifying Arguments in Place
This topic describes known issues in Microsoft Excel that you might encounter in XLL development.
When an XLL registers a function or command, Excel creates a new name for the resource and associates a reference to the DLL function with that name. The name is taken from the fourth argument of the the xlfRegister function. This name is hidden from the normal dialog boxes for managing worksheet names. To unregister a function or command, you must delete the name by using the xlfSetName function, passing the name but not passing a definition. However, a bug prevents this from removing the name from the Function Wizard lists.
Arguments 11 onwards of the xlfRegister function are optional strings that correspond to the arguments of the XLL function. The Function Wizard displays these to provide help in the argument construction dialog box. Sometimes Excel truncates the string that corresponds to the final argument by one or two characters when displaying it in the dialog box. You can avoid this by adding one or two spaces to the end of the final string.
Binary names and their data can be retrieved only when the worksheet that was active at the time they were created is again active. Because worksheet functions cannot activate worksheets within a workbook (only commands can do this), applications of binary names are very limited. If you have a command that is only invoked from a particular worksheet, for example, you could use a binary name to store command-related data.
In Excel 2003 and earlier versions, the xlSet function fails if you try to assign values to a range on a worksheet that is not the active worksheet, where the equivalent range on the active sheet contains an array formula. In this case, Excel displays the message "You cannot change part of an array." This was fixed in Excel 2007.
Because the integer type xltypeInt is a 32-bit signed integer in the XLOPER12 data type, but it is only a 16-bit signed integer in the XLOPER data type, it is possible that some integer XLOPER12 values cannot be contained in an integer XLOPER. Where Excel converts this type internally, it gets around this problem by converting the type to a floating-point xltypeNumXLOPER.
The Framework XLOper12ToXLOper function mirrors this behavior to be consistent with Excel internally. When you call this function, you should not assume that the returned XLOPER will always be xltypeInt; reading my_xloper.val.w gives a false value if the my_xloper type is xltypeNum.
Excel permits the registration of functions that return an XLOPER or XLOPER12 by modifying an argument in place. However, if an XLOPER/XLOPER12 argument points to memory, and the pointer is then overwritten by the return value of the DLL function, Excel can leak memory. Excel does not display an error, but it might eventually crash. Also, if the DLL allocated memory for the return value, Excel might try to free that memory, which could cause an immediate application crash. Therefore, you should not modify XLOPER/XLOPER12 arguments in place. All XLOPER or XLOPER12 arguments should be treated as strictly read-only.
For more information, see Memory Management in Excel.