Creating a 'Breadcrumb Trail' on forms

[Jan Il]

Hi all - Access 2002 XP, Windows ME

I currently have controls on all my forms for users to click which takes
them back to a specific form, such as the previous filter form or perhaps
the Main Switchboard. However, there are times when it would be very
helpful, and efficient, if they could return to any point at any time by
clicking on the form they want to return to as needed.

What is would like to do is have the name of each form they went to in the
process of reaching the current form listed in the footer of the form, so
that they can select which form they wish to return to. The current return
control is coded to go back to the previous source form, in case they
need/want to make another selection from that form. But, if they are
finished, they could return to any other form in the 'Breadcrumb Trail' in
the footer, and close all the other forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to go back
to the Wayside Inspections form to select another piece of equipment, they
could select one of the other forms in the ''trail', which would take them
directly back to that form, and close any forms still open at the same time.
I think I can figure out the how on the controls, but, how should I set up
the controls to do this? This would be put on all forms in the DB that where
this process would be needed.

Sorry if I'm not explaining very well, but I'm trying. <g>

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

 

[SFAxess]

You could use a system of label controls which use the
SubHyperlink property to refer to the form. You may have
to hide and unhide the controls, or set their caption and
hyperlink properties when forms are opened.

 

[Jan Il]

Hi SFAxess!

You could use a system of label controls which use the
SubHyperlink property to refer to the form. You may have
to hide and unhide the controls, or set their caption and
hyperlink properties when forms are opened.

Yes, using the labels is the first thing that came to mind, as that is what
I have used for the 'Exit' controls that close the current form and then
open the previous form. But, I was not sure if the label would be the best
type of control to use for this. Plus, how to format the information for
each of them to accomplish what I want to do. I would like text in the label
to show the name of the form that label will take them to, such as Home
(which would be the Opening Page), and when the user clicked on the word
Home, the control would then, close the current form and open the Home form.
Is this how the SubHyperlink function you refer to work?

The current Exit labels on the forms close the current form and then open
the previous form, which was closed when the current form was opened by the
command button that opened that form. This way there are no open forms at
any time except the current form, so this would remain the primary method of
navigation between the immediate forms. But, there will come a point when
the user will be finished and ready to move to the next function, so they
will need to go back to the Main Switchboard or Menu to do so. That is when
they could use the Breadcrumb Trail to jump to Home, Main Switchboard or
exit the DB.

Thank you very much for your time and very helpful information. I really do
appreciate it. I'll try the SubHyperlink and see how it works out. I've
never used it before, so even more fun learning something new. ;-))

Best regards,
Jan

 

[Jim/Chris]

Have you considered using tabs and each one of your forms
as subform in each tab

Jim

 

[Dirk Goldgar]

Hi all - Access 2002 XP, Windows ME

I currently have controls on all my forms for users to click which
takes them back to a specific form, such as the previous filter form
or perhaps the Main Switchboard. However, there are times when it
would be very helpful, and efficient, if they could return to any
point at any time by clicking on the form they want to return to as
needed.

What is would like to do is have the name of each form they went to
in the process of reaching the current form listed in the footer of
the form, so that they can select which form they wish to return to.
The current return control is coded to go back to the previous source
form, in case they need/want to make another selection from that
form. But, if they are finished, they could return to any other form
in the 'Breadcrumb Trail' in the footer, and close all the other
forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to
go back to the Wayside Inspections form to select another piece of
equipment, they could select one of the other forms in the ''trail',
which would take them directly back to that form, and close any forms
still open at the same time. I think I can figure out the how on the
controls, but, how should I set up the controls to do this? This
would be put on all forms in the DB that where this process would be
needed.

Sorry if I'm not explaining very well, but I'm trying. <g>

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

Jan -

This is an interesting idea. I haven't tested this out, but I believe
you could do something like this:

+ Define a Public variable named gvarBreadcrumbs, type Variant, in a
standard module. In the same module, create this function:

Public Function fncBreadcrumbs() As String
fncBreadcrumbs = gvarBreadcrumbs & vbNullString
End Function

+ In every main form (not subforms), place an text box named
txtBreadcrumbs with these properties:

Control Source: =fncBreadcrumbs()
Tab Stop: No

+ Also in every main form, put code like this in the form's Open event:

gvarBreadcrumbs = (gvarBreadcrumbs + " -> ") & Me.Name

