Pat,

There is a part of this loop I cannot grasp.

I now have C++ and have successfully compiled some Math-example program written in C++ into a DLL
which can be called by VBA in Excel. So far so good!

What is missing is what I want to accomplish which is protect my current VBA code.

What steps do I have to take to be able to drop my VBA (Excel) code into a C++ via Win32 Console
Application Project and then ending up with an Com Addin of a DLL?

As I see it:
Plan A Plan B
1) have VBA code (Excel) 1) VBA code
2) Possible save that code as a .xla file 2) Drop into VB.NET and/or C++
3) Compile into DLL (With what? and how?) 3) Compile into a DLL
4) Call DLL from Excel VBA 4) Call DLL from Excel VBA


EagleOne




"Patrick Molloy" wrote:

IMHO if you want to create a library of functions just for Excel, then use
VB.NET
These are all programming languages, and they all have their merits.
As Chip says, its easier to get to grips with if you're already somewhat
familiar with VB/VBA and once a DLL is compiled, its machine code, so the
application used isn't really relevant anymore.
I used Chip's VB.NET for creating my first COM ...thanks Chip ! -- and I
simply typed his code, and followed his example exactly, using Visual Studio
2008. The DLL i compiled worked for Excel 2003 and Excel 2007 as well, so
that suited my needs perfectly

regards
Patrick



wrote in message
.. .
Chip,

With others guidance, including you, and a ton of time, I have been able
to accomplish many
meaningful VBA projects.

That said, I have paid the time-price of not having any formal coding
training. My point, I do not
know the relationship(s) of of C++ to VB.NET.

Bottom line, it appears to me that I should learn VB.NET. At this point,
my only interest in C, C+
C++ is that it is a means to an end of creating DLL files to be called
from VBA.

Frankly, I do not know the "+'s" or "-'s" of creating Code-behind vs Com
Addins. Also, I do not
have the perspective to appreciate if I need to use C++ or just VB.NET.

Therefore, my "only" goal is to create
relatively-secure-original-source-code DLL's which will
work/function on both Excel 2003 and 2007. Also, my lack of
code-perspective, inhibits me to
understand if all of the information that you have made available is
enough to hande my goal.

My plans were to begin today utilizing the information you have provided
to create my DLLs.

Do I need both: Add-In Express For NET 2008 and Add-In Express For VSTO
2008?

You have no idea how appreciative I am for you and other MVP's to take
time and transfer knowledge.

EagleOne


Chip Pearson wrote:


The examples on Chip's site use VB 6. When I became interested in
compiling VBA, I was told that VB
6 was/is on the way out. Therefore I got Visual Studio C+.

As noted, I also have VB.NET examples of an automation add-in (NET
ClassLib project). Even though VB6 is on its way out (or already is
out, depending on who you ask), it still provides more and better
functionality than VBA ever will. (VBA, too, is on the way out. The
language hasn't been updated in nearly a decade. In the future, some
incarnation of NET is going to supplant everything.) If you don't
already have VB6 or don't have an MSDN subscription, obtaining VS6 may
be a challenge.

The nice thing about using the NET framework is that it doesn't really
matter what language you code in and that the functional requirements
of an application don't generally dictate much about which language to
use. If you're good in VBA and/or VB6, VB.NET is reasonably easy to
learn. If you're a C/C++ person, you could use C++ or C#. You can
even use COBOL if you're really nuts for it.

If you're going to be writing automation libraries, you can do that
with straight NET code, whichever language you prefer. For add-ins,
though, you'll probably want to use Visual Studio Tools For Office.
This is a separate product for Visual Studio 2003 and VS2005, but it
included integrated into VS2008 as part of the package. The real
problem when writing what are called "code behind" workbooks is that
if you have Excel 2007 installed on your system, you can create only
2007 code-behind applications. Even if you have both XL 2003 and 2007
installed, you can still create only 2007 projects due to the way
interoperability is handled. (I use a VM running Windows XP with
Office 2003 only if I need it.) Various press reports say, though,
that this limitation will be remedied in VS2010 or whatever comes
after VS2008.

If you are aiming to write commercial quality code-behind or add-ins
for Office using NET, I would strongly recommend Add-In Express For
NET 2008 and Add-In Express For VSTO 2008
(http://www.add-in-express.com). These project prototypes and their
attendant assemblies make writing NET for Office much simpler, and
extend what is possible using NET/Office alone. It also overcomes the
2003/2007 interoperability problems. AIX can also automatically create
a setup/deployment package that is much better than Microsoft's. AIX
also supports creating XLL add-ins on the new Office 12 standard.



Cordially,
Chip Pearson
Microsoft Most Valuable Professional
Excel Product Group, 1998 - 2009
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)

On Sat, 16 May 2009 20:44:25 -0400,
wrote:

Thanks Gord.

The examples on Chip's site use VB 6. When I became interested in
compiling VBA, I was told that VB
6 was/is on the way out. Therefore I got Visual Studio C+.

Do you have any thoughts on where I can get similar information (Chip's
info) for C+? I have no
experience with any code other than VBA.

TIA EagleOne


Gord Dibben <gorddibbATshawDOTca wrote:

Try Chip Pearson's site.

http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

Or

http://www.cpearson.com/excel/automationaddins.aspx



Gord Dibben MS Excel MVP


On Sat, 16 May 2009 19:47:11 -0400,
wrote:

2003, 2007

I have a VBA Procedure that I would like to compile into a DLL which
can be called from an Excel
macro so that I can protect the original source VBA code.

A working example would be great as that is the way I learn best.

Any thoughts, examples, plan of attack, links greatly appreciated.

TIA EagleOne