Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .
Is there a book on the subject anywhere ?.
Is there a speed penalty ?
Thanks all - Charles Jordan

Choice of language depends on various factors e.g. version of Office,
existing knowledge base, financial outlay for development tools, etc.

For example, if you are developing for Excel2000, your existing
knowledge is primarily VBA and you like the idea of picking up a
bargain on eBay, you'd probably go for Visual Basic 6.0.

If I had the choice and unlimited resources (time and money), I'd go
for Excel2003 and take on the challenge C# in VS.NET with the help of
Visual Studio Tools for Office.

--

(Charles Jordan) wrote in message . com...
Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .
Is there a book on the subject anywhere ?.
Is there a speed penalty ?
Thanks all - Charles Jordan

(onedaywhen) wrote in message . com...
Choice of language depends on various factors e.g. version of Office,
existing knowledge base, financial outlay for development tools, etc.

For example, if you are developing for Excel2000, your existing
knowledge is primarily VBA and you like the idea of picking up a
bargain on eBay, you'd probably go for Visual Basic 6.0.

If I had the choice and unlimited resources (time and money), I'd go
for Excel2003 and take on the challenge C# in VS.NET with the help of
Visual Studio Tools for Office.

--

(Charles Jordan) wrote in message . com...
Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .
Is there a book on the subject anywhere ?.
Is there a speed penalty ?
Thanks all - Charles Jordan

Hi Oneday! Very interesting.. Because we are writing code to a
University audience, mostly outside the UK, we have to write to the
lowest common denominator which we take to be Excel 2000, and up, and
because there is a LOT of code, the idea is to write enough so as to
hide some of our key routines and thus cripple it unless it is a legal
copy. I note that you are not a million miles away from Aberdeenshire
- and given the broad nature of my question I don't think it would be
rude to the NG to ask whether we could possibly speak, briefly ?? If
so you can reach me in the first instance on
, and it would be much appreciated .

TIA - Charles

"Charles Jordan" wrote in message
om...
Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .

If its existing VBA code then by far the simplest conversion
will be to use Visual Studio Professional 6 as with a little
rework you can use much of your existing code.

If its part of a larger development and you can use
Excel 2003 then go for C#

Is there a book on the subject anywhere ?.

Sure but there's a lot of info on the microsoft website

http://support.microsoft.com/?kbid=238228

Keith

"Keith Willshaw" wrote in message ...
"Charles Jordan" wrote in message
om...
Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .

If its existing VBA code then by far the simplest conversion
will be to use Visual Studio Professional 6 as with a little
rework you can use much of your existing code.

If its part of a larger development and you can use
Excel 2003 then go for C#

Is there a book on the subject anywhere ?.

Sure but there's a lot of info on the microsoft website

http://support.microsoft.com/?kbid=238228

Keith

Keith - thanks. It *is* quite a large development - some of us have
been on it 100% for eight years, and we want to be able to supply it
to students around the world, some of them still using Excel 2000, and
some up to 2003. On the other hand, if there are very large advantages
attached to C# maybe we should migrate in that direction sooner or
later anyway, which you seemed to indicate would only apply if they
had Excel 2003. Given the complexity of the subject, can we contact
you by e-mail ? Thanks - Charles Jordan

Many visitors of these groups would love to follow the discussion, so please
keep it in the newsgroup.

For older versions of Excel, you can certainly use C++ and wrap the calls in
a very slim VBA shell. That gives you the speed advantages of C, although
for most users that is hardly noticeable.
I'm not sure about C#, but I suspect something similar is possible.
I would like to hear from the experts!

--

Kind Regards,

Niek Otten

Microsoft MVP - Excel

"Charles Jordan" wrote in message
om...
"Keith Willshaw" wrote in message
...
"Charles Jordan" wrote in message
om...
Hi all. We have been wondering lately whether to convert some of our
code into DLL's, called from within Excel in order to (a) conceal the
source - at least partially and (b) possibly make it more efficient.
Can any one with experience of this suggest a platform. Names
mentioned so far have been C, C++, Delphi .

If its existing VBA code then by far the simplest conversion
will be to use Visual Studio Professional 6 as with a little
rework you can use much of your existing code.

If its part of a larger development and you can use
Excel 2003 then go for C#

Is there a book on the subject anywhere ?.

Sure but there's a lot of info on the microsoft website

http://support.microsoft.com/?kbid=238228

Keith

Keith - thanks. It *is* quite a large development - some of us have
been on it 100% for eight years, and we want to be able to supply it
to students around the world, some of them still using Excel 2000, and
some up to 2003. On the other hand, if there are very large advantages
attached to C# maybe we should migrate in that direction sooner or
later anyway, which you seemed to indicate would only apply if they
had Excel 2003. Given the complexity of the subject, can we contact
you by e-mail ? Thanks - Charles Jordan

"Charles Jordan" wrote in message
om...


Keith - thanks. It *is* quite a large development - some of us have
been on it 100% for eight years, and we want to be able to supply it
to students around the world, some of them still using Excel 2000, and
some up to 2003. On the other hand, if there are very large advantages
attached to C# maybe we should migrate in that direction sooner or
later anyway, which you seemed to indicate would only apply if they
had Excel 2003.

Excel 2003 still uses VBA as will the next release of Office
as I understand it. So at this stage there are no compelling
reasons unless you have other code writtent in .net that
you wish to interface with.

I have two developments in hand at present, one is an
Excel Datasheet that interacts with various databases
and is currently written in VBA. That will be migrated
to a COM add-in targetting Excel 2000 and higher to minimise
re-work.

The other interfaces an Excel sheet to proprietary hydraulics
calculation code written in C#, we will use .net for that

Given the complexity of the subject, can we contact
you by e-mail ? Thanks - Charles Jordan

I'd rather you didnt , my employers may take a dim view
of my giving more than general advice.

Keith

"Keith Willshaw" wrote in message ...
"Charles Jordan" wrote in message
om...


Keith - thanks. It *is* quite a large development - some of us have
been on it 100% for eight years, and we want to be able to supply it
to students around the world, some of them still using Excel 2000, and
some up to 2003. On the other hand, if there are very large advantages
attached to C# maybe we should migrate in that direction sooner or
later anyway, which you seemed to indicate would only apply if they
had Excel 2003.

Excel 2003 still uses VBA as will the next release of Office
as I understand it. So at this stage there are no compelling
reasons unless you have other code writtent in .net that
you wish to interface with.

I have two developments in hand at present, one is an
Excel Datasheet that interacts with various databases
and is currently written in VBA. That will be migrated
to a COM add-in targetting Excel 2000 and higher to minimise
re-work.

The other interfaces an Excel sheet to proprietary hydraulics
calculation code written in C#, we will use .net for that

Given the complexity of the subject, can we contact
you by e-mail ? Thanks - Charles Jordan

I'd rather you didnt , my employers may take a dim view
of my giving more than general advice.

Keith


Thanks Keith. We'll pursue other avenues - no doubt there are lots. Charles