+ The only thing that's left is a public function that figures out what
form to go to, based on where you clicked in txtBreadcrumbs. You would
call this function in the Click event of txtBreadcrumbs, and you would
pass it [txtBreadcrumbs] and [txtBreadcrumbs].[SelStart]. In other
words, the OnClick property of txtBreadcrumbs would be set to

=fncFollowBreadcrumbs([txtBreadcrumbs], [txtBreadcrumbs].[SelStart])

The function's signature would look something like this:

Public Function fncFollowBreadcrumbs( _
BreadcrumbTrail As Variant, _
Crumb As Integer)

' The code that goes in here would do the following:
' (1) Use the Split function to get an array of the
' forms in the list.
' (2) Figure out from the SelStart value passed as
' the argument "Crumb", which of the forms
' in the array was clicked.
' (3) Modify the global variable gvarBreadcrumbs to
' truncate it after the form that was clicked.
' (4) Close all forms following that form in the
' array.
' (5) Open the form that was clicked.

End Function

Clearly, the code for the function is not trivial to write, but it
should be feasible. Different ways of storing the breadcrumb trail
might make it easier; for example, storing the trail as an array or a
collection, and only building the text string on demand. I haven't
thought this through completely. It may also be better to set the
user-interface part of this up as a subform that you could simply insert
in a form to get all the functionality. The whole thing is a bit
tricky, though well worth pursuing if you have the time.

 

[SFAxess]

I was not sure if the label would be the best

type of control to use for this.

You could use a command button to do this, but I find
command buttons to be bulky for this sort of thing.

Is this how the SubHyperlink function you refer to work?

It would open the form you have set in the SubHyperlink
property, but you would have to add code to the labels
click or mousedown event to close the current form. The
good part about using the subhyperlink property is when
the user puts the pointer over the label the pointer
becomes a hand and makes it obvious that you should click
the label to link to something, just like you do in web
browsing.

I hope this works out for you.

SFAxess

 

[Fred Boer]

Hey Jan.. if you go the route that Dirk suggests, make sure you don't have
any stray "gvarBlackbird" variables floating around, or you'll be *really*
lost! <g>

 

[Jan Il]

Hi SFAxess,

You could use a command button to do this, but I find
command buttons to be bulky for this sort of thing.


It would open the form you have set in the SubHyperlink
property, but you would have to add code to the labels
click or mousedown event to close the current form. The
good part about using the subhyperlink property is when
the user puts the pointer over the label the pointer
becomes a hand and makes it obvious that you should click
the label to link to something, just like you do in web
browsing.

I hope this works out for you.

Thank you so much for the additional information on this. The 'hand' would
be a big help for the user (and me <g>) I really appreciate your time and
help.

Jan <snip>

 

[Jan Il]

Hi Jim,

"> Have you considered using tabs and each one of your forms

as subform in each tab

No..I haven't. Being as this is my first attempt at this sort of thing, and
having used labels before, that is sort of what stuck most in my mind. But,
I am open to all ideas and I will certainly look into the Tab option for
this.

Thank you very much for your time and input. I really appreciate it.

Jan

 

[Jan Il]

Hi Dirk!

"> >

I currently have controls on all my forms for users to click which
takes them back to a specific form, such as the previous filter form
or perhaps the Main Switchboard. However, there are times when it
would be very helpful, and efficient, if they could return to any
point at any time by clicking on the form they want to return to as
needed.

What is would like to do is have the name of each form they went to
in the process of reaching the current form listed in the footer of
the form, so that they can select which form they wish to return to.
The current return control is coded to go back to the previous source
form, in case they need/want to make another selection from that
form. But, if they are finished, they could return to any other form
in the 'Breadcrumb Trail' in the footer, and close all the other
forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to
go back to the Wayside Inspections form to select another piece of
equipment, they could select one of the other forms in the ''trail',
which would take them directly back to that form, and close any forms
still open at the same time. I think I can figure out the how on the
controls, but, how should I set up the controls to do this? This
would be put on all forms in the DB that where this process would be
needed.

Sorry if I'm not explaining very well, but I'm trying. <g>

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

Jan -

This is an interesting idea. I haven't tested this out, but I believe
you could do something like this:

+ Define a Public variable named gvarBreadcrumbs, type Variant, in a
standard module. In the same module, create this function:

Public Function fncBreadcrumbs() As String
fncBreadcrumbs = gvarBreadcrumbs & vbNullString
End Function

+ In every main form (not subforms), place an text box named
txtBreadcrumbs with these properties:

