I suspect that we may not have to be 'all encompasing'. That is, I don't think that the real problem is with the select windows (because these refresh when opened - ie if you have done a customer selection for names starting 'ai' and you select one of them, and then someone else adds say 'ainsley, john', then when you press the Reselect button, Ainsley, John will be there).

I think that the problem is as you move between "screens" ie if you move from Customer|Accounts to Customers|Payments to do a payment and then back to Customer|Accounts, then the payment that you have just done does not show [until you press Find to do a refresh].

The problem here is that a screen/workspace (Customers|Account) that we have cached has become out of date because of the payment, but when you switch back to it, it is shown as it was and not refreshed.

The following algorithm may help resolve the problem.

Concept: have a table that indicates whether or not a refresh is required when a user switches to a cached workspace.

Required data structure: a table with a row for each logged on user, and a column for each workspace/screen, with each cell containing two things, a dirty flag and an identifier.  The dirty flag, if set means that the screen should be refreshed when switched to.  The identifier is something that identifies what is displayed, for the customer, patient, and supplier screens it is the customer/patient/supplier id, for the workflow scheduling and worklist screens it is the date and shedule/worklist view. [In fact one might want a primary and secondary identifier slots - for supplier|orders one might want the supplier and store location ids as the primary and secondary identifiers.]

Program logic:

1) When an update occurs (eg the customer payment), then one runs down the appropriate column (in the case the Customers|Account column) looking for any cell (ie any user row) where the id is the same as that that just updated, and if so, set the dirty flag.

2) When the user switches to a workspace/screen, check the dirty flag, if set clear it and do a find to refresh the cached information.

3) when the user logs on, create the row for the user in the table. When the log off, delete the row.

The above logic allows the cached information to be used as is where it is not dirty, and only refreshed when it is dirty.  It also handles the cases where the update is being done by the user themselves or some other user. 

Note that it might be argued that the above logic is too much of a shotgun approach, in that if someone updates a line item in an invoice for customer X, then if I am looking a customer X's Charges screen but NOT at the date range including the updated invoice, then it will flag that a refresh is required when it is not.

However, I think that the suggested approach provides a good trade-off between simplicity of implementation and achieved result.

Regards, Tim G