Just released: Excel 2007 XLL Software Development Kit

[Danny Khen [MSFT]]

The Microsoft Office Excel 2007 XLL Software Development Kit is out the door
at long last. Many Excel developers have been waiting for the new XLL SDK
for a long time now, since we released Office 2007 at the end of last year.
It took us longer than we had initially thought to update the SDK content
and develop the new documentation, but we hope that you will find the wait
was worthwhile, and will be satisfied with the quality of the final SDK
we've just released - the API files, the framework and code samples, and of
course the extensive and detailed documentation.

Please find the new SDK here:
1. Download:
http://www.microsoft.com/downloads/...d1-93ab-4bd4-af18-cb6bb487e1c4&displaylang=en
2. Online documentation:
http://msdn2.microsoft.com/en-us/library/bb687883.aspx

Excerpt from the SDK documentation:

The Microsoft Office Excel 2007 XLL Software Development Kit is designed to
help you understand the relevant concepts and technologies that relate to
creating DLL add-ins for Microsoft Office Excel 2007 that use the Excel C
API. The C API enables DLLs to be integrated tightly with Excel 2007 and to
access the internal functionality in Excel. These DLL add-ins are known as
XLLs, given that they are usually given the file name extension .xll.
The primary reason for writing XLLs and using the C API is to create
high-performance worksheet functions. Although XLL functions are frequently
referred to as user-defined functions, the investment in time to obtain the
understanding and skills that are required to write XLLs make this a
technology impractical for most users. Nevertheless, the applications of
high-performance functions-and, in Excel 2007, the ability to write
multithreaded interfaces to powerful server resources-make it a very
important part of Excel extensibility. The performance of XLLs is further
enhanced in Excel 2007 by the addition of new data types and, most
important, support for multithreading.
The Excel 2007 XLL Software Development Kit contains a framework library
that is designed to speed up the writing of XLLs, and also three sample
projects.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars, and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Keith A. Lewis]

According the the SDK Redist License Terms, it seems xlcall.h, xlcall.cpp,
and xlcall32.lib
are not redistributable. I hope I'm wrong, but if not, is the appropriate
way of providing these
is to have users download and install the Microsoft SDK?

Thanks,
Keith A. Lewis

 

[Guest]

Dear Danny,

Thank you for providing the new SDK.

The only thing that the SDK lacks is a decent object oriented framework
wrapper. It would be nice to have some classes available which would hide the
complexity of memory management, working with specific data types
(XLOPER/XLOPER12), registration/unregistration of
UDFs/menus/commands/toolbars etc. The wrapper could take care of handling
different Excel versions, working with Pascal-style strings, and many other
little but annoying things.

For an example of such a wrapper, please see http://xlw.sourceforge.net.
This is an open source project which looks great, but which shouldn't be used
in a serious commercial project as it may contain unexpected bugs.

The old-style C API might be more efficient than the C++ wrapper, but
using it in modern software projects is very counterproductive and error
prone. I am sure most (if not all) C++ developers would be interested in
having a C++ wrapper officially supported by Microsoft.

I've noticed that the new SDK includes two C++ classes, MemoryManager and
MemoryPool, which is great! But the rest of things look like in the old Excel
97 days -- that's 10 years ago..

Do you have any plans to provide a similar object oriented framework in
the nearest future?

Thanks for your help!

--
Regards,
Antony

The Microsoft Office Excel 2007 XLL Software Development Kit is out the door
at long last. Many Excel developers have been waiting for the new XLL SDK
for a long time now, since we released Office 2007 at the end of last year.
It took us longer than we had initially thought to update the SDK content
and develop the new documentation, but we hope that you will find the wait
was worthwhile, and will be satisfied with the quality of the final SDK
we've just released - the API files, the framework and code samples, and of
course the extensive and detailed documentation.

