OK. I think i know someone with VS6... going to attempt to convert VBA to a VB project (VB 6 for ease). I have some basic questions to ask please:

1. The current system has code across a number of modules etc - do i just paste all the code into a single text file to import into studio & then correct it's references / syntax, or will there be a clever "import VBA" option in studio ?
2. The Excel functions used in the workbook - are they included / similar in VB 6 ie can this code run WITHOUT Excel present on the system - or are the advanced filters etc etc functions only part of Excel ? If the latter, are there any developer code etc that can be used with permission etc to create a standalone app ?

These 2 questions will help shape the path - and in about 3 years i'll have i done !!!
thanks again.

Mike,

for 1., there is no "best practice" I guess. Whether you need one or more
modules is just a matter of organisation. It doesn't change the behaviour of
the program at all.
For 2., the functions of Excel are not included since Excel is a separate
program. However, you may use Excel from VB using automation. That is,
creating a reference to Excel in VB and refer to its objects, methods and
properties. But Excel still has to be on the target machine.

Hope this helps you getting started.

Stefan

"Mike Iacovou" schrieb im
Newsbeitrag ...
OK. I think i know someone with VS6... going to attempt to convert VBA to
a VB project (VB 6 for ease). I have some basic questions to ask please:

1. The current system has code across a number of modules etc - do i just
paste all the code into a single text file to import into studio & then
correct it's references / syntax, or will there be a clever "import VBA"
option in studio ?
2. The Excel functions used in the workbook - are they included / similar
in VB 6 ie can this code run WITHOUT Excel present on the system - or are
the advanced filters etc etc functions only part of Excel ? If the latter,
are there any developer code etc that can be used with permission etc to
create a standalone app ?

These 2 questions will help shape the path - and in about 3 years i'll
have i done !!!
thanks again.

Hi Mike

You can rightclick an Excel module in the project explorer, then choose
"export file". This generates a .bas file (which is nothing but a text file
really) that you can import into VB6. But since you'll have to fine tune
each single line of code anyway, I prefer to copy-paste macro by macro, or
related groups of macros/functions, and make them work before pasting the
next one.

You should be able to find or write functions to replace the simpler
spreadsheet functions. The complex ones are worse. All will definitely be
far slower than Excel's built-in. So functions will need considerations one
by one. If this is a huge or commercial project you should consider
purchasing a spreadsheet control. It will be expensive and save you tons of
work. Try
http://www.componentsource.com/Catal...et&go= Search

HTH. Best wishes Harald


"Mike Iacovou" skrev i melding
...
OK. I think i know someone with VS6... going to attempt to convert VBA to
a VB project (VB 6 for ease). I have some basic questions to ask please:

1. The current system has code across a number of modules etc - do i just
paste all the code into a single text file to import into studio & then
correct it's references / syntax, or will there be a clever "import VBA"
option in studio ?
2. The Excel functions used in the workbook - are they included / similar
in VB 6 ie can this code run WITHOUT Excel present on the system - or are
the advanced filters etc etc functions only part of Excel ? If the latter,
are there any developer code etc that can be used with permission etc to
create a standalone app ?

These 2 questions will help shape the path - and in about 3 years i'll
have i done !!!
thanks again.

Mike,

In principle the automation works, although it will only work to the level
of functionality supported by Excel 97.

--
HTH

-------

Bob Phillips
"Mike Iacovou" wrote in message
...
Will automating an excel object from VB work with office 97 (i know 2000+
should be ok)?
I think considering i have never tried, the best i can hope to do is
automate excel by correctly declaring variables / referncing functions etc
etc. I guess i will follow that route.
any further tips / resources greatly appreciated. thanks for your replies.

"Mike Iacovou" skrev i melding
...
Will automating an excel object from VB work with office 97 (i know 2000+
should be ok)?
I think considering i have never tried, the best i can hope to do is
automate excel by correctly declaring variables / referncing functions etc
etc. I guess i will follow that route.
any further tips / resources greatly appreciated. thanks for your replies.

Yes, it will work. But beware, references in early binding will not
"downgrade". See
http://www.erlandsendata.no/english/...baoleolebasics
on early binding/late binding.

I fail to see the reason for creating a standalone app if it needs Microsoft
Office to run anyway. VBA and VB6 is really the very same thing and
therefore equally powerful. (But that's really none of my business, sorry
;-)

Best wishes Harald

I fail to see the reason for creating a standalone app if
it needs Microsoft Office to run anyway. VBA and VB6 is
really the very same thing and therefore equally
powerful. (But that's really none of my business, sorry
;-)

Best wishes Harald

