Basic VB/Access2003 syntax, how to find out about it?

[usenet]

How and where can one find out about the basics of VB/Access2003
syntax?

I am a died in the wool C/C++/Java Linux/Unix programmer and I am
finding it difficult to understand the program format for accessing
objects, controls, etc. in VB/Access2003.

In particular where will I find explanations of:-

Actions, Functions, Methods, Properties - I'm understand the
concepts but I can't find anywhere that explains where each is
used, in my world a 'method' is simply a more modern name for a
'function'. Why are they all different?

The syntax for getting values of Properties and Objects, where []
are needed and where to use '.' and where to use '!'.

Where one can use 'me' and what it means.

Etc.!

None of this seems to be particularly easy to find in the Access help.
--
Chris Green

[Albert D. Kallal]

us****@isbd.co.uk> wrote in message news:44301b92.0@entanet...

How and where can one find out about the basics of VB/Access2003
syntax?

The access 2003 help is split into two parts..

#1 part - User part

This is the basic product called ms-access. How to add a record, how to
move...how to print a report. Since MANY people use ms-access WITHOUT
writing any code. This is the basic product.

So, if you launch ms-access, and then go help->Microsoft access help. This
is the general help. (part#1).

#2 part - programmers part.

However, if you flip into the code IDE, then you will receive VB help.

So, while in your application, hit ctrl-g (or alt-f11)

Now go help->Microsoft visual basic help.

Note the list nice list, and all of the methods, properties...events,
function list is all VERY nicely grouped. There is also a JET sql reference,
and a few other goodies....

Do note that while ms-access use the SAME coding syntax as VB6, the learning
curve in ms-access is STEEPER then that of VB6. This is because the objects
models in ms-access are far more complex that those in VB6.

For example, while most would use a flexgrid, or a listview activeX control
in most languages, if you take a look at the following screen shots, you can
do this native in ms-access without having to resort to activeX control..

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm
The best site for code examples, and virtually every coding task you might
every need can be found here....do take a browse
http://www.mvps.org/access/

Note the "forms", "reports" etc on the left side...they all have tons of VBA
code examples....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Lyle Fairfield]

Open a module.
Click on the object browser (a yellow box with floating othingmes
above, or press f2).
All will be revealed unto you.
Well, not quite all; right click in one of the windows; choose "Show
Hidden Members"; now all will be revealed unto you.

The help file is mostly just crap; a high percentage of it is wrong and
the rest is inefficient and/or ludicrous. Trust it as much as you would
the significant woman in your life.

[david epsom dot com dot au]

:~) 'dyed in the wool'

dye<>die

:~)

Actions, Functions, Methods, Properties
... Why are they all different?
None of those are fundamental BASIC concepts - they
have all been tacked on to serve market fashions. As
with any fashion trend, they look a bit strange when
viewed in retrospect.
The syntax for getting values of Properties and Objects, where []
are needed and where to use '.' and where to use '!'.
[] is used when you have a name with a space in it.

.. is for properties.
! is for members of collections!

'me' is the form object you are coding. you can use
it when you write code in a form object. It is implicit,
so it is never required. In Access, it is often used
for clarity, because there are often recordset field
objects that have the same names as controls on a form.

(david)

<us****@isbd.co.uk> wrote in message news:44301b92.0@entanet... How and where can one find out about the basics of VB/Access2003
syntax?

I am a died in the wool C/C++/Java Linux/Unix programmer and I am
finding it difficult to understand the program format for accessing
objects, controls, etc. in VB/Access2003.

In particular where will I find explanations of:-

Actions, Functions, Methods, Properties - I'm understand the
concepts but I can't find anywhere that explains where each is
used, in my world a 'method' is simply a more modern name for a
'function'. Why are they all different?

The syntax for getting values of Properties and Objects, where []
are needed and where to use '.' and where to use '!'.

Where one can use 'me' and what it means.

Etc.!

None of this seems to be particularly easy to find in the Access help.
--
Chris Green

[usenet]

Albert D. Kallal <ka****@msn.com> wrote:

us****@isbd.co.uk> wrote in message news:44301b92.0@entanet...

How and where can one find out about the basics of VB/Access2003
syntax?
The access 2003 help is split into two parts..

#1 part - User part

This is the basic product called ms-access. How to add a record, how to
move...how to print a report. Since MANY people use ms-access WITHOUT
writing any code. This is the basic product.

So, if you launch ms-access, and then go help->Microsoft access help. This
is the general help. (part#1).

#2 part - programmers part.

However, if you flip into the code IDE, then you will receive VB help.

Yes, OK, I've got there.
So, while in your application, hit ctrl-g (or alt-f11)
Though not by doing this, a helpful short cut, thanks.

Now go help->Microsoft visual basic help.

Note the list nice list, and all of the methods, properties...events,
function list is all VERY nicely grouped. There is also a JET sql reference,
and a few other goodies....
Yes, absolutely fine if I know the name of the method/function/action
I want - BUT I haven't yet found anything that gives me any help on
the detailed syntax or an overview of why there seem to be so many
different sorts of 'do something' operations.

Do note that while ms-access use the SAME coding syntax as VB6, the learning
curve in ms-access is STEEPER then that of VB6. This is because the objects
models in ms-access are far more complex that those in VB6.
I don't have a big problem with the object hierarchy, it's the sort of
thing I'm already fairly familiar with. As I said it's the detailed
sysntax and what sort of 'things' to use where that confuses me.

For example, while most would use a flexgrid, or a listview activeX control
in most languages, if you take a look at the following screen shots, you can
do this native in ms-access without having to resort to activeX control..
This is where you (and I suspect the help system) loses me.
'flexgrid' and 'activeX' mean absolutely nothing to me.

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm
The best site for code examples, and virtually every coding task you might
every need can be found here....do take a browse
http://www.mvps.org/access/
That looks a useful site. It does however worry me somewhat how much
of the information is the sort of stuff I would expect to be able to
find written down concisely in a language definition somewhere.

Note the "forms", "reports" etc on the left side...they all have tons of VBA
code examples....

Yes, I took a brief look down there, some of the examples should be
very useful, thanks.

--
Chris Green

[usenet]

Lyle Fairfield <ly***********@aim.com> wrote:

Open a module.
Click on the object browser (a yellow box with floating othingmes
above, or press f2).
All will be revealed unto you.
Well, not quite all; right click in one of the windows; choose "Show
Hidden Members"; now all will be revealed unto you.
Except the syntax I'm after, and also the necessity of knowing where
to look for something before you start. But, yes, that is useful,
thanks!

The help file is mostly just crap; a high percentage of it is wrong and
the rest is inefficient and/or ludicrous. Trust it as much as you would
the significant woman in your life.

The "significant woman" in my life is somewhat more reliable than
yours apparently! :-)

--
Chris Green

[Albert D. Kallal]

> Yes, absolutely fine if I know the name of the method/function/action

I want - BUT I haven't yet found anything that gives me any help on
the detailed syntax or an overview of why there seem to be so many
different sorts of 'do something' operations.
Well, I can't think of ANY help system that will explain the use of
pointers, or overloading in c++ either. Either you will have to get a book,
or learn some things over time. So, when learning a new system, connecting
the dots is hard. The docmd for example simply executes a method of the
ms-access appcation. So, in help...if you view any of the methods, you would
be browsing the list of docmd possible options.
I don't have a big problem with the object hierarchy, it's the sort of
thing I'm already fairly familiar with. As I said it's the detailed
sysntax and what sort of 'things' to use where that confuses me.
Learning to use what things where is certainly the issue. While some help
system actually might explain c++ pointers, I would be REALLY surprised if
the help system told you WHEN to use pointers. (that would be a amazing help
system!!). Again, I can't think of any c++, or any other reference that
tells you when you use what function or method *when*. That is essentially
conveying the essence of a development language, and I suppose if a help
system could do that, we would eliminate the learning curve of a language!
This is where you (and I suspect the help system) loses me.
'flexgrid' and 'activeX' mean absolutely nothing to me.