Please find the new SDK here:
1. Download:
http://www.microsoft.com/downloads/...d1-93ab-4bd4-af18-cb6bb487e1c4&displaylang=en
2. Online documentation:
http://msdn2.microsoft.com/en-us/library/bb687883.aspx

Excerpt from the SDK documentation:

The Microsoft Office Excel 2007 XLL Software Development Kit is designed to
help you understand the relevant concepts and technologies that relate to
creating DLL add-ins for Microsoft Office Excel 2007 that use the Excel C
API. The C API enables DLLs to be integrated tightly with Excel 2007 and to
access the internal functionality in Excel. These DLL add-ins are known as
XLLs, given that they are usually given the file name extension .xll.
The primary reason for writing XLLs and using the C API is to create
high-performance worksheet functions. Although XLL functions are frequently
referred to as user-defined functions, the investment in time to obtain the
understanding and skills that are required to write XLLs make this a
technology impractical for most users. Nevertheless, the applications of
high-performance functions-and, in Excel 2007, the ability to write
multithreaded interfaces to powerful server resources-make it a very
important part of Excel extensibility. The performance of XLLs is further
enhanced in Excel 2007 by the addition of new data types and, most
important, support for multithreading.
The Excel 2007 XLL Software Development Kit contains a framework library
that is designed to speed up the writing of XLLs, and also three sample
projects.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars, and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Keith A. Lewis]

Dear Danny,

Thank you for providing the new SDK.

The only thing that the SDK lacks is a decent object oriented framework
wrapper. It would be nice to have some classes available which would hide
the
complexity of memory management, working with specific data types
(XLOPER/XLOPER12), registration/unregistration of
UDFs/menus/commands/toolbars etc. The wrapper could take care of handling
different Excel versions, working with Pascal-style strings, and many
other
little but annoying things.

For an example of such a wrapper, please see http://xlw.sourceforge.net.
This is an open source project which looks great, but which shouldn't be
used
in a serious commercial project as it may contain unexpected bugs.

Please excuse me tooting my own horn here, but I have
such a product and am in the beta testing phase for the
latest version that solves some of the problems involved
in creating add-ins that work in Excel 2007 and older
versions. Anyone that is interested in being in the
program can e-mail (e-mail address removed). Currently
there are only versions for VC++ 7.1 and 8.

Please see http://kalx.net/xll/README.htm for a description of
how to use the library. Note that the code you see there is all
that you need to create add-ins. All of the xlAuto* functions
are provided in xll.lib.

Keith A. Lewis

 

[Steve Dalton]

Hi Antony

The second edition of my book, Financial applications using Excel add-in
development in C/C++, published by Wiley, contains an example C++ class that
wraps access, including all memory issues, to the XLOPER, the XLOPER12 and
the Excel callbacks Excel4, Excel12 etc. It also wraps access to strings,
XLOPER arrays and supports the idea of XLLs being version-aware and
thread-safe. It is not held forward as a commercially robust piece of
software, but there is plenty of discussion in the book about what such a
class should do. As an author, the quality threshhold you aim for is
'bug-free', but that can't be a guarantee. I do use it myself in a few
projects in the field.

Steve

Dear Danny,

Thank you for providing the new SDK.

The only thing that the SDK lacks is a decent object oriented framework
wrapper. It would be nice to have some classes available which would hide
the
complexity of memory management, working with specific data types
(XLOPER/XLOPER12), registration/unregistration of
UDFs/menus/commands/toolbars etc. The wrapper could take care of handling
different Excel versions, working with Pascal-style strings, and many
other
little but annoying things.

For an example of such a wrapper, please see http://xlw.sourceforge.net.
This is an open source project which looks great, but which shouldn't be
used
in a serious commercial project as it may contain unexpected bugs.

The old-style C API might be more efficient than the C++ wrapper, but
using it in modern software projects is very counterproductive and error
prone. I am sure most (if not all) C++ developers would be interested in
having a C++ wrapper officially supported by Microsoft.

