Navigation Pane in Access 2002

[Ixtreme]

I have an Access 2002 database with different forms. I would like to create a main form with, on the left side, buttons for each form I have.
If the user clicks on one of these buttons, the associated form should open on the right side of the main form. The buttons should remain visible all the time. I know this can be done in the newer versions of Access but is it also possible in 2002?

 

[Douglas J Steele]

It's possible, but you'd have to add each button yourself, and associate
code with each to have it open a form. Much easier might be to have a list
box or combo box containing the names of each form, and put code in the
AfterUpdate event to open the selected form.

"Ixtreme" wrote in message

I have an Access 2002 database with different forms. I would like to create
a main form with, on the left side, buttons for each form I have.
If the user clicks on one of these buttons, the associated form should open
on the right side of the main form. The buttons should remain visible all
the time. I know this can be done in the newer versions of Access but is it
also possible in 2002?

 

[Ixtreme]

Hi Douglas,

Not exactly what I want. I want the left side of my 'main' form to always displays 5 buttons. If I click button 1, it should open form A on the same 'main' form next to the buttons. If I click button 2, form A should change into form B etc.

 

[Gloops]

Ixtreme wrote, on 06/06/2013 16:20 :

Hi Douglas,

Not exactly what I want. I want the left side of my 'main' form to always displays 5 buttons. If I click button 1, it should open form A on the same 'main' form next to the buttons. If I click button 2, form A should change into form B etc.

Hello,

These are subforms.

 

[Access Developer]

Yes, on the right side you place a Subform Control and in code on the Click
event of each Command Button, you use VBA code or a Macro to change the
Source Object property of the Subform Control (and the Link Child Fields and
Link Master Fields, if needed).

 

[Ixtreme]

Thanks, I'll give it a try!

 

[Gloops]

Access Developer a écrit, le 06/06/2013 18:20 :

Yes, on the right side you place a Subform Control and in code on the Click
event of each Command Button, you use VBA code or a Macro to change the
Source Object property of the Subform Control (and the Link Child Fields and
Link Master Fields, if needed).

It can be easier to create a (hidden) subform for each part, and make it
visible when clicking on the relevant button.

Just verify the resource consumption.

 

[Gloops]

Gloops wrote, on 06/06/2013 16:38 :

Ixtreme wrote, on 06/06/2013 16:20 :

Hello,

These are subforms.

The subforms have an advantage : they already existed in version 97

On more recent versions, you also have controls that present a
collection of tabs, functionally exactly what you want to do, even if
the aspect is a little different.
I think I forgot the name of that type of control, but the picture on
the toolbar should help you find it ...

--

 

[Access Developer]

I'm cautious about designing and implementing a particular solution based on
an assumption of efficiency -- either approach will work, but I'd think
testing would be needed to determine if either approach was more efficient
than the other, and whether the difference in efficiency is enough to
matter.

Remember the hype about creating "lightweight" forms with no module because
they would load faster? The then-editor of Access Advisor tested a form with
no module and the same form with the largest module possible, and found the
"lightweight" form did load faster, by a massive 15 milliseconds (not
discernable to someone sitting at the keyboard waiting for the form to
open). Several "highly knowledgeable Access gurus" were very embarrassed --
they had drunk the Redmond Kool-Aid without verifying the claims and had
been strongly suggesting lightweight forms.

--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

Access Developer a écrit, le 06/06/2013 18:20 :

Yes, on the right side you place a Subform Control and in code on the
Click
event of each Command Button, you use VBA code or a Macro to change the
Source Object property of the Subform Control (and the Link Child Fields
and
Link Master Fields, if needed).

It can be easier to create a (hidden) subform for each part, and make it
visible when clicking on the relevant button.

Just verify the resource consumption.

 

[Gloops]

So, if you prefer, do spend a lot of time to develop a unique sub-form
that will be populated dynamically when clicking on a button. You will
spend much more time than by providing a sub-form by type of treatment,
but, maybe, you will gain somewhat in loading time ...

If you do develop both solutions, please report the results in terms of
difference of efficiency.
_______________________________________________
Access Developer wrote, on 08th June 2013 08:00 :

 

[Access Developer]

What are you talking about? Both of us suggested separate Forms for each
button... at least I think you did... and only differed in how to activate
the one that's selected. I suggested setting the Source Object (and
possibly Link Child Fields and Link Master Fields) for a single Subform
Control on the main Form; you suggested placing the multiple Subform
Controls on the main Form and hiding/unhiding them.

Just in case it's not clear to some reading this: there is no "subform
object" in Access; there is a Subform Control which can display a Form or
datasheet view; it's only a shortcut in terminology to talk about "a
subform".

Changing the Source Object property of a Subform Control populates the
Subform Control with the Form you specify in the Source Object property.

In answer to your question: No, I prefer to implement what is easier or
"seems better" to implement, and worry about performance only if it turns
out to be a problem.

Whatever did I write that would make you think I suggested a "generic
subform" to fit the data for possible options in an application?

 

[Gloops]

Oh yes, you are right.

I mixed up source of a subform control with source of the associated
form. It is even probable what you say takes less lines of code to
implement, and less memory too.

Sorry.
_______________________________________________
Access Developer wrote, on 08th June 2013 20:51 :

 

[Access Developer]

Sorry.

No problem... in fact, it is always helpful to others who are reading to see
multiple viewpoints and discussion about approaches and techniques. Thanks
for participating and helping keep our "zombie" newsgroup shuffling along; I
keep on answering not only because I'm paying back many people who helped me
over a lot of years, but because, in the process, I keep learning and
refreshing my memory.

 

[Gloops]

Access Developer wrote, on 09th June 2013 22:01 :

I keep learning and
refreshing my memory.

and ... so did I.

 

[Access Developer]

Access Developer wrote, on 09th June 2013 22:01 :

and ... so did I.

In fact, I've successfully used the approach you described more than once...
but, now, I'd more likely try what I described.

 

[HiTechCoach]

There is a working framework you can use to get started: Search the utteraccess[dot]com Access Code Archive for "Explorer Bar - Non ActiveX" by tinygiant.

Sorry I can't post a link at this time.

Boyd Trimmell, Microsoft Access MVP
aka HiTechCoach