ok. The above is simply a refence to the standard windows technologies. The
term activeX apples to all development platforms in windows. activeX is
simply a means by which 3rd party controls (such as a calendar control) can
be placed on a form, and used. In other words, using a activeX control on a
ms-access form means you would NOT be using the native controls that are
available on the tool bar when in design mode. Access is a bit different
then many windows IDE's since it has NATIVE controls. So, if you develop an
application in VB6, or c++ in windows, you might use a combo box. The
standard combo box control included with VB6, or c++ or <your favorite
windows programming system> will ALL likely use the same combo box activeX
control. A acttieX is control based on inter-program communication.

In ms-access, you *can* use activeX controls, but you are STRONGLY advised
to NOT use activeX controls. This is due to the fact that MOST ms-access
applications are NOT deployed using a widows installer that can INCLUDE
these additional code libraries and dependencies. Since we don't have a
linker, nor a system that will automatically include these additional code
libraries (in this case activeX controls), then we try to avoid them. I do
on occasion include additional .dll libraries in my applications, but then I
have to build my own install scripts.

As a note, in windows, we call inter program communication "COM", or object
automation. In the linix world, this is referred to as COBRA. I don't know
the equivalent term for activeX controls in Linux/c++, but there is likely
an equivalent. (whatever lets you place a 3rd party control on a form and
communicate with it is what the technology is going to be called).

So, I am not sure where to start, but you are learning a new development
language,and further learning new platform at the same time. Further, while
it is easy to write code in ms-access, the real hard part is getting the
relational data designs correct. So, new platforms, new programming
language, and even harder is to learn database concepts. You certainly have
your work cut out for you.....

I would suggest that you consider some books....

http://www.mvps.org/access/resources/books.htm
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Lyle Fairfield]

> The "significant woman" in my life is somewhat more reliable than

yours apparently! :-)

Yeah, yeah, sure, sure, whatever ...

[usenet]

Albert D. Kallal <ka****@msn.com> wrote:

Yes, absolutely fine if I know the name of the method/function/action
I want - BUT I haven't yet found anything that gives me any help on
the detailed syntax or an overview of why there seem to be so many
different sorts of 'do something' operations.
Well, I can't think of ANY help system that will explain the use of
pointers, or overloading in c++ either. Either you will have to get a book,
or learn some things over time. So, when learning a new system, connecting
the dots is hard. The docmd for example simply executes a method of the
ms-access appcation. So, in help...if you view any of the methods, you would
be browsing the list of docmd possible options.

.... but there are C and C++ and Java reference manuals which set out
the syntax concisely (as in books), I don't seem to be able to find
any equivalent books for VB/Access.

I'm still not clear on the differences between actions, functions,
methods, etc.

I don't have a big problem with the object hierarchy, it's the sort of
thing I'm already fairly familiar with. As I said it's the detailed
sysntax and what sort of 'things' to use where that confuses me.

Learning to use what things where is certainly the issue. While some help
system actually might explain c++ pointers, I would be REALLY surprised if
the help system told you WHEN to use pointers. (that would be a amazing help
system!!). Again, I can't think of any c++, or any other reference that
tells you when you use what function or method *when*. That is essentially
conveying the essence of a development language, and I suppose if a help
system could do that, we would eliminate the learning curve of a language!

I agree, it's a programming "fact of life" that no help systems and
few books tell you *why* to use particular constructs. However it's
usually not too difficult to find out what the syntax is, I can very
quickly find out how to write down a pointer to a structure element in
C or C++. On the other hand I still find it difficult to work out the
syntax for referring to an object element in VB/Access. Is there
anywhere that actually writes this out concisely or does everyone just
acquire how to do it from examples?

This is where you (and I suspect the help system) loses me.
'flexgrid' and 'activeX' mean absolutely nothing to me.