I've noticed that the new SDK includes two C++ classes, MemoryManager and
MemoryPool, which is great! But the rest of things look like in the old
Excel
97 days -- that's 10 years ago..

Do you have any plans to provide a similar object oriented framework in
the nearest future?

Thanks for your help!

--
Regards,
Antony

The Microsoft Office Excel 2007 XLL Software Development Kit is out the
door
at long last. Many Excel developers have been waiting for the new XLL SDK
for a long time now, since we released Office 2007 at the end of last
year.
It took us longer than we had initially thought to update the SDK content
and develop the new documentation, but we hope that you will find the
wait
was worthwhile, and will be satisfied with the quality of the final SDK
we've just released - the API files, the framework and code samples, and
of
course the extensive and detailed documentation.

Please find the new SDK here:
1. Download:
http://www.microsoft.com/downloads/...d1-93ab-4bd4-af18-cb6bb487e1c4&displaylang=en
2. Online documentation:
http://msdn2.microsoft.com/en-us/library/bb687883.aspx

Excerpt from the SDK documentation:

The Microsoft Office Excel 2007 XLL Software Development Kit is designed
to
help you understand the relevant concepts and technologies that relate to
creating DLL add-ins for Microsoft Office Excel 2007 that use the Excel C
API. The C API enables DLLs to be integrated tightly with Excel 2007 and
to
access the internal functionality in Excel. These DLL add-ins are known
as
XLLs, given that they are usually given the file name extension .xll.
The primary reason for writing XLLs and using the C API is to create
high-performance worksheet functions. Although XLL functions are
frequently
referred to as user-defined functions, the investment in time to obtain
the
understanding and skills that are required to write XLLs make this a
technology impractical for most users. Nevertheless, the applications of
high-performance functions-and, in Excel 2007, the ability to write
multithreaded interfaces to powerful server resources-make it a very
important part of Excel extensibility. The performance of XLLs is further
enhanced in Excel 2007 by the addition of new data types and, most
important, support for multithreading.
The Excel 2007 XLL Software Development Kit contains a framework library
that is designed to speed up the writing of XLLs, and also three sample
projects.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars,
and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Govert van Drimmelen]

Well, since everyone is touting their pet project, I might as well
jump in too ;-)

