From FoxPro/VFP to Access

[Jim]

I've been handed a Access 2000 app I need to modify under Access 2003. I've
been reading and poring over several access/VBA books but haven't found the
amswer to this simple question about program organization/code flow in VBA.

In FoxPro, I would call a procedure (PROC) and that would execute code from
top down. Within that .PRG file were functions I could create and call.
This code was typically at the bottom of the .PRG file - after the "main"
code flow.

I am trying to debug an Access module and have made note of function and
sub. Is the Access "function" equivalent to the heirarchal "main" code
flow (PROC) in VFP? Is the Function code called first - despite it's
physical position in the code file? In essence where in a module does Access
start executing code?

I request your indulgence on this question. I've been able to get my arms
around every other concept in learning access, but am afraid the conventions
of writing FP/VFP code have put blinders on me.

Thanks for your help!

 

[Klatuu]

The physical location of code within a module is of no consequence in Access.
Functions ans Subs are different only in that a Function can return a value,
but a Sub can not. Both can accept arguments.

There are four kinds of code modules in Access.
Form module
Report module
Standard module
Class module

Form and Report modules are actuall Class modules, but they have some
differences from a Class module.

A form may or may not have a module. They typically do, but you can have a
form without a module. All the code in a form module is specific to the
form. It can contain code that responds to specific events within the form
and the form's objects. For example, you can define a Click event for a
command button that runs whenever the button is clicked. You can define a
Load event for a form. The code in the Load event runs after the form has
been opened, but while it is loading.

Report modules are much like form modules except the events are different in
a report.

Standard modules contain functions and subs that can be called from other
modules, provided they are not declared as Private. This gives you the
ability to use common routines within your application.

Class modules are a special kind of module for building your own class
objects. They do very specific things and you handle them as an object with
methods and properties.

 

[Jim]

Thanks for the overview - especially code location.

Does that means Access loads all the standard modules into RAM at startup so
that if a menu calls a particular function, it just grabs it from memory?

 

[Klatuu]

No. It is loaded as needed.
form and report modules are loaded when the form or report is opened.
class modules are loaded when the class is instanciated.
standard modules are loaded when any sub or function in the module is called.
That is to say the procedure alone is not loaded, but the entire module it
is in is loaded.

 

[david]

You can configure a database to load a form or a macro at
startup. In current versions, you may be able to configure it
to load something else at startup, like a code module, but I
don't remember.

If a form is loaded at startup, it can call code, or have a button
to call code.

If a macro is loaded at startup, it call code, or load another
macro, or open a form or report, which can call code.

If you don't configure the database to load something at
startup, you can do the same thing from the startup shortcut,
or windows run command, or, when the database opens,
you can click on a form or report or macro, which can
run code, or you can run code from the VBA window,
by typing the name of a function or sub-routine into the
VBA Immediate Window.

(david)

 

[Klatuu]

There are 3 options
1. A macro named autoexec
It will always run when the mdb file is opened
2. A form or data access page identified in the Startup Options
3. A macro idenitifed by using the /x option in the command line to start
the application.

If the application is a User Interface application, I always start with a
form.
If the application is used for one purpose to perform some database
maintenance or data manipulation, I use the autoexec macro with a RunCode
action that starts up the VBA code that does the work.
The /x option might be useful if your application has multiple uses and you
want to be able to specify what the application does when opened.

 

[david]

The SHELLSYSTEM command line option allows you
to open forms or reports from a shortcut, or at least it
used to. The easiest way to get that is to drag-and-drop.

query example:
/SHELLSYSTEM [OpenQuery c:\script.maq, 0]

By the way, that query can run code too...

(david)

 

[Klatuu]

I have never heard of shellsystem. There is no results when searching msdn
for it.
The only thing I could find when googling for shellsystem is that it is
malware.

--
Dave Hargis, Microsoft Access MVP

The SHELLSYSTEM command line option allows you
to open forms or reports from a shortcut, or at least it
used to. The easiest way to get that is to drag-and-drop.

query example:
/SHELLSYSTEM [OpenQuery c:\script.maq, 0]

By the way, that query can run code too...

(david)

 

[Klatuu]

searching a bit further, I found a product named filext, but I know nothing
about it.
--
Dave Hargis, Microsoft Access MVP

The SHELLSYSTEM command line option allows you
to open forms or reports from a shortcut, or at least it
used to. The easiest way to get that is to drag-and-drop.

query example:
/SHELLSYSTEM [OpenQuery c:\script.maq, 0]

By the way, that query can run code too...

(david)

 

[david]

The Access help file does not discuss the mechanism by which shortcuts
are implemented. Look at the installation manifest for Access, or look at
the registration for MAQ, MAF files etc.

(david)

searching a bit further, I found a product named filext, but I know
nothing
about it.
--
Dave Hargis, Microsoft Access MVP

The SHELLSYSTEM command line option allows you
to open forms or reports from a shortcut, or at least it
used to. The easiest way to get that is to drag-and-drop.

query example:
/SHELLSYSTEM [OpenQuery c:\script.maq, 0]

By the way, that query can run code too...

(david)

There are 3 options
1. A macro named autoexec
It will always run when the mdb file is opened
2. A form or data access page identified in the Startup Options
3. A macro idenitifed by using the /x option in the command line to
start
the application.

If the application is a User Interface application, I always start with
a
form.
If the application is used for one purpose to perform some database
maintenance or data manipulation, I use the autoexec macro with a
RunCode
action that starts up the VBA code that does the work.
The /x option might be useful if your application has multiple uses and
you
want to be able to specify what the application does when opened.

--
Dave Hargis, Microsoft Access MVP


:

You can configure a database to load a form or a macro at
startup. In current versions, you may be able to configure it
to load something else at startup, like a code module, but I
don't remember.

If a form is loaded at startup, it can call code, or have a button
to call code.

If a macro is loaded at startup, it call code, or load another
macro, or open a form or report, which can call code.

If you don't configure the database to load something at
startup, you can do the same thing from the startup shortcut,
or windows run command, or, when the database opens,
you can click on a form or report or macro, which can
run code, or you can run code from the VBA window,
by typing the name of a function or sub-routine into the
VBA Immediate Window.

(david)


I've been handed a Access 2000 app I need to modify under Access
2003.
I've
been reading and poring over several access/VBA books but haven't
found
the
amswer to this simple question about program organization/code flow
in
VBA.

In FoxPro, I would call a procedure (PROC) and that would execute
code
from
top down. Within that .PRG file were functions I could create and
call.
This code was typically at the bottom of the .PRG file - after the
"main"
code flow.

I am trying to debug an Access module and have made note of function
and
sub. Is the Access "function" equivalent to the heirarchal "main"
code
flow (PROC) in VFP? Is the Function code called first - despite
it's
physical position in the code file? In essence where in a module
does
Access
start executing code?

I request your indulgence on this question. I've been able to get
my
arms
around every other concept in learning access, but am afraid the
conventions
of writing FP/VFP code have put blinders on me.

Thanks for your help!