Control Source: =fncBreadcrumbs()
Tab Stop: No

+ Also in every main form, put code like this in the form's Open event:

gvarBreadcrumbs = (gvarBreadcrumbs + " -> ") & Me.Name

+ The only thing that's left is a public function that figures out what
form to go to, based on where you clicked in txtBreadcrumbs. You would
call this function in the Click event of txtBreadcrumbs, and you would
pass it [txtBreadcrumbs] and [txtBreadcrumbs].[SelStart]. In other
words, the OnClick property of txtBreadcrumbs would be set to

=fncFollowBreadcrumbs([txtBreadcrumbs], [txtBreadcrumbs].[SelStart])

The function's signature would look something like this:

Public Function fncFollowBreadcrumbs( _
BreadcrumbTrail As Variant, _
Crumb As Integer)

' The code that goes in here would do the following:
' (1) Use the Split function to get an array of the
' forms in the list.
' (2) Figure out from the SelStart value passed as
' the argument "Crumb", which of the forms
' in the array was clicked.
' (3) Modify the global variable gvarBreadcrumbs to
' truncate it after the form that was clicked.
' (4) Close all forms following that form in the
' array.
' (5) Open the form that was clicked.

End Function

Clearly, the code for the function is not trivial to write, but it
should be feasible. Different ways of storing the breadcrumb trail
might make it easier; for example, storing the trail as an array or a
collection, and only building the text string on demand. I haven't
thought this through completely. It may also be better to set the
user-interface part of this up as a subform that you could simply insert
in a form to get all the functionality. The whole thing is a bit
tricky, though well worth pursuing if you have the time.

Yes...I see where this is going and I do like the concept. Building the text
string on demand would indeed work very well, and is along the lines I was
thinking if I am understanding it correctly. A new form name would need to
be added to the 'trail' as each new form is opened until the target form is
reached. Agreed, the subform would make it much easier to set up on the
forms, and should changes be necessary they would be made to the subform,
and thus the relative forms.

It is indeed well worth pursuing, and right now I do have some extra time I
can devote to it, so I would very much like to attempt this function. Sounds
like a fun challenge. ;-)

Thank you very much for the great suggestion, I really appreciate it.

Jan

 

[Jan Il]

Hey Jan.. if you go the route that Dirk suggests, make sure you don't have

any stray "gvarBlackbird" variables floating around, or you'll be *really*
lost! <g>

Ahmm...Fred...are you suggesting that my database if for the birds? Or that
it's just crumby? You really like being out on a limb, don't you? <VBG>

 

[Jeff Conrad]

Hi Yoda,

This was an interesting question by Jan so I've been
watching the responses. I was hesitant about offering a
suggestion since I have no idea how to actually implement
the solution.

But anyway, the first thought that came to my mind was to
have a small table used to store the loaded forms. One
field would be text to display the name of the forms. The
other field would be a number field that would increment
by one each time another form is loaded using DMax.

The first record in the table would be the Main
Switchboard form and have the number be one. That record
would never be deleted since that should always be
available???

On each form there would be a list box or combo box that
lists the loaded forms. Somehow using your functions the
records would be created/deleted as needed. Clicking on
the list box/combo box would open that form. Each form's
activate event would requery the table.

Also, wouldn't the public variable information be "lost"
if an error was encountered?

Just some thoughts I had. Obviously this is way beyond my
experience level, but I thought I'd offer the ideas for
the melting pot.

Jeff Conrad
Bend, Oregon

-----Original Message-----

Hi all - Access 2002 XP, Windows ME

I currently have controls on all my forms for users to click which
takes them back to a specific form, such as the previous filter form
or perhaps the Main Switchboard. However, there are times when it
would be very helpful, and efficient, if they could return to any
point at any time by clicking on the form they want to return to as
needed.

What is would like to do is have the name of each form they went to
in the process of reaching the current form listed in the footer of
the form, so that they can select which form they wish to return to.
The current return control is coded to go back to the previous source
form, in case they need/want to make another selection from that
form. But, if they are finished, they could return to any other form
in the 'Breadcrumb Trail' in the footer, and close all the other
forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to
go back to the Wayside Inspections form to select another piece of
equipment, they could select one of the other forms in the ''trail',
which would take them directly back to that form, and close any forms
still open at the same time. I think I can figure out the how on the
controls, but, how should I set up the controls to do this? This
would be put on all forms in the DB that where this process would be
needed.