ExcelDna (http://groups.google.com/group/exceldna) is a wrapper of the
type Anthony refers to, but for integration with the .Net world. You
can make user-defined functions and macros in any .Net language (also
Visual Basic, for ease of porting your VBA code and skills, and
features like late-binding). Your library code can either be compiled
to a .dll or reside in a text-based script file that is dynamically
compiled and linked in. The only dependency on the client PC is
the .Net 2.0 runtime.

ExcelDna is built on the Excel XLL SDK interfaces, and I plan to
update it for the Excel 12 SDK in the next few months (depending on
user demand). Of course it already works in Excel versions from 97 to
2007, but integrating with the new SDK will give access to long,
Unicode strings, the large sheet, multithreading and the like. I
expect user add-ins to work transparently across versions.

User-defined functions in your library are automatically registered,
you can add custom descriptions categories and help, and menu entries
for your macros, and you never need to deal with an XLOPER again.
Function calls into Excel also dynamically translate the arguments -
just call Excel4/Excel12 with your .Net strings and ints - no memory
management hassles.

The performance of ExcelDna compares favourably with that of the C/C++
interface (seems like about 15% slower on the functions I use). And
the productivity boost from working in C# is awesome. Existing C/C++
libraries can still be called easily if some of the heavy lifting
really needs to be optimised (though .Net normally does a pretty good
job of numerical computations too).

ExcelDna is offered under a liberal open-source license, that
explicitly allows commercial use of the library.

In the announcement Danny states: "Although XLL functions are
frequently referred to as user-defined functions, the investment in
time to obtain the understanding and skills that are required to write
XLLs make this a technology impractical for most users." I think
ExcelDna is a greate start towards reviving true user-defined
functionality in the modern .Net environment. (I just need to add an
IDE - any volunteers?)

- Govert

 

[Guest]

Hi,

Thank you everyone for your replies.

Keith: Your project looks interesting, but to be clear, I am looking for
something that covers all aspects of developing XLLs, something more
high-level but also flexible enough.

To give you an idea:
Imagine that you wish to obtain a reference to a currently selected range
of cells in your XLL. To do this, you have to call Excel() with xlfSelection;
if the call is successful, see whether it's xltypeRef, xltypeSRef, or maybe
xltypeStr; if it's xltypeRef, you have to digg into the reference array
(xloper.mref.lpmref->reftbl) and extract the information you need; and
finally, you have to free memory.

Now, imagine you could do just the same thing in a more elegant way:

std::vector <CRef> x;
if (Excel.Selection(&x) && x.size() > 0)
{
cout << "First row: " << x[0].RowFirst << endl;
}
else
{
// no luck
}

Another example:
You do care about supporting international versions of Excel, so you need
to obtain the decimal separator (which might be "." or "," etc.) for further
float-to-string conversions in your add-in. Using the C API alone, the code
would look like::

xloper xSettings;

// 37 means "A 45-item horizontal array of the items related
// to country versions and settings" (see Macrofun.hlp)
if (Excel(xlfGetWorkspace, &xSettings, 1, TempNum(37)) == xlretSuccess)
{
// lparray[2] is a decimal separator;
char *pascalStyleSeparator = xSettings.val.array.lparray[2].val.str;

// convert pascalStyleSeparator to a C-style sting
// ...

Excel4(xlFree, 0, 1, &xSettings);
}

The same could look like:

CString separator = Excel().GetWorkspace().Separator;

That's how I imagine the C++ wrapper should work. Maybe I am asking for
too much, but having such a framework available would be great.

Steve: Your book is amazing, I look forward to purchasing the 2nd edition.
Do you have any estimates on how many C++ XLL developers are out there -
hundreds, thousands, more? I'd be very grateful if you could share this
information. Thanks!

Govert : ExcelDNA looks great, but I have chosen to use XLLs primarily due
to performance considerations, and try to avoid using COM at all costs.

--
Regards,
Antony

Dear Danny,

Thank you for providing the new SDK.

The only thing that the SDK lacks is a decent object oriented framework
wrapper. It would be nice to have some classes available which would hide the
complexity of memory management, working with specific data types
(XLOPER/XLOPER12), registration/unregistration of
UDFs/menus/commands/toolbars etc. The wrapper could take care of handling
different Excel versions, working with Pascal-style strings, and many other
little but annoying things.

For an example of such a wrapper, please see http://xlw.sourceforge.net.
This is an open source project which looks great, but which shouldn't be used
in a serious commercial project as it may contain unexpected bugs.

The old-style C API might be more efficient than the C++ wrapper, but
using it in modern software projects is very counterproductive and error
prone. I am sure most (if not all) C++ developers would be interested in
having a C++ wrapper officially supported by Microsoft.

I've noticed that the new SDK includes two C++ classes, MemoryManager and
MemoryPool, which is great! But the rest of things look like in the old Excel
97 days -- that's 10 years ago..

Do you have any plans to provide a similar object oriented framework in
the nearest future?

Thanks for your help!

--
Regards,
Antony

The Microsoft Office Excel 2007 XLL Software Development Kit is out the door
at long last. Many Excel developers have been waiting for the new XLL SDK
for a long time now, since we released Office 2007 at the end of last year.
It took us longer than we had initially thought to update the SDK content
and develop the new documentation, but we hope that you will find the wait
was worthwhile, and will be satisfied with the quality of the final SDK
we've just released - the API files, the framework and code samples, and of
course the extensive and detailed documentation.

Please find the new SDK here:
1. Download:
http://www.microsoft.com/downloads/...d1-93ab-4bd4-af18-cb6bb487e1c4&displaylang=en
2. Online documentation:
http://msdn2.microsoft.com/en-us/library/bb687883.aspx

Excerpt from the SDK documentation:

The Microsoft Office Excel 2007 XLL Software Development Kit is designed to
help you understand the relevant concepts and technologies that relate to
creating DLL add-ins for Microsoft Office Excel 2007 that use the Excel C
API. The C API enables DLLs to be integrated tightly with Excel 2007 and to
access the internal functionality in Excel. These DLL add-ins are known as
XLLs, given that they are usually given the file name extension .xll.
The primary reason for writing XLLs and using the C API is to create
high-performance worksheet functions. Although XLL functions are frequently
referred to as user-defined functions, the investment in time to obtain the
understanding and skills that are required to write XLLs make this a
technology impractical for most users. Nevertheless, the applications of
high-performance functions-and, in Excel 2007, the ability to write
multithreaded interfaces to powerful server resources-make it a very
important part of Excel extensibility. The performance of XLLs is further
enhanced in Excel 2007 by the addition of new data types and, most
important, support for multithreading.
The Excel 2007 XLL Software Development Kit contains a framework library
that is designed to speed up the writing of XLLs, and also three sample
projects.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars, and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Govert van Drimmelen]