ok. The above is simply a refence to the standard windows technologies. The
term activeX apples to all development platforms in windows. activeX is
simply a means by which 3rd party controls (such as a calendar control) can
be placed on a form, and used. In other words, using a activeX control on a
ms-access form means you would NOT be using the native controls that are
available on the tool bar when in design mode. Access is a bit different
then many windows IDE's since it has NATIVE controls. So, if you develop an
application in VB6, or c++ in windows, you might use a combo box. The
standard combo box control included with VB6, or c++ or <your favorite
windows programming system> will ALL likely use the same combo box activeX
control. A acttieX is control based on inter-program communication.

In ms-access, you *can* use activeX controls, but you are STRONGLY advised
to NOT use activeX controls. This is due to the fact that MOST ms-access
applications are NOT deployed using a widows installer that can INCLUDE
these additional code libraries and dependencies. Since we don't have a
linker, nor a system that will automatically include these additional code
libraries (in this case activeX controls), then we try to avoid them. I do
on occasion include additional .dll libraries in my applications, but then I
have to build my own install scripts.

OK, thanks for the explanation.

As a note, in windows, we call inter program communication "COM", or object
automation. In the linix world, this is referred to as COBRA. I don't know
the equivalent term for activeX controls in Linux/c++, but there is likely
an equivalent. (whatever lets you place a 3rd party control on a form and
communicate with it is what the technology is going to be called).
COBRA is just one of many, many ways to communicate, we use it at work
between Sun Solaris and the MS world.

So, I am not sure where to start, but you are learning a new development
language,and further learning new platform at the same time. Further, while
it is easy to write code in ms-access, the real hard part is getting the
relational data designs correct. So, new platforms, new programming
language, and even harder is to learn database concepts. You certainly have
your work cut out for you.....
The database concepts bit I kow the basics as I've been developing
C/C++ programs that use Oracle (and call SQL queries) for many, many
years. I think this is part of my frustration, I can conceive what I
want in database terms but I find it difficult to put it into
practice.

I would suggest that you consider some books....

http://www.mvps.org/access/resources/books.htm

Yes, I quite agree! :-)
Thanks for all the help.

--
Chris Green

[Albert D. Kallal]

Good questions + answers on your part!!!

... but there are C and C++ and Java reference manuals which set out
the syntax concisely (as in books), I don't seem to be able to find
any equivalent books for VB/Access.

I'm still not clear on the differences between actions, functions,
methods, etc.
It is difficult, since a LARGE part of ms-access is using the *existing*
ms-access object model..and it is hand full!!

We have two parts:

#1
The programming language used is Visual Basic - for the most part, this
language is 100% the same as classic VB
(except that the forms used in ms-access are NOT the same as VB6 forms).

#2
The application model we interact with - ms-access (this is the complex
one).