Sorry if I'm not explaining very well, but I'm trying.

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

Jan -

This is an interesting idea. I haven't tested this out, but I believe
you could do something like this:

+ Define a Public variable named gvarBreadcrumbs, type Variant, in a
standard module. In the same module, create this function:

Public Function fncBreadcrumbs() As String
fncBreadcrumbs = gvarBreadcrumbs & vbNullString
End Function

+ In every main form (not subforms), place an text box named
txtBreadcrumbs with these properties:

Control Source: =fncBreadcrumbs()
Tab Stop: No

+ Also in every main form, put code like this in the form's Open event:

gvarBreadcrumbs = (gvarBreadcrumbs + " -> ") & Me.Name

+ The only thing that's left is a public function that figures out what
form to go to, based on where you clicked in txtBreadcrumbs. You would
call this function in the Click event of txtBreadcrumbs, and you would
pass it [txtBreadcrumbs] and [txtBreadcrumbs]. [SelStart]. In other
words, the OnClick property of txtBreadcrumbs would be set to

=fncFollowBreadcrumbs([txtBreadcrumbs], [txtBreadcrumbs].[SelStart])

The function's signature would look something like this:

Public Function fncFollowBreadcrumbs( _
BreadcrumbTrail As Variant, _
Crumb As Integer)

' The code that goes in here would do the following:
' (1) Use the Split function to get an array of the
' forms in the list.
' (2) Figure out from the SelStart value passed as
' the argument "Crumb", which of the forms
' in the array was clicked.
' (3) Modify the global variable gvarBreadcrumbs to
' truncate it after the form that was clicked.
' (4) Close all forms following that form in the
' array.
' (5) Open the form that was clicked.

End Function

Clearly, the code for the function is not trivial to write, but it
should be feasible. Different ways of storing the breadcrumb trail
might make it easier; for example, storing the trail as an array or a
collection, and only building the text string on demand. I haven't
thought this through completely. It may also be better to set the
user-interface part of this up as a subform that you could simply insert
in a form to get all the functionality. The whole thing is a bit
tricky, though well worth pursuing if you have the time.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


.

 

[Dirk Goldgar]

Hi Yoda,

This was an interesting question by Jan so I've been
watching the responses. I was hesitant about offering a
suggestion since I have no idea how to actually implement
the solution.

But anyway, the first thought that came to my mind was to
have a small table used to store the loaded forms. One
field would be text to display the name of the forms. The
other field would be a number field that would increment
by one each time another form is loaded using DMax.

This is certainly a workable approach.

The first record in the table would be the Main
Switchboard form and have the number be one. That record
would never be deleted since that should always be
available???

Conceivably. Since each form would add itself to the forms-called
stack, however implemented, this makes a certain amount of sense. On
the other hand, this logic depends on exactly how one wants the
breadcrumb-trail to work. Should the current form be displayed, or only
those forms below it on the stack?

On each form there would be a list box or combo box that
lists the loaded forms. Somehow using your functions the
records would be created/deleted as needed. Clicking on
the list box/combo box would open that form. Each form's
activate event would requery the table.

I thought about a list box or combo box but I think a list box would
occupy too much real estate, and a combo box would require too much
user-interaction (IMO). I also though of a subform with a fixed set of
command buttons or labels, shown or hidden as needed, with their
captions modified on the fly. But that has built-in limits and I think
it would be a little too complicated for Jan to build.

Also, wouldn't the public variable information be "lost"
if an error was encountered?

Only unhandled errors, and not at all in an MDE. If one programs to
handle all errors it won't be a problem, and if an unhandled error
*should* get through, a failure of this UI device may not be such a big
deal -- and is probably the least of your worries. I can't say I've
given it a lot of thought, though. Using a table to manage the stack,
of course, would largely eliminate such concerns, at a probably
undetectable cost in performance and possibly greater bloating in the
database.

Just some thoughts I had. Obviously this is way beyond my
experience level, but I thought I'd offer the ideas for
the melting pot.

Good ideas, Jeff. This could be a nice UI element, if we come up with a
good solution.

 

[Jan Il]

Hi Jeff and Dirk!

I will put my comments in below ;-)

This is certainly a workable approach.


Conceivably. Since each form would add itself to the forms-called
stack, however implemented, this makes a certain amount of sense. On
the other hand, this logic depends on exactly how one wants the
breadcrumb-trail to work. Should the current form be displayed, or only
those forms below it on the stack?