Govert : ExcelDNA looks great, but I have chosen to use XLLs primarily due

to performance considerations, and try to avoid using COM at all costs.

Hi Anthony,

Just to be clear: ExcelDna is built on the XLL interface, and does not
use the Excel COM integration at all. As a result, the performance of
managed code running on ExcelDna is similar to native XLL add-ins,
with at most some tens of processor instructions per function call
overhead for the unmanaged->managed->unmanaged transitions.

Regards,
Govert

 

[Keith A. Lewis]

Hi,

Thank you everyone for your replies.

Keith: Your project looks interesting, but to be clear, I am looking for
something that covers all aspects of developing XLLs, something more
high-level but also flexible enough.

You'll have to look at it and decide if it fits your needs.

Now, imagine you could do just the same thing in a more elegant way:

std::vector <CRef> x;
if (Excel.Selection(&x) && x.size() > 0)
{
cout << "First row: " << x[0].RowFirst << endl;
}
else
{
// no luck
}

Using my XLL library you would get the xltypeMulti
corresponding to the selection using:

OPER x = Excel(xlCoerce, Excel(xlfSelection));

No memory leaks.An exception is throw if something fails.
Elements are accessed linearly using operator[] and 2d
using operator().

Another example:
You do care about supporting international versions of Excel, so you need
to obtain the decimal separator (which might be "." or "," etc.) for
further
float-to-string conversions in your add-in. Using the C API alone, the
code
would look like::

xloper xSettings;

// 37 means "A 45-item horizontal array of the items related
// to country versions and settings" (see Macrofun.hlp)
if (Excel(xlfGetWorkspace, &xSettings, 1, TempNum(37)) == xlretSuccess)
{
// lparray[2] is a decimal separator;

ITYM 3, not 2.

char *pascalStyleSeparator = xSettings.val.array.lparray[2].val.str;

// convert pascalStyleSeparator to a C-style sting
// ...

Excel4(xlFree, 0, 1, &xSettings);
}

The same could look like:

CString separator = Excel().GetWorkspace().Separator;

My way:

string separator = String(Excel(xlfGetWorkspace, Num(37))[3]);

Again, no memory leaks and throws if something unexpected happens.

My philosophy is to use thin wrappers around the Excel SDK, not
rewrite my own that I have to test and document, or even worse,
that I have to design and then convince others is the "right" way.

That's how I imagine the C++ wrapper should work. Maybe I am asking for
too much, but having such a framework available would be great.

Sometimes you just have to work with what you got.I've found that
people having some experience with the raw SDK don't believe it is
possible to make it as simple as my library makes it. All I can say is
try it. mailto:[email protected]

Keith A. Lewis | KALX, LLC | http://kalx.net