One reason is for improved security. Something I'm looking
into now, which is daunting. I'd rather commission someone
to help do it properly - seriously!

Regards,
Peter

Many thanks for replies.
It is only for security reasons alone - hence the other topic regarding encryption of VBA...
thanks again. rock & a hard place springs to mind ;)

"Mike Iacovou" skrev i melding
...
Many thanks for replies.
It is only for security reasons alone - hence the other topic regarding
encryption of VBA...
thanks again. rock & a hard place springs to mind ;)

Yeah yeah someone might actually read my work...

If the operations conducted are too Secret to be known by Anyone Else then
make it entirely compiled standalone, don't depend on Office or any other
environmental thing. Office is not safe in the Safe meaning of the word,
it's fantastic for many things but not that. And also, take care, don't type
text constants in your code, they are readable in the raw compiled exe file
with a hex editor.

If however Security means Protecting My Own Great Code from prying eyes, ...
well, it has to be nothing but brilliant to be worth that extra effort.
Apologies for questioning this, but I've seen too many things protected
because of embarrassment or of hubris. Your/my/anyone's work is almost never
more valuable than what you will find in a free Google search, and if it is,
it's probably too specialized to have any value to the average Joe.

Best wishes Harald

You are absolutely right Harald, and I use many free pieces of software that
are better than anything I can write, but it is understandable for instance
why a software product might have a time limited evaluation period, just to
stop it being ripped off.

Bob

"Harald Staff" wrote in message
...
"Mike Iacovou" skrev i melding
...
Many thanks for replies.
It is only for security reasons alone - hence the other topic regarding
encryption of VBA...
thanks again. rock & a hard place springs to mind ;)

Yeah yeah someone might actually read my work...

If the operations conducted are too Secret to be known by Anyone Else then
make it entirely compiled standalone, don't depend on Office or any other
environmental thing. Office is not safe in the Safe meaning of the word,
it's fantastic for many things but not that. And also, take care, don't
type
text constants in your code, they are readable in the raw compiled exe
file
with a hex editor.

If however Security means Protecting My Own Great Code from prying eyes,
....
well, it has to be nothing but brilliant to be worth that extra effort.
Apologies for questioning this, but I've seen too many things protected
because of embarrassment or of hubris. Your/my/anyone's work is almost
never
more valuable than what you will find in a free Google search, and if it
is,
it's probably too specialized to have any value to the average Joe.

Best wishes Harald

you are all right. protection in this case isn't so much for the code itself (indeed many samples of the code are modified from that found here / google etc etc), but it is more an attempt to protect the idea of how to reach an end. At the end of the day, if someone wants at the code, they will get at it whether it is encrypted etc or not... if it is worth the effort. You can "copyright" code to a point / code is intellectual property the moment it exists with your name to it, but ideas cannot be protected... and "method" doesn't usually apply to programming - but it is this that sets one VBA project apart from another with similar code snippets. A project that produces results that are not achievable by any other means at the current time is worth protecting - until alternatives are developed... for once it would be nice if the "little guy" could keep some control.
i really appreciate all of your comments & time. Many many thanks.

Harold's comments need careful consideration in view of
the learning curve into vb and, from what I gather, some
4x longer to write and test.

But I'm with you, Mike, on this for all the reasons you
outlined. Slightly off topic but you mentioned copyright.
Unfortunately there's an enormous gulf between the
protection afforded in theory and what can in practice be
enforced. In rare examples if:
a) the issue is absolutely blatant,
b) you can identify the infringer,
c) you can demonstrate a material loss,
d) you have superior clout, financial or other (eg this ng)
e) he/she/entity has at least some decency
then you stand a chance. There's a successful illustration
here (you might spot a comment I threw in that
demonstrates my feelings on the subject):

http://tinyurl.com/6m839

Whatever, vba vs vb is the difference between putting up a
no entry sign and a small bolt on the door. But it's a
long trip to the hardware store to get this bolt!

Regards,
Peter


-----Original Message-----
you are all right. protection in this case isn't so much
for the code itself (indeed many samples of the code are
modified from that found here / google etc etc), but it is
more an attempt to protect the idea of how to reach an
end. At the end of the day, if someone wants at the code,
they will get at it whether it is encrypted etc or not...
if it is worth the effort. You can "copyright" code to a
point / code is intellectual property the moment it exists
with your name to it, but ideas cannot be protected...
and "method" doesn't usually apply to programming - but it
is this that sets one VBA project apart from another with
similar code snippets. A project that produces results
that are not achievable by any other means at the current
time is worth protecting - until alternatives are
developed... for once it would be nice if the "little guy"
could keep some control.

i really appreciate all of your comments & time. Many
many thanks.
.