M
mcp6453
If you were to start learning Word VBA today, what book would you buy?
M
Malcolm Smith
Frankly I wouldn't. Well, not on VBA as there isn't one that I like.
After a while I would get Ken Getz' "VBA" which is advanced work and is
published by Sybex.
Depending on how much programming knowledge I would offer different
answers. But, basically the issue isn't learning to know how to program
in VBA for a lot of people but learning to program first.
For beginners I would tell them to locate a fine VB book. For those who
have done some programming I would tell them to pick up a free C compiler
and the excellent 'Kerninghan and Ritchie' book on C.
Why? Simply that the VB/VBA successfully hides the operation of pointers
from the programmer. And I feel strongly that for the programmer to
understand what's going on behind those Set statements in VB/VBA a little
messing about with pointers is essential.
Other than that. Stick with this newsgroup and the others with 'vba' in
the tite. Try to answer every question in your head and learn from the
answers.
Have a look at the MVP site, have a look at my meagre site at the code
examples.
I think that these are miles better than any book. Even if there were a
book which I would or could recommend.
Hope that this helps
Malc
www.dragondrop.com
After a while I would get Ken Getz' "VBA" which is advanced work and is
published by Sybex.
Depending on how much programming knowledge I would offer different
answers. But, basically the issue isn't learning to know how to program
in VBA for a lot of people but learning to program first.
For beginners I would tell them to locate a fine VB book. For those who
have done some programming I would tell them to pick up a free C compiler
and the excellent 'Kerninghan and Ritchie' book on C.
Why? Simply that the VB/VBA successfully hides the operation of pointers
from the programmer. And I feel strongly that for the programmer to
understand what's going on behind those Set statements in VB/VBA a little
messing about with pointers is essential.
Other than that. Stick with this newsgroup and the others with 'vba' in
the tite. Try to answer every question in your head and learn from the
answers.
Have a look at the MVP site, have a look at my meagre site at the code
examples.
I think that these are miles better than any book. Even if there were a
book which I would or could recommend.
Hope that this helps
Malc
www.dragondrop.com
M
MARY MCRAE
The only useful book I've found that deals specifically with the Word Object
Model is "Word Macros: Learning to Program the Word object Model Using VBA"
by Steven Roman and published by O'Reilly. I have another O'Reilly book on
VB & VBA In a Nutshell; I have to say it really isn't very helpful for
learning but supplements the other book.
Model is "Word Macros: Learning to Program the Word object Model Using VBA"
by Steven Roman and published by O'Reilly. I have another O'Reilly book on
VB & VBA In a Nutshell; I have to say it really isn't very helpful for
learning but supplements the other book.
L
Lars-Eric Gisslén
Malcolm,
Do you want to make the life even harder for those guys?
I've entered the VB world from the other direction. I'm not new to low level
programming (even done Assembler, but long time ago now) and I still find it
hard to understand what's going on inside VB. Seems there is to much hokus
pokus going on inside VB and therefor I'm not to fond of it. It just doesn't
give me the control I want to feel comfortable. But I must say that the
combination VBA and Office is very powerful.
But VB do have a very strong side; COM.
Regards,
Lars-Eric
Do you want to make the life even harder for those guys?
I've entered the VB world from the other direction. I'm not new to low level
programming (even done Assembler, but long time ago now) and I still find it
hard to understand what's going on inside VB. Seems there is to much hokus
pokus going on inside VB and therefor I'm not to fond of it. It just doesn't
give me the control I want to feel comfortable. But I must say that the
combination VBA and Office is very powerful.
But VB do have a very strong side; COM.
Regards,
Lars-Eric
M
Malcolm Smith
I see it as essential background knowledge. If one knows and understands
pointers then handling the pointers to objects makes a lot more sense.
I think that knowing the difference between the object and the pointer to
an object is of massive importance.
My own views, of course.
Malc
www.dragondrop.com
pointers then handling the pointers to objects makes a lot more sense.
I think that knowing the difference between the object and the pointer to
an object is of massive importance.
My own views, of course.
Malc
www.dragondrop.com
L
Lars-Eric Gisslén
Malcolm,
It never hurts to understand what's going on. At least you should be able to
tell the difference between plain memory pointers and interface pointers to
Objects if you study some C code. But going deeper to VTable binding or to
the IDispatch interface and the Invoke method would be going to deep for a
general VBA user, in my oppinion.
Regards,
Lars-Eric
It never hurts to understand what's going on. At least you should be able to
tell the difference between plain memory pointers and interface pointers to
Objects if you study some C code. But going deeper to VTable binding or to
the IDispatch interface and the Invoke method would be going to deep for a
general VBA user, in my oppinion.
Regards,
Lars-Eric
M
Mark Tangard
Malc & Lars,
I still wonder how advisable it is to introduce the notion
of a pointer to total programming newbies looking to learn
VBA, since the word is virtually never used in any of the
MS documentation, or in most third-party books I've seen.
And especially considering how profoundly strange much VBA
terminology is to start with, eh...?
I still wonder how advisable it is to introduce the notion
of a pointer to total programming newbies looking to learn
VBA, since the word is virtually never used in any of the
MS documentation, or in most third-party books I've seen.
And especially considering how profoundly strange much VBA
terminology is to start with, eh...?
M
Malcolm Smith
Mark
This is my point. MS have disguised what's going on but it does help to
know what a pointer is and why, in a recent posting, I was able to do
stuff like:
dim oControl as Control
dim oTextBox as TextBox
if TypeOf(oControl) is MsForms.TextBox then
Set oTextBox = oControl
Well, I merged a bit of a MVP's code for the If() statement there, but the
point is I am setting a oTextBox variable.
Now, to someone who isn't familiar to the concept of pointers they may
think that I am actually creating a TextBox control and working with that
when, in fact I am not.
When I have taught people about pointers and things, and no I don't go
into the VTable, honest Lars, then they have been able to wander off any
play about making linked lists, binary trees and the like. Sure most of
it is for fun but it does widen one's horizons.
Anyway, I am a strong believer that one should understand the difference
between an object and pointer. In VB/VBA we tend to deal with the
pointers all the time whereas in C we can play with the objects themselves
as well as the pointers. We don't need to go that far down but the having
the user understand that they can share objects with pointers and swap
pointers about the place and what goes on would help immensely with their
knowledge.
Of course I could be utterly and totally wrong but this is a strong
opinion of mine. Learn how something works a little deeper than what's on
the surface and one can understand more. Gosh, that sounds a little New
Age, doesn't it? Better go out and hug a tree or something then!
Cheers from a sunny North Wales (honest!)
Malc
www.dragondrop.com
This is my point. MS have disguised what's going on but it does help to
know what a pointer is and why, in a recent posting, I was able to do
stuff like:
dim oControl as Control
dim oTextBox as TextBox
if TypeOf(oControl) is MsForms.TextBox then
Set oTextBox = oControl
Well, I merged a bit of a MVP's code for the If() statement there, but the
point is I am setting a oTextBox variable.
Now, to someone who isn't familiar to the concept of pointers they may
think that I am actually creating a TextBox control and working with that
when, in fact I am not.
When I have taught people about pointers and things, and no I don't go
into the VTable, honest Lars, then they have been able to wander off any
play about making linked lists, binary trees and the like. Sure most of
it is for fun but it does widen one's horizons.
Anyway, I am a strong believer that one should understand the difference
between an object and pointer. In VB/VBA we tend to deal with the
pointers all the time whereas in C we can play with the objects themselves
as well as the pointers. We don't need to go that far down but the having
the user understand that they can share objects with pointers and swap
pointers about the place and what goes on would help immensely with their
knowledge.
Of course I could be utterly and totally wrong but this is a strong
opinion of mine. Learn how something works a little deeper than what's on
the surface and one can understand more. Gosh, that sounds a little New
Age, doesn't it? Better go out and hug a tree or something then!
Cheers from a sunny North Wales (honest!)
Malc
www.dragondrop.com
J
Jonathan West
Hi Mark,
I rather agree with you. Pointers are not used within VBA at all, unless you
get involved in advanced Windows API hackery.
Also, pointers have nothing at all to do with object-oriented languages and
programming. In fact OOP was intended in part to be able to got you away
from the dangers of using pointers...
The thing that really needs to be understood effecrively is the distinction
between an object and one or more instances of that object.
In some ways, an instance and a pointer have some similarities, but they
have this key difference. A pointer has a numerical value (usually though
not necessarily representing a memory address), and that numerical value can
be manipulated to change what the pointer is pointing to. The technique of
messing around with pointers is simultaneously very powerful and extremely
dangerous. Instances don't have a numerical value, they just "are". So they
are safer, and their power is expressed differently.
Getting pointers and instances mixed up can get people very confused about
OOP.
--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
I rather agree with you. Pointers are not used within VBA at all, unless you
get involved in advanced Windows API hackery.
Also, pointers have nothing at all to do with object-oriented languages and
programming. In fact OOP was intended in part to be able to got you away
from the dangers of using pointers...
The thing that really needs to be understood effecrively is the distinction
between an object and one or more instances of that object.
In some ways, an instance and a pointer have some similarities, but they
have this key difference. A pointer has a numerical value (usually though
not necessarily representing a memory address), and that numerical value can
be manipulated to change what the pointer is pointing to. The technique of
messing around with pointers is simultaneously very powerful and extremely
dangerous. Instances don't have a numerical value, they just "are". So they
are safer, and their power is expressed differently.
Getting pointers and instances mixed up can get people very confused about
OOP.
--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
L
Lars-Eric Gisslén
Jonathan,
To make life harder when talking about OOP, you must then also distinguage
between COM interface pointers and pointers to native objects in true OOP
languages like C++ and Visual Objects (using basically the same class
structure). Pointers are sometimes used even in OOP, mostly when you cast
a pointer to an object and is very common when binding to VTables in COM
interfaces. Also in WindowProcedures you may need to get the object pointer
by the Window handle and cast it to a new object so you can call the objects
methods.
In my oppinion neither VB nor VBA is designed to work with pointers and
should therefor be avoided, unless neccesary in API calls. As VB does not
have any Pointer (or Typed Pointer) data types there is no way for the
compiler to check your code for faulty use of 'pointer'/Long data types.
Even in system development pointers should be used with care. I've seen
several systems just blow up because of incorrect use of pointers so I don't
really think they belong in the VBA world.
Regards,
Lars-Eric
To make life harder when talking about OOP, you must then also distinguage
between COM interface pointers and pointers to native objects in true OOP
languages like C++ and Visual Objects (using basically the same class
structure). Pointers are sometimes used even in OOP, mostly when you cast
a pointer to an object and is very common when binding to VTables in COM
interfaces. Also in WindowProcedures you may need to get the object pointer
by the Window handle and cast it to a new object so you can call the objects
methods.
In my oppinion neither VB nor VBA is designed to work with pointers and
should therefor be avoided, unless neccesary in API calls. As VB does not
have any Pointer (or Typed Pointer) data types there is no way for the
compiler to check your code for faulty use of 'pointer'/Long data types.
Even in system development pointers should be used with care. I've seen
several systems just blow up because of incorrect use of pointers so I don't
really think they belong in the VBA world.
Regards,
Lars-Eric
J
Jonathan West
I think we are singing from the same hymn sheet
--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
M
Malcolm Smith
Jonathon
The Set statement is something that works on a pointer and not an object.
One can't see the object at all. The indirection is done for you so
people can get puzzled by this.
Again look at the code example:
Dim oControl as Control
Dim oTextBox as TextBox
Set oControl = Me.Controls("txtThisIsATextBoxBecauseIKnowItIs")
Set oTextBox = oControl
In this example there is one control, object if you like, on the user form
(dialog box).
So what happens here? Well oControl points to it and then in the next
line oTextBox also points to it. Note that I am not creating a new
object nor a new instance; I am just creating a new pointer to the
instance. We have now two pointers pointing to the same object and NOT
two instances.
This is why VBA is full of pointers and very few people realise it.
If there were no pointers then people wouldn't be able to make linked
lists and the like. Go on; I challenge you -- make a set of routines that
create a linked list; you know add a node somewhere to the list, remove a
node from the list and so on. I've done it many a time; and then tell me
how it's possible without pointers because I would love to know.
And, no, I am not going in the depths of the API hoola-hoops; but just
using plain VBA as it comes out of the tin.
Anyway, in a nutshell; whenever you play with a Set statement you are
playing with a pointer. It is the object that one doesn't know where it
is unless you want to start to look at memory locations of the things.
So, I think that you're the other way about here and, again, this
difference is important because when one knows what is an object and what
is a pointer then one's horizons wider.
Regards
Malc
www.dragondrop.com
The Set statement is something that works on a pointer and not an object.
One can't see the object at all. The indirection is done for you so
people can get puzzled by this.
Again look at the code example:
Dim oControl as Control
Dim oTextBox as TextBox
Set oControl = Me.Controls("txtThisIsATextBoxBecauseIKnowItIs")
Set oTextBox = oControl
In this example there is one control, object if you like, on the user form
(dialog box).
So what happens here? Well oControl points to it and then in the next
line oTextBox also points to it. Note that I am not creating a new
object nor a new instance; I am just creating a new pointer to the
instance. We have now two pointers pointing to the same object and NOT
two instances.
This is why VBA is full of pointers and very few people realise it.
If there were no pointers then people wouldn't be able to make linked
lists and the like. Go on; I challenge you -- make a set of routines that
create a linked list; you know add a node somewhere to the list, remove a
node from the list and so on. I've done it many a time; and then tell me
how it's possible without pointers because I would love to know.
And, no, I am not going in the depths of the API hoola-hoops; but just
using plain VBA as it comes out of the tin.
Anyway, in a nutshell; whenever you play with a Set statement you are
playing with a pointer. It is the object that one doesn't know where it
is unless you want to start to look at memory locations of the things.
So, I think that you're the other way about here and, again, this
difference is important because when one knows what is an object and what
is a pointer then one's horizons wider.
Regards
Malc
www.dragondrop.com
M
Malcolm Smith
Lars-Eric
Whether you think that they don't belong doesn't mean that they don't
exist. The problem of dereferencing messed up pointers (and I do
remember this from my C days) is removed here because MS have effectively
removed the indirection from us. They have given us the pointer and then,
with a slight of hand, a puff of smoke and a few mirrors (a bit like the
Wizard of Oz) have called it the object.
But it really isn't like that.
I am not talking about OOP or anything like that. Nor am I worried about
APIs (and thank God, I don't have to worry about pointers to strings any
more!).
Like I mentioned to Jonathon; if there are no pointers in VB/VBA then how
come one is able to create a simple linked list with a few types and the
Set statement?
Regards
Malc
www.dragondrop.com
Whether you think that they don't belong doesn't mean that they don't
exist. The problem of dereferencing messed up pointers (and I do
remember this from my C days) is removed here because MS have effectively
removed the indirection from us. They have given us the pointer and then,
with a slight of hand, a puff of smoke and a few mirrors (a bit like the
Wizard of Oz) have called it the object.
But it really isn't like that.
I am not talking about OOP or anything like that. Nor am I worried about
APIs (and thank God, I don't have to worry about pointers to strings any
more!).
Like I mentioned to Jonathon; if there are no pointers in VB/VBA then how
come one is able to create a simple linked list with a few types and the
Set statement?
Regards
Malc
www.dragondrop.com
J
Jonathan West
Malcolm Smith said:
We've been round this loop before, and the term for what you are describing
is an instance, not a pointer.
--
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
M
Malcolm Smith
I know we have.
An instance is exactly that; an instantiation of a class, i.e. an object.
The pointer points to the instance.
Anyway, take up my challenge. Write a simple linked list and then tell me
how it was done without pointers? How will one keep track of each
instance?
Cheers
Malc
An instance is exactly that; an instantiation of a class, i.e. an object.
The pointer points to the instance.
Anyway, take up my challenge. Write a simple linked list and then tell me
how it was done without pointers? How will one keep track of each
instance?
Cheers
Malc
R
Rob Strover
Mary,
I looked at Steve Roman's book, but decided not to buy it as I saw no
mention in either contents or index of events which I consider an important
aspect of VBA programming. I thought this a major failing. This was after
I had been programming in VB for many years (using versions 3 to 6), so that
may have some impact on my reaction to the book.
Most VBA texts seem to concentrate on the general aspects of the language,
not the object models exposed by the various VBA host applications (Word,
Excel, etc.) Given that I'd used many VBA type contructs within VB I was
really after info on object model issues and events generated by the host
application at various level (eg. Application and Document levels for Word).
This is why I looked at Roman's book, and as I said before came away
disapointed.
I've learnt an amazing amount just by 'listening' into the various
newsgroups of interest and seeing what the "wise ones" are talking about.
Also the 'Auto List Member' and 'Auto Quick Info' options in the VB Editor
make writing code far, far easier than any other way I've ever seen before.
Rob.
I looked at Steve Roman's book, but decided not to buy it as I saw no
mention in either contents or index of events which I consider an important
aspect of VBA programming. I thought this a major failing. This was after
I had been programming in VB for many years (using versions 3 to 6), so that
may have some impact on my reaction to the book.
Most VBA texts seem to concentrate on the general aspects of the language,
not the object models exposed by the various VBA host applications (Word,
Excel, etc.) Given that I'd used many VBA type contructs within VB I was
really after info on object model issues and events generated by the host
application at various level (eg. Application and Document levels for Word).
This is why I looked at Roman's book, and as I said before came away
disapointed.
I've learnt an amazing amount just by 'listening' into the various
newsgroups of interest and seeing what the "wise ones" are talking about.
Also the 'Auto List Member' and 'Auto Quick Info' options in the VB Editor
make writing code far, far easier than any other way I've ever seen before.
Rob.
L
Lars-Eric Gisslén
Malcolm,
VB/VBA uses pointers internally like any other programming languages,
otherwise you would not even be able to use variables. You should not even
be able to call functions with a total lack of pointers. What I mean is
that it's well hidden from you and pointer data types is not officially
supported in VB/VBA. However, I think the code below will describe what you
are saying.
For readers of this thread, the Ptr functions below is NOT supported by
Microsoft and should be avoided.
Sub PtrTest()
Dim c1 As Collection
Dim c2 As Collection
Dim n1 As Long
Dim n2 As Long
Set c1 = New Collection
Set c2 = c1
n1 = 1000
n2 = n1
If ObjPtr(c1) = ObjPtr(c2) Then
MsgBox "c1 and c2 points to the same Collection"
Else
MsgBox "c1 and c2 are two different Objects"
End If
If VarPtr(n1) = VarPtr(n2) Then
MsgBox "n1 and n2 points to the same memory location"
Else
MsgBox "c1 and c2 are two different variables"
End If
End Sub
Regards,
Lars-Eric
VB/VBA uses pointers internally like any other programming languages,
otherwise you would not even be able to use variables. You should not even
be able to call functions with a total lack of pointers. What I mean is
that it's well hidden from you and pointer data types is not officially
supported in VB/VBA. However, I think the code below will describe what you
are saying.
For readers of this thread, the Ptr functions below is NOT supported by
Microsoft and should be avoided.
Sub PtrTest()
Dim c1 As Collection
Dim c2 As Collection
Dim n1 As Long
Dim n2 As Long
Set c1 = New Collection
Set c2 = c1
n1 = 1000
n2 = n1
If ObjPtr(c1) = ObjPtr(c2) Then
MsgBox "c1 and c2 points to the same Collection"
Else
MsgBox "c1 and c2 are two different Objects"
End If
If VarPtr(n1) = VarPtr(n2) Then
MsgBox "n1 and n2 points to the same memory location"
Else
MsgBox "c1 and c2 are two different variables"
End If
End Sub
Regards,
Lars-Eric
K
Klaus Linke
Malcolm Smith said:I know we have.
An instance is exactly that; an instantiation of a class, i.e. an
object. The pointer points to the instance.
Anyway, take up my challenge. Write a simple linked list and
then tell me how it was done without pointers? How will one
keep track of each instance?
Hi Malc,
I haven't seen the previous discussion. In VB(A), I guess most people would
use the Collection object for linked lists.
No doubt, VBA uses pointers behind the scenes, but it is nothing the
programmer has to worry about.
Regards,
Klaus
M
Malcolm Smith
Lars
I can see you're just itching to put asterisks everywhere...
Indeed, that's a nice example there of fun things to do when one is bored.
Cheers
Malc
www.dragondrop.com
I can see you're just itching to put asterisks everywhere...
Indeed, that's a nice example there of fun things to do when one is bored.
Cheers
Malc
www.dragondrop.com
M
Malcolm Smith
Klaus
Agreed. The Collection basically supersedes the requirement to make a
linked list. However, there is nothing like being grateful for a
Collection than having to write one oneself.
Like when I went to college (it was a long time ago) and did my first year
Computer Science degree. I think that this was the first year ever of
this degree here in the UK and Hollerith punch cards were the input media
of choice at the time. Yes, we're in the seventies; flared jeans, long
hair and the like (well, nowt's changed here at Smith Towers).
Anyway, the college had a few punch-card typists who would transcribe our
coding sheets into punch cards. We were encouraged to make our own card
stack for one program just the once so that we could understand and
appreciate the pain that these ladies had.
But, coming back on track. If one writes a simple linked list then it
gives one a great understanding of pointers and objects. This is what I
would recommend to everyone to try at least once. The really brave (or
totally insane) could go further and try to write a binary tree.
These are totally valid structures and above else it really would give the
coder a massive understanding on what really happens just under the hood
of VB/VBA.
One day I may write something for my web site...
Pip Pip!
Malc
www.dragondrop.com
Agreed. The Collection basically supersedes the requirement to make a
linked list. However, there is nothing like being grateful for a
Collection than having to write one oneself.
Like when I went to college (it was a long time ago) and did my first year
Computer Science degree. I think that this was the first year ever of
this degree here in the UK and Hollerith punch cards were the input media
of choice at the time. Yes, we're in the seventies; flared jeans, long
hair and the like (well, nowt's changed here at Smith Towers).
Anyway, the college had a few punch-card typists who would transcribe our
coding sheets into punch cards. We were encouraged to make our own card
stack for one program just the once so that we could understand and
appreciate the pain that these ladies had.
But, coming back on track. If one writes a simple linked list then it
gives one a great understanding of pointers and objects. This is what I
would recommend to everyone to try at least once. The really brave (or
totally insane) could go further and try to write a binary tree.
These are totally valid structures and above else it really would give the
coder a massive understanding on what really happens just under the hood
of VB/VBA.
One day I may write something for my web site...
Pip Pip!
Malc
www.dragondrop.com