Using Module(s) to handle record navigation?

[Guest]

In the process of polishing up my (last) beta application; I have been
exploring all the possible ways of speeding up my forms. I realized that
numerous a forms under various application modules/suites lots of the same
navigation buttons.

I thought of creating a macro to handle all this, and just reference the
macro, etc, in order to reduce the amount of forms coding/duplication from
form to form. However, I have no idea of where macros are going in future
versions of MS Access. Is it possible to use a single VBA/module, or
different modules, for handling each of the commands? Are there articles with
examples out there, or suggestion on how I might handle navigation buttons
this way?

First, I realize that this may be overkill if there were only a few forms in
question, but it does not.

Second, I tried using, “Navigation Buttons†in Properties and format.
However, for some areas of my app., it means fundamental and time-consuming
changes that would have to be made at this stage of the game. Yea, I should
have thought of this sooner; but I didn’t.

Thanks,
John

 

[Guest]

Update:

I sinced used code, that I acquire from a newsgroup, for a module containing
all the navigation commands to be referrenced from the different forms that I
use with my own navigation buttons. This works as along as the navigation
button is located on the main form with the following code in the, "On Click"
for the e.g., Previous button:

=navtoPrevious([activecontrol].[parent])

However, if I want to place the same code on a sub form it does not.
Therefore, I tried creating a path to the subfor where the navigation buttons
are located:

=navtoPrevious([activecontrol].[Forms]![formA]![formB].[Form])

It still does not work. So, I'm back to square one in getting all this to
work.

Thanks,
John

 

[Marshall Barton]

I don't see how the active control enters into the problem.
All you need is the form object that contains the nav
button.

It think all you need is to call the procedure from the
OnClick property:
=navtoPrevious(Form)
or from an event procedure:
=navtoPrevious(Me)
--
Marsh
MVP [MS Access]

Update:

I sinced used code, that I acquire from a newsgroup, for a module containing
all the navigation commands to be referrenced from the different forms that I
use with my own navigation buttons. This works as along as the navigation
button is located on the main form with the following code in the, "On Click"
for the e.g., Previous button:

=navtoPrevious([activecontrol].[parent])

However, if I want to place the same code on a sub form it does not.
Therefore, I tried creating a path to the subfor where the navigation buttons
are located:

=navtoPrevious([activecontrol].[Forms]![formA]![formB].[Form])

It still does not work. So, I'm back to square one in getting all this to
work.

In the process of polishing up my (last) beta application; I have been
exploring all the possible ways of speeding up my forms. I realized that
numerous a forms under various application modules/suites lots of the same
navigation buttons.

I thought of creating a macro to handle all this, and just reference the
macro, etc, in order to reduce the amount of forms coding/duplication from
form to form. However, I have no idea of where macros are going in future
versions of MS Access. Is it possible to use a single VBA/module, or
different modules, for handling each of the commands? Are there articles with
examples out there, or suggestion on how I might handle navigation buttons
this way?

First, I realize that this may be overkill if there were only a few forms in
question, but it does not.

Second, I tried using, “Navigation Buttons” in Properties and format.
However, for some areas of my app., it means fundamental and time-consuming
changes that would have to be made at this stage of the game. Yea, I should
have thought of this sooner; but I didn’t.

 

[Guest]

But how would you write "=navtoPrevious(Me)" into an event procedure?

John

I don't see how the active control enters into the problem.
All you need is the form object that contains the nav
button.

It think all you need is to call the procedure from the
OnClick property:
=navtoPrevious(Form)
or from an event procedure:
=navtoPrevious(Me)
--
Marsh
MVP [MS Access]

Update:

I sinced used code, that I acquire from a newsgroup, for a module containing
all the navigation commands to be referrenced from the different forms that I
use with my own navigation buttons. This works as along as the navigation
button is located on the main form with the following code in the, "On Click"
for the e.g., Previous button:

=navtoPrevious([activecontrol].[parent])

However, if I want to place the same code on a sub form it does not.
Therefore, I tried creating a path to the subfor where the navigation buttons
are located:

=navtoPrevious([activecontrol].[Forms]![formA]![formB].[Form])

It still does not work. So, I'm back to square one in getting all this to
work.

In the process of polishing up my (last) beta application; I have been
exploring all the possible ways of speeding up my forms. I realized that
numerous a forms under various application modules/suites lots of the same
navigation buttons.

I thought of creating a macro to handle all this, and just reference the
macro, etc, in order to reduce the amount of forms coding/duplication from
form to form. However, I have no idea of where macros are going in future
versions of MS Access. Is it possible to use a single VBA/module, or
different modules, for handling each of the commands? Are there articles with
examples out there, or suggestion on how I might handle navigation buttons
this way?

First, I realize that this may be overkill if there were only a few forms in
question, but it does not.

Second, I tried using, “Navigation Buttons†in Properties and format.
However, for some areas of my app., it means fundamental and time-consuming
changes that would have to be made at this stage of the game. Yea, I should
have thought of this sooner; but I didn’t.

 

[Marshall Barton]

Well, I don't know what your code looks like so maybe you
would not want to call it in an assignment statement:
retval = navtoPrevious(Me)
To be more analogous with the call in an event property, you
might prefer to use a call statement:
Call navtoPrevious(Me)
or just:
navtoPrevious Me
--
Marsh
MVP [MS Access]

But how would you write "=navtoPrevious(Me)" into an event procedure?
John

I don't see how the active control enters into the problem.
All you need is the form object that contains the nav
button.

It think all you need is to call the procedure from the
OnClick property:
=navtoPrevious(Form)
or from an event procedure:
=navtoPrevious(Me)

Update:
I sinced used code, that I acquire from a newsgroup, for a module containing
all the navigation commands to be referrenced from the different forms that I
use with my own navigation buttons. This works as along as the navigation
button is located on the main form with the following code in the, "On Click"
for the e.g., Previous button:

=navtoPrevious([activecontrol].[parent])

However, if I want to place the same code on a sub form it does not.
Therefore, I tried creating a path to the subfor where the navigation buttons
are located:

=navtoPrevious([activecontrol].[Forms]![formA]![formB].[Form])

It still does not work. So, I'm back to square one in getting all this to
work.

:

In the process of polishing up my (last) beta application; I have been
exploring all the possible ways of speeding up my forms. I realized that
numerous a forms under various application modules/suites lots of the same
navigation buttons.

I thought of creating a macro to handle all this, and just reference the
macro, etc, in order to reduce the amount of forms coding/duplication from
form to form. However, I have no idea of where macros are going in future
versions of MS Access. Is it possible to use a single VBA/module, or
different modules, for handling each of the commands? Are there articles with
examples out there, or suggestion on how I might handle navigation buttons
this way?

First, I realize that this may be overkill if there were only a few forms in
question, but it does not.

Second, I tried using, “Navigation Buttons” in Properties and format.
However, for some areas of my app., it means fundamental and time-consuming
changes that would have to be made at this stage of the game. Yea, I should
have thought of this sooner; but I didn’t.