Request Guidance on Visual Basic Versions

[Dave]

From my first post on this group this morning I was impressed by the quality
and professional responses I received. I feel the knowledge is here to get
a good handle on this, a question on Visual Basic Versions and what
direction I should take. Some background is in order.

As an old IBM 360 o/s BAL programmer, and also a EXCP channel programmer
dealing with interrupt routines, my first experience with BASIC was on DEC
PDP 11/40 & 11/70 RSTS time sharing systems. I really liked what you could
do with the DEC BASIC and wrote a number of programs and developed video
support macros for the application programmers. Later in life, on Windows
based PC's, I got somewhat into writing a few M/S Word and Excel macros. I
really enjoyed Excel macros and wrote some fairly complex ones, however, I
never spent enough time to become really good at it. When Excel moved from
their macros to VBA I did a little conversion but not much.

One day I decided to spend money and bought M/S VB 4.0 and the manuals.
Wrote a couple of small test programs but not as much as I would have liked
to do. Then came along VB 6.0 SP6 Professional Edition which I purchased.
Again not much time to spend and before I knew it VB 2008 Express Edition
was available which I installed.

As you may imagine I have a few VB versions and manuals. I also have Office
2007, so considering Word & Excel support of VB, plus what is available at
present what should I be moving towards? I'm wondering if I should rat hole
everything except VB 2008 Express? How does this relate to Visual Studio?
Small Basic? I hope to spend more time on VB and would like to be able to
grow in VB capability in Word, Excel, and stand alone VB applications I may
write.

Hopeful someone can clear this up for me. Thanks in advance.

Dave

 

[RB Smissaert]

It all depends what your ultimate aim is.
My impression from what you posted there is that you are best of to stick to
VB6.

RBS

 

[RB Smissaert]

As I said, it all depends on the OP's ultimate aim.
If he is a hobby programmer and not aiming for a long career in programming
and if he is familiar already with VBA/VB6 then I think sticking with VB6
makes sense.

RBS

 

[Rick Rothstein]

I might question the "most people" part of your last sentence... it is my
understanding that there were far, far, far more VB programmers (upwards of
six million was the estimates that I had heard) than there currently are
VB.NET programmers. I'm not sure where they went (assuming they left in the
first place), but it appears VB.NET was not there final destination.

 

[Peter T]

And it is

easier in C to interface to the Windows Environment.

I agree VBA is not best suited to working with Windows where some sort of a
hook or sub-classing is required. However for interest, in which way would
you say C is "easier" to interface with the Windows Environment than VB6.

Regards,
Peter T

Maybe they moved from B to C. I don't think there is a single answer
why people move from one programming language to another programming
language and to which programming language they go to.

There is a large group of preple who where using VB6 to control test
equipment who moved onto Lab View. There are another group of people
who moved to the went version VB8 and then to VB8 replacement VB.net or
took a side step to C Language.

My preference is C languages (C++, or C#). The libraries in C have
developed a lot and now have a lot of the string manipulation features
that gave Basic some advantages. It is much easier in C Language with
its points to do a lot of tasks that you can't do it basic. An it is
easier in C to interface to the Windows Environment.


--
joel
------------------------------------------------------------------------
joel's Profile: 229
View this thread:
http://www.thecodecage.com/forumz/showthread.php?t=166356

Microsoft Office Help

 

[Peter T]

Afraid I don't follow that. "The dlls that require pointers" - do you mean
APIs, the arguments to many of which are actually pointers (declared as
Longs in x32 VBA/6), is there some problem with use of the CopyMemory API in
VBA/6.

Regards,
Peter T

 

[RB Smissaert]

The problem with copy memory when using Excel VBA is to copy a string

declared in VBA. Since you can't get the pointer to the string you have
to first
move the string into an array so you have a pointer.

I am no expert in this, but I have a feeling that this is not right. Have a
look here:
http://vb.mvps.org/tips/varptr.asp

RBS

I usually refere to API as Dll's since in VBA excel you need to declare
the dll library to use them. The problem with copy memory when using
Excel VBA is to copy a string declared in VBA. Since you can't get the
pointer to the string you have to first move the string into an array so
you have a pointer. the same thing applies with a number array. The
Dim arrays in VBA are not compatible with the CopyMemory so you first
have to move the data to a C-Language compatible array before you can
use copyMemory. I 'm usually using some other API and to be able to get
the data from Excel VBA in the format that the API is looking for I end
up using CopyMemory which adds an additional step. If I was using C
language I wouldn't need to go through a bunch of extra steps.


--
joel
------------------------------------------------------------------------
joel's Profile: 229
View this thread:
http://www.thecodecage.com/forumz/showthread.php?t=166356

Microsoft Office Help

 

[Peter T]

I completely misunderstood your orginal comments. As for CopyMemory and
string stuff, is this what you mean is easier in C

Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
(pDest As Any, pSource As Any, ByVal ByteLen As Long)

Sub test1()
Dim lenBytes As Long
Dim s1 As String, s2 As String
s1 = "Orginal string 123"
s2 = String$(Len(s1), 0)
lenBytes = Len(s1) * 2 ' bytes
CopyMemory ByVal StrPtr(s2), ByVal StrPtr(s1), lenBytes
s1 = "new string 456"

MsgBox s1 & vbCr & s2
End Sub

Alternatively, s2 = s1

Regards,
Peter T

 

[bart.smissaert]

Your code only works because of the StrPtr function which is not
documented in VBA.  And it is weird that you have to specify that Strptr
yo need to pass using Byval instead of the default ByRef.  I wouldn't
use Any as the variable type of the pointers instead I would use LONG
since a pointer is really a long in VBA.

The Strptr() function basically skips the header that VBA put infront
of a variable which contains the Variable type and number of characters.
If yo uwere using VB6 yo can specify the compiling option and use
C-Language variable passing instead of the Microsoft Standard variable
passing.

Again it is easier and clearer to write this code in C-language than in
VBA.

--
joel
------------------------------------------------------------------------
joel's Profile: 229
View this thread:http://www.thecodecage.com/forumz/showthread.php?t=166356

Microsoft Office Help

I use the Windows API a lot in VBA (and VB6) and never had any problem
at all, but
we are now completely off the original topic of this thread. I doubt
very much that learning
C is the answer to the OP's question.

RBS

 

[Peter T]

I don't know why StrPtr, VarPtr & ObjPtr are not documented, but there are
alternative APIs to get same. However these are used extensively by the VB
guys and often cited in MSDN examples albeit with the caveat.

ByVal & ByRef serve different purposes, in this context definitely wouldn't
want to pass a pointer to the pointer. No reason not to use 'As Any', the
pointer is a structure that merely looks like a Long in VB.

I'm not aware of the 'C-Language variable passing' compile option you
mentioned, in a quick look I don't see it.

I am sure you are right that some things are easier, if that's the right
word, in C if not more efficient too (notably xll for Excel UDFs). However
it is often surprising how highly optimized VB6 can perform as well as C
when making full use of memory swaps and the compile options disabled. As
for "easier", that predicates first learning C which for many is not as easy
as learning VBA/6.

Regards,
Peter T