As far as how the forms would be displayed, if I am understanding this
correctly, if the user is in the target form, it is already displayed if the
user is in that form, so the only form that would need to be displayed after
clicking on the control, would be the form selected to return to. As an
example; I'm in the Inspections Due form, and I don't need to do any more
searching for that function, and I want to go back to the Main Switchboard
to go to another activity. I would simply click on the Main Switchboard
selection and it would close the current form and open the Main Switchboard.
None of the other forms in the current Breadcrumb Trail would be needed any
further, so all other forms in that *trail* do not need to be displayed and
are to be
deleted from the list.

All Breadcrumb Trails lead to Rome. And the Opening Page is Rome. ;-) The
Opening Page is the first form the user will be in when the DB is opened.
This should be the first form in the Breadcrumb list (table) or 1, as Jeff
suggested. From this form the user opens the next form, the Main
Switchboard. From the Main Switchboard, the user then selects a function or
activity to perform from the various command buttons here. Thus, the Main
Switchboard is the *hub* from which all activities are generated. While the
user may not need to go back to the Opening Page until it is time to exit
the DB, it should be shown in the BT at all times so that there is a clear
and complete trail. Additionally, the Main Switchboard should also remain in
the list at all times. Does this make any sense? Or is my thinking off base
on this?

I thought about a list box or combo box but I think a list box would
occupy too much real estate, and a combo box would require too much
user-interaction (IMO). I also though of a subform with a fixed set of
command buttons or labels, shown or hidden as needed, with their
captions modified on the fly. But that has built-in limits and I think
it would be a little too complicated for Jan to build.

'k...here is just something that comes to my mind, and being as I am
definitely way over my head and experience, this is just sort of thinking
out loud, and perhaps a stretch. But, like Jeff, thought I'd throw it into
the pot. <g> Could there be a series of labels in a subform, each with a
name/number/ (?), set up to be invisible until it is filled with the name of
a form in the list? Then, when the user wanted to return to another form in
the list, they would click on that label, and all other forms, except the
Opening Page and Main Switchboard, would be deleted from the list. When the
new form is opened, it would only display the new BT. This would mean there
could be several different BT's created as the user performs various tasks.
Now, using the names/numbers of the controls in the subform on each form,
the various forms of each new BT would be displayed in however many controls
needed to complete the BT to the target form. Eh....did I get lost here
somewhere? Hope some of this is making sense.

Only unhandled errors, and not at all in an MDE. If one programs to
handle all errors it won't be a problem, and if an unhandled error
*should* get through, a failure of this UI device may not be such a big
deal -- and is probably the least of your worries. I can't say I've
given it a lot of thought, though. Using a table to manage the stack,
of course, would largely eliminate such concerns, at a probably
undetectable cost in performance and possibly greater bloating in the
database.


Good ideas, Jeff. This could be a nice UI element, if we come up with a
good solution.

Thank you Dirk. And thank you, Jeff, for your interest and input. I really
appreciate it. Your suggestions have given me food for thought.
And.....it's lunch time..<VBG>

Jan

 

[Jan Il]

Hi Dirk!

Hi all - Access 2002 XP, Windows ME

I currently have controls on all my forms for users to click which
takes them back to a specific form, such as the previous filter form
or perhaps the Main Switchboard. However, there are times when it
would be very helpful, and efficient, if they could return to any
point at any time by clicking on the form they want to return to as
needed.

What is would like to do is have the name of each form they went to
in the process of reaching the current form listed in the footer of
the form, so that they can select which form they wish to return to.
The current return control is coded to go back to the previous source
form, in case they need/want to make another selection from that
form. But, if they are finished, they could return to any other form
in the 'Breadcrumb Trail' in the footer, and close all the other
forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to
go back to the Wayside Inspections form to select another piece of
equipment, they could select one of the other forms in the ''trail',
which would take them directly back to that form, and close any forms
still open at the same time. I think I can figure out the how on the
controls, but, how should I set up the controls to do this? This
would be put on all forms in the DB that where this process would be
needed.

Sorry if I'm not explaining very well, but I'm trying. <g>

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

Jan -

This is an interesting idea. I haven't tested this out, but I believe
you could do something like this:

+ Define a Public variable named gvarBreadcrumbs, type Variant, in a
standard module. In the same module, create this function:

Public Function fncBreadcrumbs() As String
fncBreadcrumbs = gvarBreadcrumbs & vbNullString
End Function

