Determining cause of Update event

[RJosephNewton]

Hi Folks,

Can anybody point me to any event that riggers prior to BeforeUpdate when a subform is entered from its parent? I have a form that needs to signal its user when they are finished editing information on a single record, and offer the option of adding the current intake event to a different history table.

This should only trigger once per client, when the form is closed, or when a new client is chosen for viewing, and only if the data has been edited. The BeforeUpdate event would be perfect, except that Access is hyperactive with its updates, and does it whenever my users click into either of two subforms.

Is there any event that would fire that would trigger prior to the BeforeUpdate event that would indicate when the cause of the update was just moving into one of the subforms?



I've tried capturing the mouse position with an API call, but his lead to a lot more calls to get the window position in related terms, then more calls to the GetScrollPos functin to acount for the adjustments due to scrolling. Bandage upon bandage! It sees like there should be a more direct way.

Any suggestions? This is driving me buggy.

Joseph

[NTC]

I suppose you are being humorous to write "Access is hyperactive with its updates" as of course code is code and there is no personality involved.....

code runs linear - so do anything 'before' - you put the code before....

[RJosephNewton]

Thanks,

I'll get to the quip in a bit. The issue is where before is. I am trying to capture user-initiated events, and the question is where to find the "before" in the code. What I am looking for is either an event that triggers based on the user moving into the subform, prior to the BeforeUpdate event, or to find a way from within BeforeUpdate to ascertain what event actually triggered the update. If the event is only the user working within a contained subform, the message asking the user to commit their work shoould be suppressed, since it should only occur once each time a client screening sheet is edited for a given client, and only when the person is done for certain with the record.


As to anthropomorphic language: Well actually, behavior patterns do not rely on human motivations. The pattern displayed by Access is hyperactive. There is no logical reason to auto-commit just because the user has moved to essentially a different field within the form, so this interim commits are excessive, in my view. If therre is a point to auto-commit at all it should still only happen when the user closes the form or moves to a different record *within that forms dataset".

Joseph

[pbaldy]

Because a form and subform are normally be bound to different tables, this really isn't accurate: "the user has moved to essentially a different field within the form". The user is moving to a different table, thus the data for the form/subform being departed is committed. When moving from form to subform, the form's update events will fire if data has changed, and the subform's update events will fire when leaving the subform if data has changed.

I understand what you're saying, but while you may think of it all as one client's data, each form is bound to a different set of data (related yes, but different), thus must update when you leave the form.

Other than going to unbound forms, I don't know of any way around the main form updating when you go to the subform.