Hi,

since I have serious problems in VBA, I consider to migrate to VSTO. I have
some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new platform
2. Can I compile the project to an executable stand-alone file (.exe) so I
am not dependent to what the user have installed of dll's
3. Does it work with all versions of Office (starting with 2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll (mso9.dll for
office 2000) of the different office versions, which causes a crash on
startup when I build up my menu-bar. Recompilation on the specific excel
version solves the problem, but then I have to maintain at least 3 versions
(2000, XP and 2003). Even subversions (Service Packs and minor upgrades
cause those commilation problems so I cannot keep that much versions).

Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to
VSTO. I have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the problem,
but then I have to maintain at least 3 versions (2000, XP and
2003). Even subversions (Service Packs and minor upgrades cause
those commilation problems so I cannot keep that much
versions).

But going back to your VBA problem, if you develop on your lowest deployment
version of Excel, that should work on all later versions. No need for 3
versions. I don't have 3 versions, and I bet Chip never does.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to
VSTO. I have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the problem,
but then I have to maintain at least 3 versions (2000, XP and
2003). Even subversions (Service Packs and minor upgrades cause
those commilation problems so I cannot keep that much
versions).

versions. I don't have 3 versions, and I bet Chip never does.

I have 5 versions of Excel on my main box.



"Bob Phillips" wrote in
message ...
But going back to your VBA problem, if you develop on your
lowest deployment
version of Excel, that should work on all later versions. No
need for 3
versions. I don't have 3 versions, and I bet Chip never does.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone
file
(.exe) so I am not dependent to what the user have installed
of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate
to
VSTO. I have some questions about that, in order of
importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone
file
(.exe) so I am not dependent to what the user have installed
of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the
problem,
but then I have to maintain at least 3 versions (2000, XP
and
2003). Even subversions (Service Packs and minor upgrades
cause
those commilation problems so I cannot keep that much
versions).

I meant of code Chip, not Excel <g

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
versions. I don't have 3 versions, and I bet Chip never does.

I have 5 versions of Excel on my main box.



"Bob Phillips" wrote in
message ...
But going back to your VBA problem, if you develop on your
lowest deployment
version of Excel, that should work on all later versions. No
need for 3
versions. I don't have 3 versions, and I bet Chip never does.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone
file
(.exe) so I am not dependent to what the user have installed
of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate
to
VSTO. I have some questions about that, in order of
importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone
file
(.exe) so I am not dependent to what the user have installed
of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the
problem,
but then I have to maintain at least 3 versions (2000, XP
and
2003). Even subversions (Service Packs and minor upgrades
cause
those commilation problems so I cannot keep that much
versions).

Hi Bob,

I try it out! You mean I should develop in office 2000 then...

I always did in XP, but maybe I did an upgrade and then it didn't work
anymore. It is also rare that my code of XP also crashes on office 2003!

Thanks
Jos

"Bob Phillips" schreef in bericht
...
But going back to your VBA problem, if you develop on your lowest
deployment
version of Excel, that should work on all later versions. No need for 3
versions. I don't have 3 versions, and I bet Chip never does.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to
VSTO. I have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the problem,
but then I have to maintain at least 3 versions (2000, XP and
2003). Even subversions (Service Packs and minor upgrades cause
those commilation problems so I cannot keep that much
versions).

Hi Chip,

I mean, I developped in VBA, and I don't want to spend to much time to set
my code in vb.net. Is the language comparable or do I have to learn a lot
(and debug a lot) to get my code back in vb?

I never used VB.NET! I assume you mean I cannot copy and paste my code from
vba to vb.net.

Jos

"Chip Pearson" schreef in bericht
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file (.exe) so
I am not dependent to what the user have installed of dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with 2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to VSTO. I
have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new platform
2. Can I compile the project to an executable stand-alone file (.exe) so
I am not dependent to what the user have installed of dll's
3. Does it work with all versions of Office (starting with 2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll (mso9.dll for
office 2000) of the different office versions, which causes a crash on
startup when I build up my menu-bar. Recompilation on the specific excel
version solves the problem, but then I have to maintain at least 3
versions (2000, XP and 2003). Even subversions (Service Packs and minor
upgrades cause those commilation problems so I cannot keep that much
versions).

You'll find the syntax of VB.NET familiar if you know VBA, but
VB.NET is vastly larger and more complicated than VBA. Some code
will copy/paste, but most will require some degree of rewrite.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com




"Jos Vens" wrote in message
...
Hi Chip,

I mean, I developped in VBA, and I don't want to spend to much
time to set my code in vb.net. Is the language comparable or do
I have to learn a lot (and debug a lot) to get my code back in
vb?

I never used VB.NET! I assume you mean I cannot copy and paste
my code from vba to vb.net.

Jos

"Chip Pearson" schreef in bericht
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone
file (.exe) so I am not dependent to what the user have
installed of dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate
to VSTO. I have some questions about that, in order of
importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone
file (.exe) so I am not dependent to what the user have
installed of dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the
problem, but then I have to maintain at least 3 versions
(2000, XP and 2003). Even subversions (Service Packs and
minor upgrades cause those commilation problems so I cannot
keep that much versions).

Exactly Jos, that is what I mean.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Jos Vens" wrote in message
...
Hi Bob,

I try it out! You mean I should develop in office 2000 then...

I always did in XP, but maybe I did an upgrade and then it didn't work
anymore. It is also rare that my code of XP also crashes on office 2003!

Thanks
Jos

"Bob Phillips" schreef in bericht
...
But going back to your VBA problem, if you develop on your lowest
deployment
version of Excel, that should work on all later versions. No need for 3
versions. I don't have 3 versions, and I bet Chip never does.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Chip Pearson" wrote in message
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new
platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with
2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to
VSTO. I have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new
platform
2. Can I compile the project to an executable stand-alone file
(.exe) so I am not dependent to what the user have installed of
dll's
3. Does it work with all versions of Office (starting with
2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll
(mso9.dll for office 2000) of the different office versions,
which causes a crash on startup when I build up my menu-bar.
Recompilation on the specific excel version solves the problem,
but then I have to maintain at least 3 versions (2000, XP and
2003). Even subversions (Service Packs and minor upgrades cause
those commilation problems so I cannot keep that much
versions).

If you are deploying to Excel 2000 and Xp as well as 2003, VB.Net isn't
really an option anyway.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Jos Vens" wrote in message
...
Hi Chip,

I mean, I developped in VBA, and I don't want to spend to much time to set
my code in vb.net. Is the language comparable or do I have to learn a lot
(and debug a lot) to get my code back in vb?

I never used VB.NET! I assume you mean I cannot copy and paste my code
from
vba to vb.net.

Jos

"Chip Pearson" schreef in bericht
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file (.exe)
so
I am not dependent to what the user have installed of dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with 2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to VSTO. I
have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new platform
2. Can I compile the project to an executable stand-alone file (.exe)
so
I am not dependent to what the user have installed of dll's
3. Does it work with all versions of Office (starting with 2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll (mso9.dll for
office 2000) of the different office versions, which causes a crash on
startup when I build up my menu-bar. Recompilation on the specific
excel
version solves the problem, but then I have to maintain at least 3
versions (2000, XP and 2003). Even subversions (Service Packs and minor
upgrades cause those commilation problems so I cannot keep that much
versions).

I know,

but if VSTO is stable, I can convince my customers to migrate to 2003, now
it's a mess: my excel application crashes on almost every machine, unless it
is upgraded to the right version (like for XP is it 10.6789.6735 SP3). All
other versions are crashing, unless I recompile. I've built a compiler (I
use the sendkeys method to unlock the project etc etc... It worked, but on
2003 I couldn't save it anymore - an error on saving appeared for an unknown
reason).

Thanks for all your suggestions!
Jos Vens



"Bob Phillips" schreef in bericht
...
If you are deploying to Excel 2000 and Xp as well as 2003, VB.Net isn't
really an option anyway.

--
HTH

Bob Phillips

(remove nothere from email address if mailing direct)

"Jos Vens" wrote in message
...
Hi Chip,

I mean, I developped in VBA, and I don't want to spend to much time to
set
my code in vb.net. Is the language comparable or do I have to learn a lot
(and debug a lot) to get my code back in vb?

I never used VB.NET! I assume you mean I cannot copy and paste my code
from
vba to vb.net.

Jos

"Chip Pearson" schreef in bericht
...
Assuming you know VB.NET,

1. Is my code in VBA in a high level portable to the new platform

Only you can answer that question.

2. Can I compile the project to an executable stand-alone file (.exe)
so
I am not dependent to what the user have installed of dll's

With VTSO, you end up with a workbook and a managed code DLL.

3. Does it work with all versions of Office (starting with 2000)

No. 2003 only.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com



"Jos Vens" wrote in message
...
Hi,

since I have serious problems in VBA, I consider to migrate to VSTO. I
have some questions about that, in order of importance:

1. Is my code in VBA in a high level portable to the new platform
2. Can I compile the project to an executable stand-alone file (.exe)
so
I am not dependent to what the user have installed of dll's
3. Does it work with all versions of Office (starting with 2000)

Thanks for your help.
Jos Vens

PS my big problem in VBA is the difference of the mso.dll (mso9.dll
for
office 2000) of the different office versions, which causes a crash on
startup when I build up my menu-bar. Recompilation on the specific
excel
version solves the problem, but then I have to maintain at least 3
versions (2000, XP and 2003). Even subversions (Service Packs and
minor
upgrades cause those commilation problems so I cannot keep that much
versions).

Smiss wrote:

... there is no benefit (bit slower in fact) normally of declaring
integer compared
to longs ...

I support the idea of going *Long* rather than* Integer* in al
situations. But is it really true that Integer is slower than Long
I'd had always thought the opposite plus the fact that Integer use
less memory resources than Long or Double.

Just curious.


Myle

--
Myle
-----------------------------------------------------------------------
Myles's Profile: http://www.excelforum.com/member.php...fo&userid=2874
View this thread: http://www.excelforum.com/showthread.php?threadid=52884

I believe the thought is that
In 32 bit versions of windows, Long is the default length - so it takes
extra code to work with integers and doesn't save any memory since the
variables are not bitpacked.

--
Regards,
Tom Ogilvy


"Myles" wrote in
message ...

Smiss wrote:

.. there is no benefit (bit slower in fact) normally of declaring
integer compared
to longs ...

I support the idea of going *Long* rather than* Integer* in all
situations. But is it really true that Integer is slower than Long?
I'd had always thought the opposite plus the fact that Integer uses
less memory resources than Long or Double.

Just curious.


Myles


--
Myles
------------------------------------------------------------------------
Myles's Profile:
http://www.excelforum.com/member.php...o&userid=28746
View this thread: http://www.excelforum.com/showthread...hreadid=528846

I did re-compile.
File was 5 Mb after compile and save and went down to 2.5 Mb after
running WB Rebuilder.
I always compile before save, just to make sure there are no errors. I
think most people on this NG will do the same.
It would be no trouble to pass you the code and I will do that tonight
after work.

RBS

Hi Bart,

I did a time-check and compiled or not, the program starts equally fast. I
have also the habbit to compile. I think when I distribute, I will run WB
Rebuilder and do no recompilation.
If you want to send code directly: (the
newsgroup-emailaddress was my old one and does not exist anymore).

Your a great person!
Jos


schreef in bericht
oups.com...
I did re-compile.
File was 5 Mb after compile and save and went down to 2.5 Mb after
running WB Rebuilder.
I always compile before save, just to make sure there are no errors. I
think most people on this NG will do the same.
It would be no trouble to pass you the code and I will do that tonight
after work.

RBS