440 Ninth Ave., 8th Floor | New York, NY 10001

Phone: 212.404.2311 | Fax: 212.404.3228

 

[Guest]

Govert,

Sorry, I meant managed code. I think ExcelDNA only works with .NET? I've got
a lot of code written in pure C/C++ so there's no good reason to use .NET.

 

[Guest]

Keith,

Thanks for your reply.

// 37 means "A 45-item horizontal array of the items related
// to country versions and settings" (see Macrofun.hlp)
if (Excel(xlfGetWorkspace, &xSettings, 1, TempNum(37)) == xlretSuccess)
{
// lparray[2] is a decimal separator;

ITYM 3, not 2.

No, I meant 2 - the C array is zero-based.

My philosophy is to use thin wrappers around the Excel SDK,
not rewrite my own that I have to test and document, or even
worse, that I have to design and then convince others is the
"right" way.

I think there is no "right" way really. You can just hide the complexity of
handling all these little things (like the array index - 3 or 2? I had to
test it..) in a way similar to how Microsoft's MFC and Borland's VCL hide the
complexity of dealing with WinAPI. That's not like you are rewriting the core
SDK - you're just providing a *little bit* thicker wrapper and a *much more*
easy, productive, safe and intuitive way to develop add-ins.

Thanks again for taking your time.

--
Regards,
Antony

Hi,

Thank you everyone for your replies.

Keith: Your project looks interesting, but to be clear, I am looking for
something that covers all aspects of developing XLLs, something more
high-level but also flexible enough.

You'll have to look at it and decide if it fits your needs.

Now, imagine you could do just the same thing in a more elegant way:

std::vector <CRef> x;
if (Excel.Selection(&x) && x.size() > 0)
{
cout << "First row: " << x[0].RowFirst << endl;
}
else
{
// no luck
}

Using my XLL library you would get the xltypeMulti
corresponding to the selection using:

OPER x = Excel(xlCoerce, Excel(xlfSelection));

No memory leaks.An exception is throw if something fails.
Elements are accessed linearly using operator[] and 2d
using operator().

Another example:
You do care about supporting international versions of Excel, so you need
to obtain the decimal separator (which might be "." or "," etc.) for
further
float-to-string conversions in your add-in. Using the C API alone, the
code
would look like::

xloper xSettings;

// 37 means "A 45-item horizontal array of the items related
// to country versions and settings" (see Macrofun.hlp)
if (Excel(xlfGetWorkspace, &xSettings, 1, TempNum(37)) == xlretSuccess)
{
// lparray[2] is a decimal separator;

ITYM 3, not 2.

char *pascalStyleSeparator = xSettings.val.array.lparray[2].val.str;

// convert pascalStyleSeparator to a C-style sting
// ...

Excel4(xlFree, 0, 1, &xSettings);
}

The same could look like:

CString separator = Excel().GetWorkspace().Separator;

My way:

string separator = String(Excel(xlfGetWorkspace, Num(37))[3]);

Again, no memory leaks and throws if something unexpected happens.

My philosophy is to use thin wrappers around the Excel SDK, not
rewrite my own that I have to test and document, or even worse,
that I have to design and then convince others is the "right" way.

That's how I imagine the C++ wrapper should work. Maybe I am asking for
too much, but having such a framework available would be great.

Sometimes you just have to work with what you got.I've found that
people having some experience with the raw SDK don't believe it is
possible to make it as simple as my library makes it. All I can say is
try it. mailto:[email protected]

Keith A. Lewis | KALX, LLC | http://kalx.net

440 Ninth Ave., 8th Floor | New York, NY 10001

Phone: 212.404.2311 | Fax: 212.404.3228

 

[Keith A. Lewis]

Keith, ....

No, I meant 2 - the C array is zero-based.

....
You are correct. My mistake.

I think there is no "right" way really. You can just hide the complexity
of
handling all these little things (like the array index - 3 or 2? I had to
test it..) in a way similar to how Microsoft's MFC and Borland's VCL hide
the
complexity of dealing with WinAPI. That's not like you are rewriting the
core
SDK - you're just providing a *little bit* thicker wrapper and a *much
more*
easy, productive, safe and intuitive way to develop add-ins.

Good points. It is certainly possible to make the arrays
1-based in the C++ wrapper, but then you might make the
opposite mistake when you have your C++ cap on.0-based
seems right to me.

What you want does not exist. What I have is very
close to what you seem to be describing in terms of
the actual number of characters you need to type in
order to produce the functionality specified in your
two examples. If you want to hold out for someone to
write Excel().GetWorkspace().Separator (or should
that be .DecimalSeparator?) and hundreds of
similar functions, that's your choice. If you can live with
String(Excel(xlfGetWorkspace, Num(37))[2]), and have full
access to all of the API, you can get your job done today.

I've solved all the fundamental problems for you: make
it trivial to register functions and macros, have C++
versions of OPER's that work how you expect a variant
to work, handle memory management for Excel4 calls, and
even provide simple ways to hook into xlAuto* and xlOn*
functions. You have the easy and fun part of deciding what
kind of training wheels you want to bolt on the side.

This is the sixth version of the library I've written from
the ground up. I think I'm getting pretty good at it now.
I use earlier versions for the Excel work I do consulting
for hedge funds. Since this version is the first one
designed for Excel 2007, I'm looking for beta testers
before using it in production.

This version of the library addresses some of the issues
involved with writing Excel 2007 macros. In particular,
it allows one to write one set of source code that can be
compiled for either Excel 2007 or older versions, much
like the unicode/non unicode method Microsoft employs.

It also makes it possible to write one set of code that
runs in either environment and takes advantage of the new
SDK features when run in Excel 2007.

If you're a good beta tester, I might even port my menu
and dialog classes over that make it simple to write these
and have them interact properly with Excel. But you have
to actually use and look at the code I wrote. Feel free
to point out where it does not meet your functional
requirements.

No promises on your esthetic requirements.

mailto:[email protected]

Keith A. Lewis | KALX, LLC | http://kalx.net
440 Ninth Ave., 8th Floor | New York, NY 10001
Phone: 212.404.2311 | Fax: 212.404.3228

 

[Danny Khen [MSFT]]

Keith,
There is no need to redistribute those files; users don't need them. All you
need to deploy is the XLL that you come up with; you need the API files to
compile and link, but the XLL doesn't need them in runtime on the user's
machine.

In terms of the SDK itself (for developers), anyone can download and use the
SDK for free, but we want them to get it from us. I think that's what the
legal language means. Does this make sense?

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars, and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Danny Khen [MSFT]]

