tfurnivall
Registered User.
- Local time
- Yesterday, 21:51
- Joined
- Apr 19, 2012
- Messages
- 81
I'm learning to use the new Navigation Form control in Access 2010. I think I like it. I have, however, run into a small problem.
I'm using the options/sub-options capabilities, with major options lined up across the top, and sub-options down the left-hand side.
At one point I need to be able to have a button on one of two sub-forms "call" another sub-form. If the target sub-form is access using the navigation buttons I want the form 'just as is", but if it is accessed from one of the other sub-forms, I have a button which will return me to the form whence I came. (Think procedures, where I call one procedure from within another, and when I exit the procedure, I know where to go back to. You probably have to be a COBOL programmer to even conceive of a procedure that can be accessed as in-line code, too - but then, history is what it is ;-)
I'm storing the calling form in the tag area of the button used for the return function. This is set up as part of the calling process. I also save the context of the calling form in the tag of the button that does the actual "call". Here's a more specific example.
Calling Button on Form 1 is called cmdCallTargetForm
Same thing for a similarly named button on Form2
The ReturnButton on TargetForm is coded as follows:
There is also much debug.printing around this.
What actually happens is that the first (calling) BrowseTo remains within the NavigationForm, and 'switches' to the TargetForm properly, including making the ReturnButton visible. The caption is properly set, and if I examine the Tag, it contains the proper return address. I also examine the ReturnContext, and during the execution of the TargetForm it is correctly set.
The problem is that on return, using substantially identical code (identical in concept, at least), rather than navigating withon the Navigation Form, Access pops up the sub-form independently. In other words, the first BrowseTo goes to the TargetForm within the Navigation Form, but the second form goes to the Calling Form as an independent form.
Obviously I am misunderstanding the way in which this is meant to work (using as my mental model the navigation within a tab control). What I don't understand is why one works, and the other doesn't!
Some things have occurred to me - but I'm at a loss to see how I can test them.
1) calling BrowseTo using a variable rather than a literal doesn't work (but if not, why did VBA accept it?)
2) The Navigation Form was never meant to be used in this way (but if not, why not? It's a perfectly rational way of using it)
3) Microsoft didn't think far enough through.....Nah, that would never be the case (!)
Any ideas?
(The db is available if wanted).
Tony
I'm using the options/sub-options capabilities, with major options lined up across the top, and sub-options down the left-hand side.
At one point I need to be able to have a button on one of two sub-forms "call" another sub-form. If the target sub-form is access using the navigation buttons I want the form 'just as is", but if it is accessed from one of the other sub-forms, I have a button which will return me to the form whence I came. (Think procedures, where I call one procedure from within another, and when I exit the procedure, I know where to go back to. You probably have to be a COBOL programmer to even conceive of a procedure that can be accessed as in-line code, too - but then, history is what it is ;-)
I'm storing the calling form in the tag area of the button used for the return function. This is set up as part of the calling process. I also save the context of the calling form in the tag of the button that does the actual "call". Here's a more specific example.
Calling Button on Form 1 is called cmdCallTargetForm
Code:
Sub Form1.cmdCallTargetForm_Click
dim ReturnContext as string
... Return Context is built using various controls ...
Me.cmdCallTargetForm.Tag=ReturnContext
' Now navigate using the BrowseTo command
DoCmd.BrowseTo acForm, "TargetForm"
Form_TargetForm.cmdReturnButton.visible=true
TargetForm.cmdReturnButton.Tag="Form1"
TargetForm.cmdReturnButton.Caption="Return to Form1"
End Sub
The ReturnButton on TargetForm is coded as follows:
Code:
Sub cmdReturnButton_Click
dim ReturnTag as string
dim ReturnContext as string ' Already available in the calling form
ReturnTag=me.cmdReturnButton.Tag
if ReturnTag="Form1" then
ReturnContext=Form_Form1.cmdCallTargetButton.Tag
elseif ReturnTag="Form2" then
ReturnContext=Form_Form2.cmdCallTargetButton.Tag
else
endif
' Now use BrowseTo to get back to the calling form
DoCmd.BrowseTo acForm, ReturnTarget
End Sub
What actually happens is that the first (calling) BrowseTo remains within the NavigationForm, and 'switches' to the TargetForm properly, including making the ReturnButton visible. The caption is properly set, and if I examine the Tag, it contains the proper return address. I also examine the ReturnContext, and during the execution of the TargetForm it is correctly set.
The problem is that on return, using substantially identical code (identical in concept, at least), rather than navigating withon the Navigation Form, Access pops up the sub-form independently. In other words, the first BrowseTo goes to the TargetForm within the Navigation Form, but the second form goes to the Calling Form as an independent form.
Obviously I am misunderstanding the way in which this is meant to work (using as my mental model the navigation within a tab control). What I don't understand is why one works, and the other doesn't!
Some things have occurred to me - but I'm at a loss to see how I can test them.
1) calling BrowseTo using a variable rather than a literal doesn't work (but if not, why did VBA accept it?)
2) The Navigation Form was never meant to be used in this way (but if not, why not? It's a perfectly rational way of using it)
3) Microsoft didn't think far enough through.....Nah, that would never be the case (!)
Any ideas?
(The db is available if wanted).
Tony