I'm trying to use the event when a person moves to a different form by
clicking on the built in Access application tabs.

Is there something I can reference or does it require some kind of
subclassing/hook api calls?


Thanks

On Jul 21, 9:47*pm, "christianlo... (AT) yahoo (DOT) com"
<christianlo... (AT) yahoo (DOT) com> wrote:
Hi Christian,

You can use the OnDeactivate event.

Imb.

Hello Imb,

Aha. Now I am forced to make an event for each form. Trying to
automate what tab the ribbon moves to based on the access application
tab.

Okay, thanks.

Access could use a rewrite of it's event system imho. There are no top
level application events to tap into, no 'after delete' event, record
saves w/ a 'dirty=true', it's all quite ridiculous.

I was hoping the new table events would be the solution but they come
up w/ this 'data macro' crap where there doesn't seem to be any way to
call your own code on the event.

Sometimes I wonder if the ms developers ever use Access.

However, I love the report and form design improvements.

<christianlott1 (AT) yahoo (DOT) com> wrote

You don't have write a event for each form, put a function or a sub in a
module and call it from the form. Enter "=YourFunctionName()" in the
deactivate event .

What would those events look like? Would you put after delete and record
save code in both the form and the application events? How would the
application events know which form or report to control? With the current
event model the form manages the data. When you click a tab you get Control,
Record and Form events on the form you are leaving and Form, Record and
Control events on the form you are entering.

Yes you are right, but that is in effect inserting an event stub in
each form/report, even if it is just to call the same routine. The
more direct way is to be able to use an application tab event. That
way you don't need to remember to insert that de/activate event stub
in each new form/report. I will be walking away from this db at some
point but the users may still be creating new reports and will have to
remember this (arbitrary) formality.


I initially intended the form event, but at the application level
could be useful as well. At present I create a right-click/context
menu to delete the record AND hook into the delete key down event to
call a routine that deletes the record. I need to do some post delete
re-querying of the form so it updates correctly. OnDelete cannot re-
query the form AFTER the delete.


Well, if you used an application level AfterDelete (or any other
application level event) it would apply to ALL open forms (etc).


Say you have two forms viewing the same table open in two tabs. You
type in the first form, tab (click) to the next form. Now try typing
data in the second form. You can't. The data is still locked from the
first edit. You must detect (on the de/activate of Each form) when it
is de/activated and save the previous record before editing the new
form because it won't automatically save. And to save that record we
get to the 'dirty=true/false' silliness. And I say it's silly because
there is no form/control level auto-save method.



Not saying it's completely wrong, I'm just saying it can be more
orthogonal AND allow the developer to tap into the higher level event
system that is already there, just not exposed to us.

<christianlott1 (AT) yahoo (DOT) com> wrote

Not only a new programmer but also you after a number of years of not
working the the application. That is why you document the application and
test changes.

I don't understand what a application delete event could do that a form
delete event could not do better, unless you are allow users to edit the
tables; which is not a best practice in Access. If you need some code to run
after any delete, like logging, call a module level function.

I would think you would want to verify the data before using it in the 2nd
form. Just like if a 2nd user wanted to edit the data on that record.
Holding the user on the 1st form and showing them an error message would be
less confusing then seeing the error from the 1st form displayed in the 2nd.

You may want to look at object modules. I once saw a example using object
modules to control 2 instances of the same form, allowing data to be passed
though the object. It was a booking application that allowed you to move
customers between 2 open events.

If I want a standard event to trigger for every report in the
application I shouldn't need to embed a new event in every new report.
This is common sense.

Programming is about relieving repetitive, tedious, arbitrary tasks,
not about documenting them so you can keep doing it.







Like above - if you have a standard method that must be applied to all
forms/reports or at least the majority of them - it makes sense to
have an application level event sink NOT tediously embed the same
function call in every form/report.




And an application level 'tab-click' event wouldn't be able to find
out what the last and current form and control were? Not true.



I haven't had the opportunity to explore these two demos but I think
these have something to do with what I'm wanting:

Power Tip: Use dynamic event callbacks to simplify complicated
applications
http://blogs.office.com/b/microsoft-...lications.aspx

Power Tip: Experiment with dynamic event callbacks
http://blogs.office.com/b/microsoft-...callbacks.aspx

Unfortunately, you and the architects / designers of Access have a different
view. And, now that Microsoft's emphasis seems to be on Access as an
Information Worker's end-user tool and on Access Web Apps (frontending
SharePoint), I suspect the chances that they will make such a significant
change and investment in Access forms are the proverbial two: slim and none.

On the other hand, I can't recall that, in my use of Access on a daily basis
since early 1993, I have ever suffered from lack of an event that would fire
on the opening of every report in an application, nor from an event that
would fire on the opening of every form.

What you describe as needed on any delete is provided in server databases by
"triggers", and there is some implementation of triggers in Access 2007 and
2010 in the current ACE, database engine for ACCDB and its siblings and
cousins -- as all my client work is using classic Access (2003 and earlier),
I haven't had occasion to look into those enhancements. If that doesn't work
for you, then SQL Server Express Edition is free, has somewhat more storage
capacity, and does have extensive capability for triggers.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access


<christianlott1 (AT) yahoo (DOT) com> wrote


If I want a standard event to trigger for every report in the
application I shouldn't need to embed a new event in every new report.
This is common sense.

Programming is about relieving repetitive, tedious, arbitrary tasks,
not about documenting them so you can keep doing it.







Like above - if you have a standard method that must be applied to all
forms/reports or at least the majority of them - it makes sense to
have an application level event sink NOT tediously embed the same
function call in every form/report.




And an application level 'tab-click' event wouldn't be able to find
out what the last and current form and control were? Not true.



I haven't had the opportunity to explore these two demos but I think
these have something to do with what I'm wanting:

Power Tip: Use dynamic event callbacks to simplify complicated
applications
http://blogs.office.com/b/microsoft-...lications.aspx

Power Tip: Experiment with dynamic event callbacks
http://blogs.office.com/b/microsoft-...callbacks.aspx