We don't have current plans to enhance XLLs with an OO interface. In
general, for us to invest in a new OM, we have to consider the broader
context of Excel client + Excel Services. The server does not support XLLs,
so the first consideration would need to be - do we add that support? If we
don't - does it make sense for us to invest in a new framework that's good
only for the client? As you can imagine, we're constantly evaluating this
and other questions, and we have to take strategic approaches, which would
make sense long term, would be easy to support, to develop against, would
make sense as part of Microsoft's and Office's overall programmability
story, etc. There is nothing short-term that I can share unfortunately.

There are many 3rd-party solutions, some of them discussed on this thread,
that can be used right now.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars, and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

Dear Danny,

Thank you for providing the new SDK.

The only thing that the SDK lacks is a decent object oriented framework
wrapper. It would be nice to have some classes available which would hide
the
complexity of memory management, working with specific data types
(XLOPER/XLOPER12), registration/unregistration of
UDFs/menus/commands/toolbars etc. The wrapper could take care of handling
different Excel versions, working with Pascal-style strings, and many
other
little but annoying things.

For an example of such a wrapper, please see http://xlw.sourceforge.net.
This is an open source project which looks great, but which shouldn't be
used
in a serious commercial project as it may contain unexpected bugs.

The old-style C API might be more efficient than the C++ wrapper, but
using it in modern software projects is very counterproductive and error
prone. I am sure most (if not all) C++ developers would be interested in
having a C++ wrapper officially supported by Microsoft.