So, all of your functions for the most part are simply VB expressions (the
above #1). There is a nice list of built in functions in that VB references
6th entry - Microsoft visual basic references.. (As a warning, stay away
from the "Microsoft Forms Visual basic Reference" found as a sub category
here--- we don't use these in ms-access)

So, functions for the most part are going to be found in the VB reference.

For what we call actions, and most methods...that is going to be the
ms-access object model, so, we use the first entry of
Microsoft Access Visual Basic Documentation (#2 in the above).

The VB references is quite general, and it has things like scope of
variables, looping, and virtually the whole VB language is documented.

Then, there is also the ms-access object model explained...you find the help
for that in the First entry of

Microsoft Access Visual basic reference

This is the one that you will use once you up to speed in Visual Basic...

So, methods + actions are really just using part of the ms-access
object....functions are the built in VB functions.
However it's
usually not too difficult to find out what the syntax is, I can very
quickly find out how to write down a pointer to a structure element in
C or C++. On the other hand I still find it difficult to work out the
syntax for referring to an object element in VB/Access. Is there
anywhere that actually writes this out concisely or does everyone just
acquire how to do it from examples?
There is some examples in both the VB reference, and the ms-access vb ref...

Lets look up the forms object..and how to use it......

in the VB ide, help->Microsoft Visual basic help

On the right...we click on the first ref....Microsoft Access Visual basic
references. (we are using a ms-access form...so, that why we look here!!)
Then expand the entry objects---> now choose "f" from the list....click on
forms object.

Now, you can navigate to the above via the collections object also (note
that EVERYTHING in ms-access is a collection).

So, also could have simply looked this up by the collections in ms-access
also. So, in place of the above forms, we could have went collections->
f---> forms collection. This winds you up with a genreal expalin of a form
(you could then click on the "see also" to jump to the forms object refercne
as we did above)..
COBRA is just one of many, many ways to communicate, we use it at work
between Sun Solaris and the MS world.

Yes, but in windows, we live and die by object automation. EVERYTHING you
use in windows is a com object (we don't care..and the programmers don't
care about this fact, or give it a 2nd thought.......but, it is important to
note that this is how it all works - and, for the record, .net is the EXACT
same idea..but it works OVER the internet!!)

So, for example to launch outlook with a attached report, we will use
Outlook as a object in our code. It is REALLY simple to do this. We just set
a reference in the code editor, and then without even giving it a thought ,
you can now write and use outlook code in your ms-access applications. (all
of the properties...methods etc are instant available in the ms-access IDE
for all of outlook!).

Even windows scripts (batch files) will actually use object automation to do
things. (eg: nightly launch ms-access....generate a report.....send results
to a word document, launch outlook...attached the word document we just
made, and send it...- all of this can be done from a windows script, and
using application objects). Unix/linix people find windows batch files hard
to write, since you are actually working with objects in a windows
script....

Last, but not least, many will say that the help sucks compared to access 97
(that is 4 versions ago!!). However, I find the a2003 help quite good, and
in many ways it is BETTER then the access 97 help....

In addition to this great newsgroup, don't forget to check out the
Microsoft.public.access.* hierarchy of newsgroups. (point your newsreader
to news.microsoft.com).

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[usenet]

Albert D. Kallal <ka****@msn.com> wrote:
[snipped lots and lots of useful stuff]

Last, but not least, many will say that the help sucks compared to access 97
(that is 4 versions ago!!). However, I find the a2003 help quite good, and
in many ways it is BETTER then the access 97 help....

In addition to this great newsgroup, don't forget to check out the
Microsoft.public.access.* hierarchy of newsgroups. (point your newsreader
to news.microsoft.com).

Thanks for the (yet again) comprehensive reply.

I'm beginning to get to grips with it and having a better overview of
what's going on.

I think much of my problem (with Access in particular) is the
'multiple technologies' involved. Back in my 'home' world of Java
and/or C++ anything new that is added *has* to fit into the existing
syntax and semantics. So Java *only* has methods, you cope with
different 'things' out there by creating new objects and interfaces
but the details of how you interact with them are always the same.

The mix of VB, Access objects and other paraphenalia in Acces is,
initially at least, rather confusing.

The actual application I'm devloping (for my own use) is also
beginning to show signs of actually becoming functional as well, so
things are looking up! :-)

Thanks again for all the help and explanations.

--
Chris Green

[David W. Fenton]

us****@isbd.co.uk wrote in news:44322fe7.0@entanet:

Albert D. Kallal <ka****@msn.com> wrote:
[snipped lots and lots of useful stuff]

Last, but not least, many will say that the help sucks compared
to access 97 (that is 4 versions ago!!). However, I find the
a2003 help quite good, and in many ways it is BETTER then the
access 97 help....

In addition to this great newsgroup, don't forget to check out
the Microsoft.public.access.* hierarchy of newsgroups. (point
your newsreader to news.microsoft.com).
Thanks for the (yet again) comprehensive reply.

I'm beginning to get to grips with it and having a better overview
of what's going on.

I think much of my problem (with Access in particular) is the
'multiple technologies' involved. Back in my 'home' world of Java
and/or C++ anything new that is added *has* to fit into the
existing syntax and semantics. So Java *only* has methods, you
cope with different 'things' out there by creating new objects and
interfaces but the details of how you interact with them are
always the same.

The mix of VB, Access objects and other paraphenalia in Acces is,
initially at least, rather confusing.

I don't see it. Everything's an object that exposes methods and
properties.

DoCmd is an object. It has methods (no properties).

Collections are objects that have properties and methods.

It all seems pretty consistent with the basics of object-oriented
programming to me.
The actual application I'm devloping (for my own use) is also
beginning to show signs of actually becoming functional as well,
so things are looking up! :-)

You don't need to know much at all about VBA to be able to construct
a useful Access application of some complexity.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[usenet]

David W. Fenton <XX*******@dfenton.com.invalid> wrote:

us****@isbd.co.uk wrote in news:44322fe7.0@entanet:

I think much of my problem (with Access in particular) is the
'multiple technologies' involved. Back in my 'home' world of Java
and/or C++ anything new that is added *has* to fit into the
existing syntax and semantics. So Java *only* has methods, you
cope with different 'things' out there by creating new objects and
interfaces but the details of how you interact with them are
always the same.

The mix of VB, Access objects and other paraphenalia in Acces is,
initially at least, rather confusing.

I don't see it. Everything's an object that exposes methods and
properties.

DoCmd is an object. It has methods (no properties).

Collections are objects that have properties and methods.

It all seems pretty consistent with the basics of object-oriented
programming to me.

So what about all those VB functions? And what about Actions?

The actual application I'm devloping (for my own use) is also
beginning to show signs of actually becoming functional as well,
so things are looking up! :-)