+ In every main form (not subforms), place an text box named
txtBreadcrumbs with these properties:

Control Source: =fncBreadcrumbs()
Tab Stop: No

+ Also in every main form, put code like this in the form's Open event:

gvarBreadcrumbs = (gvarBreadcrumbs + " -> ") & Me.Name

+ The only thing that's left is a public function that figures out what
form to go to, based on where you clicked in txtBreadcrumbs. You would
call this function in the Click event of txtBreadcrumbs, and you would
pass it [txtBreadcrumbs] and [txtBreadcrumbs].[SelStart]. In other
words, the OnClick property of txtBreadcrumbs would be set to

=fncFollowBreadcrumbs([txtBreadcrumbs], [txtBreadcrumbs].[SelStart])

The function's signature would look something like this:

Public Function fncFollowBreadcrumbs( _
BreadcrumbTrail As Variant, _
Crumb As Integer)

' The code that goes in here would do the following:
' (1) Use the Split function to get an array of the
' forms in the list.
' (2) Figure out from the SelStart value passed as
' the argument "Crumb", which of the forms
' in the array was clicked.
' (3) Modify the global variable gvarBreadcrumbs to
' truncate it after the form that was clicked.
' (4) Close all forms following that form in the
' array.
' (5) Open the form that was clicked.

End Function

Clearly, the code for the function is not trivial to write, but it
should be feasible. Different ways of storing the breadcrumb trail
might make it easier; for example, storing the trail as an array or a
collection, and only building the text string on demand. I haven't
thought this through completely. It may also be better to set the
user-interface part of this up as a subform that you could simply insert
in a form to get all the functionality. The whole thing is a bit
tricky, though well worth pursuing if you have the time.

I have set up a test DB, and have set up the codes and control on one of the
forms as suggested above. I am using a copy of the working MOW db so that I
will have a working app that this will ultimately be applied to. I will use
the actual forms and tasks so that I have real a platform to work with and
can tell if each function is going to work properly in actual use. This will
make it easier for me to see how all things are going to relate.

Thank you for your help,

Jan

 

[Jeff Conrad]

Hi Yoda,

Conceivably. Since each form would add itself to the forms-called
stack, however implemented, this makes a certain amount of sense. On
the other hand, this logic depends on exactly how one wants the
breadcrumb-trail to work. Should the current form be displayed, or only
those forms below it on the stack?

I assumed that the current form would not be displayed in the
call stack as it seems to go against the "back" routine.
"Back to the form I'm on???"

I thought about a list box or combo box but I think a list box would
occupy too much real estate...

True, very true.
I could see where that would present a problem on some forms.

...and a combo box would require too much
user-interaction (IMO).

Yes I can see your point now on that one.
Didn't even think of that.

I also thought of a subform with a fixed set of
command buttons or labels, shown or hidden as needed, with their
captions modified on the fly. But that has built-in limits and I think
it would be a little too complicated for Jan to build.

Well that would certainly look slick, but yes, complexity could be an issue!

I also had a very similar thought as well.
I thought maybe creating some command buttons in each form's header
that would be hidden/shown based on the values in the table.
The maximum number of command buttons ever needed would be
created at design time. The caption of course would display the form stack.
These would be put horizontally across the top to minimize
form real estate needed.

Only unhandled errors, and not at all in an MDE.

I was aware of that, but I was pretty sure Jan doesn't use MDE for the MOW.
I could be mistaken.

If one programs to handle all errors it won't be a problem, and if an unhandled error
*should* get through, a failure of this UI device may not be such a big
deal -- and is probably the least of your worries.
True.

I can't say I've given it a lot of thought, though.
Using a table to manage the stack, of course, would largely eliminate
such concerns, at a probably undetectable cost in performance and
possibly greater bloating in the database.

It was just my first thought on using a table.
Since I have much less coding experience the options I
think of are more limited.
Heck, to me an array is some sunlight coming through the window!

Good ideas, Jeff. This could be a nice UI element, if we come up with a
good solution.

WE????!
You do realize who you are talking to right?! <vbg>

I have a question and I honestly do not know the answer:
Can you fill a label or text box with values from a table
by stringing them together?

Jeff Conrad
Bend, Oregon

 

[Dirk Goldgar]

WE????!
You do realize who you are talking to right?! <vbg>

My padawan learner? But really it's Jan's idea, with input from
SFAxess, you, and me -- so far. No knowing who else might jump in.

