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 supplied to 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 to the function xlfRegister are optional strings corresponding 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 only be retrieved 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, you could use a binary name to store command-related data, for example.

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 has been fixed in Excel 2007.

Excel currently does not complain if the calculation that a data table is based on refers to something in the table itself. As unlikely as this scenario might be, you should be careful when you are creating or modifying formulas that are used to calculate data table values.

Because the integer type xltypeInt in the XLOPER12 is a 32-bit signed integer, but it is only a 16-bit signed integer in the XLOPER, it is possible that some integer XLOPER12 values cannot be contained in an integer XLOPER. Where Excel 2007 is converting this type internally, it gets around this by converting the type to a floating point xltypeNum XLOPER.

The Framework function XLOper12ToXLOper mirrors this behavior to be consistent with Excel internally. You should be careful when you are calling this function to 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 2007 and earlier versions permit 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, thinking that it was allocated by itself, which could cause an immediate application crash. You should not use the technique of modifying XLOPER/XLOPER12 arguments in this way. All XLOPER or XLOPER12 arguments should be treated as strictly read-only.

For more information, see Memory Management in Excel 2007.

Reference

Concepts