You don't need to know much at all about VBA to be able to construct
a useful Access application of some complexity.

I have found previously (an application I wrote some time ago using
Access 97) and am finding again now that to get the user interface I
want almost inevitably requires at least a small amount of VB code.

--
Chris Green

[David W. Fenton]

us****@isbd.co.uk wrote in news:44328ad9.0@entanet:

David W. Fenton <XX*******@dfenton.com.invalid> wrote:

us****@isbd.co.uk wrote in news:44322fe7.0@entanet:

> I think much of my problem (with Access in particular) is the
> 'multiple technologies' involved. Back in my 'home' world of
> Java and/or C++ anything new that is added *has* to fit into
> the existing syntax and semantics. So Java *only* has methods,
> you cope with different 'things' out there by creating new
> objects and interfaces but the details of how you interact with
> them are always the same.
>
> The mix of VB, Access objects and other paraphenalia in Acces
> is, initially at least, rather confusing.

I don't see it. Everything's an object that exposes methods and
properties.

DoCmd is an object. It has methods (no properties).

Collections are objects that have properties and methods.

It all seems pretty consistent with the basics of object-oriented
programming to me.

So what about all those VB functions? And what about Actions?

It's true there are commands and functions, but they are methods of
an object, implicit or not, in most cases the Application object.

For instance, CurrentDB() is a function that can be used without
qualification.

But if you use the object browser (hit F2 in a code window), you'll
see that it's parent is the Application object, and a full reference
to it is in this format:

Application.CurrentDB()

That is the case for nearly everything in Access.

As to ACTIONS, you're looking at the Help for writing MACROS, which
are not code. I have always found it quite annoying that the Access
help often takes you first to help for writing Macros, but almost
all of the ACTION help topics give the equivalent VBA method near
the end (or in the links at the top of the help topic). For
instance, the RunCommand Action help topic has this text at the end:

To run the RunCommand action in Visual Basic, use the RunCommand
method of the Application object. (This is equivalent to the
RunCommand method of the DoCmd object.)

I agree that the help is confusing in this regard.

You might want to spend some time working with the object browser
(F2 in any code window).

> The actual application I'm devloping (for my own use) is also
> beginning to show signs of actually becoming functional as
> well, so things are looking up! :-)

You don't need to know much at all about VBA to be able to
construct a useful Access application of some complexity.

I have found previously (an application I wrote some time ago
using Access 97) and am finding again now that to get the user
interface I want almost inevitably requires at least a small
amount of VB code.

But you often don't have to write that code yourself.

Of course, if you want to change the way Access behaves by default,
you often have to write VBA code. But that doesn't preclude writing
complicated apps without writing VBA code. I think it's best to
learn the default Access approaches to things and then only depart
from them when you have good reasons for doing them. That enhances
Access's value, since it's much faster to use the default behavior
when you are able.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/