I have a question and I honestly do not know the answer:
Can you fill a label or text box with values from a table
by stringing them together?

Sure. Suppose you have a function along these lines:

'---- start of example function ----
Function BreadcrumbTrail() As String

Dim rs As DAO.Recordset
Dim strTrail As String

Set rs = CurrentDb.OpenRecordset( _
"SELECT FormName FROM Breadcrumbs " & _
"ORDER BY SeqNo")

With rs
Do Until .EOF
strTrail = strTrail & " => " & !FormName
.MoveNext
Loop
.Close
End With

Set rs = Nothing

BreadcrumbTrail = Mid$(strTrail, 5)

End Function
'---- end of example function ----

Then you could have a calculated text box that calls the function in its
ControlSource:

=BreadcrumbTrail()

Or you could set a label's caption or a text box's value in code by
calling the function:

Me!lblBreadcrumbs.Caption = BreadcrumbTrail()
or
Me!txtBreadcrumbs = BreadcrumbTrail()

So your idea of using a table is certainly not ruled out.

 

[Jan Il]

Hi Jeff!

Well that would certainly look slick, but yes, complexity could be an

issue!

Perhaps...but, I don't want to discount any reasonable or workable solution.
If I have to learn how to do it then I learn how to do it. I'm looking at
an overall method that can be used as a standard for all apps where this
type of navigation might apply. Which, in my current line of work and
industry of development, would most likely be all, not just this particular
app. I chose to use a copy of the MOW db for this exercise, as it is the
most complex and extensive, and will, IMHO, offer the best platform for
developing this type of navigation procedure. If it will work with this db,

I also had a very similar thought as well.
I thought maybe creating some command buttons in each form's header
that would be hidden/shown based on the values in the table.
The maximum number of command buttons ever needed would be
created at design time. The caption of course would display the form stack.
These would be put horizontally across the top to minimize
form real estate needed.

I don't think that it would be a good idea, for the MOW db anyway, to add
the Breadcrumb Trail to the headers. In many of my forms I have detailed
information in the top of the form to be reviewed by management personnel,
such as calculations for one or more fields, date periods, and text
information, as well as some command buttons for specific functions. Some
are already pretty busy up there. For my forms, if a subform is not used, I
would prefer that the BT's be in the footer area, or at least lower portion
of the form. This will keep the BT visible, but, out of the way of normal
business until such time as the user needs it. The distinct red 'Exit'
labels at the top of each form allows the user to navigate back to the
previous form to conduct further activities with the current form, unless
they need to leave the immediate activity, they will not need the BT.

I really don't think it is a good idea to have the BT's too 'in their face',
as I would not like the users to get into the habit of using the BT to
navigate between the current activity function forms. This might lead to
someone accidentally hitting the wrong selection. Thus, I would prefer the
BT to be located in as out of the way area as possible. To be used only as
needed.
Additionally, regarding any type of entry forms, the form can not be closed
if there are incomplete entries or unsaved records. Error messages are
called to instruct the user to either Cancel or complete the entry, or
Cancel or Save a record. However, perhaps I'm not seeing the picture too
clearly, as I am not that experienced with all the various techniques of
building forms. Any thoughts or suggestions on this?

<snip>

Jan

 

[Jeff Conrad]

Hi Yoda,

My padawan learner?

ROFL!!

Sure. Suppose you have a function along these lines:

'---- start of example function ----
Function BreadcrumbTrail() As String

Dim rs As DAO.Recordset
Dim strTrail As String

Set rs = CurrentDb.OpenRecordset( _
"SELECT FormName FROM Breadcrumbs " & _
"ORDER BY SeqNo")

With rs
Do Until .EOF
strTrail = strTrail & " => " & !FormName
.MoveNext
Loop
.Close
End With

Set rs = Nothing

BreadcrumbTrail = Mid$(strTrail, 5)

End Function
'---- end of example function ----

Then you could have a calculated text box that calls the function in its
ControlSource:

=BreadcrumbTrail()

Or you could set a label's caption or a text box's value in code by
calling the function:

Me!lblBreadcrumbs.Caption = BreadcrumbTrail()
or
Me!txtBreadcrumbs = BreadcrumbTrail()

So your idea of using a table is certainly not ruled out.

Well that sounds cool.
I'll definitely have to test this out.

Just some other random thoughts I had:
1. What about creating toolbar buttons to use as the call stack?
So the buttons would look like this horizontally:
Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>
(With the arrow as well)

