Requery tabbed documents

I've always use overlapping windows (forms) for building apps, but I thought
I'd try using the tabbed documents featrue in 2007. It has a nice clean full
feel when using the tabbed documents (forms), but one problem I've discovered
is that a user can go back to the main menu (first tab) and open other tabs
(forms), so when you edit some info on one tab and go to a different tab the
data has not been requeried, so updated info doesn't show up. Should I lock
the main menu from being accessed if another tab is open (so I can only open
one tab at a time to keep the data intact between tabs) or requery all my
forms when changing tabs? Anyone got a routine for this? On what event
should I run the requery to update info on the other tabs when moving from
one tab to another?

I don't know that there's a really simple way of doing this.

One approach is to create a function in a standard module, and call it in
the AfterUpdate and AfterDelConfirm events of every form in your database.
The function receives the name of the form that calls it and has a monster
Select Case structure so it can update any other form in the database that's
open and has a dependency on it.

I've never managed to write a routine that sorts this out automatically, as
there are too many possible dependencies to trace. You would need to trace
the RecordSource of every open form and their subforms (recursively), and
the RowSource of every combo and list box on those forms, and handle stacked
queries (queries based on other queries), subqueries, aliased tables and
expressions, and so on.

This example shows the start of the routine that updates the ClientID combo
on the frmAccount if frmClient gets a record modified or deleted:

Public Function NotifyCombos(strSourceForm As String, _
Optional iStatus As Integer = acDeleteOK)
Dim strForm As String

If iStatus = acDeleteOK Then
Select Case strSourceForm
Case "frmClient"
strForm = "frmAccount"
If CurrentProject.AllForms(strForm).IsLoaded Then
Forms(strForm)!ClientID.Requery
'...

Hope that's enough for you to follow to give you what you need.

Note the timing he if someone is editing a record on one tab (not yet
saved), the routine won't update the other forms until the edit does get
saved.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.


"Maarkr" wrote in message
...
I've always use overlapping windows (forms) for building apps, but I
thought
I'd try using the tabbed documents featrue in 2007. It has a nice clean
full
feel when using the tabbed documents (forms), but one problem I've
discovered
is that a user can go back to the main menu (first tab) and open other
tabs
(forms), so when you edit some info on one tab and go to a different tab
the
data has not been requeried, so updated info doesn't show up. Should I
lock
the main menu from being accessed if another tab is open (so I can only
open
one tab at a time to keep the data intact between tabs) or requery all my
forms when changing tabs? Anyone got a routine for this? On what event
should I run the requery to update info on the other tabs when moving from
one tab to another?

Thanks Allen... I think what I'll do for now is to just hide (close) the
menus or other tabbed forms that present a dependency problem. This project
doesn't use too many forms, but if I do a larger project, I'll stick with
overlaping windows.

"Allen Browne" wrote:

I don't know that there's a really simple way of doing this.

One approach is to create a function in a standard module, and call it in
the AfterUpdate and AfterDelConfirm events of every form in your database.
The function receives the name of the form that calls it and has a monster
Select Case structure so it can update any other form in the database that's
open and has a dependency on it.

I've never managed to write a routine that sorts this out automatically, as
there are too many possible dependencies to trace. You would need to trace
the RecordSource of every open form and their subforms (recursively), and
the RowSource of every combo and list box on those forms, and handle stacked
queries (queries based on other queries), subqueries, aliased tables and
expressions, and so on.

This example shows the start of the routine that updates the ClientID combo
on the frmAccount if frmClient gets a record modified or deleted:

Public Function NotifyCombos(strSourceForm As String, _
Optional iStatus As Integer = acDeleteOK)
Dim strForm As String

If iStatus = acDeleteOK Then
Select Case strSourceForm
Case "frmClient"
strForm = "frmAccount"
If CurrentProject.AllForms(strForm).IsLoaded Then
Forms(strForm)!ClientID.Requery
'...

Hope that's enough for you to follow to give you what you need.

Note the timing he if someone is editing a record on one tab (not yet
saved), the routine won't update the other forms until the edit does get
saved.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.


"Maarkr" wrote in message
...
I've always use overlapping windows (forms) for building apps, but I
thought
I'd try using the tabbed documents featrue in 2007. It has a nice clean
full
feel when using the tabbed documents (forms), but one problem I've
discovered
is that a user can go back to the main menu (first tab) and open other
tabs
(forms), so when you edit some info on one tab and go to a different tab
the
data has not been requeried, so updated info doesn't show up. Should I
lock
the main menu from being accessed if another tab is open (so I can only
open
one tab at a time to keep the data intact between tabs) or requery all my
forms when changing tabs? Anyone got a routine for this? On what event
should I run the requery to update info on the other tabs when moving from
one tab to another?

.