I've noticed that the new SDK includes two C++ classes, MemoryManager and
MemoryPool, which is great! But the rest of things look like in the old
Excel
97 days -- that's 10 years ago..

Do you have any plans to provide a similar object oriented framework in
the nearest future?

Thanks for your help!

--
Regards,
Antony

The Microsoft Office Excel 2007 XLL Software Development Kit is out the
door
at long last. Many Excel developers have been waiting for the new XLL SDK
for a long time now, since we released Office 2007 at the end of last
year.
It took us longer than we had initially thought to update the SDK content
and develop the new documentation, but we hope that you will find the
wait
was worthwhile, and will be satisfied with the quality of the final SDK
we've just released - the API files, the framework and code samples, and
of
course the extensive and detailed documentation.

Please find the new SDK here:
1. Download:
http://www.microsoft.com/downloads/...d1-93ab-4bd4-af18-cb6bb487e1c4&displaylang=en
2. Online documentation:
http://msdn2.microsoft.com/en-us/library/bb687883.aspx

Excerpt from the SDK documentation:

The Microsoft Office Excel 2007 XLL Software Development Kit is designed
to
help you understand the relevant concepts and technologies that relate to
creating DLL add-ins for Microsoft Office Excel 2007 that use the Excel C
API. The C API enables DLLs to be integrated tightly with Excel 2007 and
to
access the internal functionality in Excel. These DLL add-ins are known
as
XLLs, given that they are usually given the file name extension .xll.
The primary reason for writing XLLs and using the C API is to create
high-performance worksheet functions. Although XLL functions are
frequently
referred to as user-defined functions, the investment in time to obtain
the
understanding and skills that are required to write XLLs make this a
technology impractical for most users. Nevertheless, the applications of
high-performance functions-and, in Excel 2007, the ability to write
multithreaded interfaces to powerful server resources-make it a very
important part of Excel extensibility. The performance of XLLs is further
enhanced in Excel 2007 by the addition of new data types and, most
important, support for multithreading.
The Excel 2007 XLL Software Development Kit contains a framework library
that is designed to speed up the writing of XLLs, and also three sample
projects.

--
Danny Khen
Excel Program Manager, Microsoft Corp.
[To use my email address, replace (dot) and (at) with respective chars,
and
(xxxx) with microsoft.com.]

** This posting is provided "AS IS", with no warranties, and confers no
rights. **

 

[Keith A. Lewis]

Keith,
There is no need to redistribute those files; users don't need them. All
you need to deploy is the XLL that you come up with; you need the API
files to compile and link, but the XLL doesn't need them in runtime on the
user's machine.

In terms of the SDK itself (for developers), anyone can download and use
the SDK for free, but we want them to get it from us. I think that's what
the legal language means. Does this make sense?

Completely. Thanks for the clarification, Danny.

 

[Excel .Net]

We have recently released a new version of Excel4Net v2.0 - the RAD kit for creating Excel spreadsheet applications and add-ins using the .NET framework.

To download a free fully functionally beta version please go to www.excel4net.com/Download.aspx


Key features:

*Easy to use
*Works with VBA and with in-cell functions
*Uses a simple deployment model
*Makes it easy to test and debug your spreadsheet and .NET code
*Have a built-in monitoring and performance profiling capabilities
*Supports users remotely
*Generates documentation for your code
*Runs on Excel 2002, 2003 and 2007, .NET 2.0, 3.0 and 3.5

"Getting started" documentation: http://excel4net.com/Documentation.aspx

"Quick overview" page: http://excel4net.com/Overview.aspx

Download link: http://excel4net.com/Download.aspx