I think you can create/delete toolbar buttons at runtime correct?
I've never done that at runtime.

The advantage of this is no form real estate needed at all.
Would this be a serious drain on resources?

2. What about a Menu Bar with the word "Back" on it just like Internet
Explorer?
The drop down arrow displays the call stack.
The very bottom option would always be Opening Page.

Again no form real estate and the interface is already what people are used
to.

3. A text box or label just like you suggested to display the call stack,
but a checkbox to hide/display the box next to it.
As Jan wants it to not interfere too much it could be hidden or viewed at
will
by the user.

Jeff Conrad
Bend, Oregon

 

[Jan Il]

Hi Dirk,

I currently have controls on all my forms for users to click which
takes them back to a specific form, such as the previous filter form
or perhaps the Main Switchboard. However, there are times when it
would be very helpful, and efficient, if they could return to any
point at any time by clicking on the form they want to return to as
needed.

What is would like to do is have the name of each form they went to
in the process of reaching the current form listed in the footer of
the form, so that they can select which form they wish to return to.
The current return control is coded to go back to the previous source
form, in case they need/want to make another selection from that
form. But, if they are finished, they could return to any other form
in the 'Breadcrumb Trail' in the footer, and close all the other
forms at the same time.An example:

Opening Page> Wayside Menu> Wayside Inspections> Inspections Due>

The final form would be the Inspections Due. If they did not need to
go back to the Wayside Inspections form to select another piece of
equipment, they could select one of the other forms in the ''trail',
which would take them directly back to that form, and close any forms
still open at the same time. I think I can figure out the how on the
controls, but, how should I set up the controls to do this? This
would be put on all forms in the DB that where this process would be
needed.

Sorry if I'm not explaining very well, but I'm trying. <g>

I would truly appreciate any suggestions on the best way to do this if
possible.

Best regards,
Jan

Jan -

This is an interesting idea. I haven't tested this out, but I believe
you could do something like this:

+ Define a Public variable named gvarBreadcrumbs, type Variant, in a
standard module. In the same module, create this function:

Public Function fncBreadcrumbs() As String
fncBreadcrumbs = gvarBreadcrumbs & vbNullString
End Function

+ In every main form (not subforms), place an text box named
txtBreadcrumbs with these properties:

Control Source: =fncBreadcrumbs()
Tab Stop: No

+ Also in every main form, put code like this in the form's Open event:

gvarBreadcrumbs = (gvarBreadcrumbs + " -> ") & Me.Name

+ The only thing that's left is a public function that figures out what
form to go to, based on where you clicked in txtBreadcrumbs. You would
call this function in the Click event of txtBreadcrumbs, and you would
pass it [txtBreadcrumbs] and [txtBreadcrumbs].[SelStart]. In other
words, the OnClick property of txtBreadcrumbs would be set to

=fncFollowBreadcrumbs([txtBreadcrumbs], [txtBreadcrumbs].[SelStart])

The function's signature would look something like this:

Public Function fncFollowBreadcrumbs( _
BreadcrumbTrail As Variant, _
Crumb As Integer)

' The code that goes in here would do the following:
' (1) Use the Split function to get an array of the
' forms in the list.
' (2) Figure out from the SelStart value passed as
' the argument "Crumb", which of the forms
' in the array was clicked.
' (3) Modify the global variable gvarBreadcrumbs to
' truncate it after the form that was clicked.
' (4) Close all forms following that form in the
' array.
' (5) Open the form that was clicked.

End Function

Clearly, the code for the function is not trivial to write, but it
should be feasible. Different ways of storing the breadcrumb trail
might make it easier; for example, storing the trail as an array or a
collection, and only building the text string on demand. I haven't
thought this through completely. It may also be better to set the
user-interface part of this up as a subform that you could simply insert
in a form to get all the functionality. The whole thing is a bit
tricky, though well worth pursuing if you have the time.

Don't know if you might get back this far, if not, that's fine. Just wanted
to do a bit of follow-up. I have been sampling with formats that might work
for my forms. As a standard, there should be 4 form controls in the
Breadcrumb Trails, but, there could be up to 6 in some instances.

I have set up a sampling in the footer of a form called frmVehInspDue, a
copy of one of the standard forms, to use as a test. This should not impact
the body of the form, and if the code in the controls is a standard
function, the could be applied to all the forms. I have also sampled with a
subform, but....thoughts still out on this.

I'll keep trying.

Jan