How does Access handle the updates on my Forms?

[The_Doc_Man]

For the Navy system that was my most recent big project, the rule was that the user had to explicitly save or cancel any inputs. I had sense whether the form was dirty and if so, to block of navigation, the upper-right X to close the form, and I had a separate CLOSE command that would go invisible if the form was dirty. I also blocked the update at BeforeUpdate so that if the user hadn't used the save button, the form (and Access) would refuse to close. I couldn't stop a shutdown due to power or certain other uncontrollable events, but the idea was that since the result had to do with system security, there could be no accidental updates.

I bring that up ONLY because it was a real P.I.T.A. to block off all of the ways that Access would support a save operation via implicit triggers. At least I didn't have to worry about Me.Dirty diddling because the users couldn't see the code. On the other hand, once I got it working right, the users actually liked the fact that they could only do what the form thought they were ready to do. The "not ready" buttons would vanish or appear based on form context. It is not for the faint of heart, but it had a relatively good "look and feel" and responded pretty well.

 

[Isaac]

That is all well and good EXCEPT that if you are running code in a form's class module, THAT is the active form.

I would disagree on that. Just because code is executing in a particular form's class module, that doesn't guarantee that it will be seen as the active form - I think the active form is more about the focus.

 

[JMongi]

Better change my sub-name to "Pot Stirrer"

 

[JMongi]

I'm certainly no expert, but I feel we might not be EXACTLY talking about the same scenarios. So, perhaps let's narrow down my broad question to a more focused one that pertains to my particular project. My project will eventually have a login, some kind of switchboard/menu for launching the various applications (right now an equipment maintenance app and a project hour tracker app). I presume I will perform some behind the scenes shenanigans to hide the switchboard upon application launch. So let's go from there assuming my project hour tracker has been launched. We now get this:

The only thing currently missing are a checkmark toggle for showing/unshowing archived projects and a "New Project" button (modal data entry form for Project creation).

Clicking on the "Edit Hours" button launches this form (cleary a work in progress):

This form is based on a query and requires the master project list to be open as it passed projID to the query to limit the results to the appropriate project.
So, now I have two open forms. To add a new task entry, I want the user to click on the plus button. This will open a third form that will look something like this:

This would be modal.

So a user would save or cancel their new task entry.
Aside from that, I'd like to provide a master edit possibility for admins to edit the individual task hours in one go (believe me, corrections from the shop floor WILL happen...wrong employee, wrong hours, etc) or delete a task entirely if it was added incorrectly.

 

[JMongi]

@Pat Hartman - I'm not sure if this was meant for this thread or not. Since your last post was a month and a half ago I thought I would ping you just in case.

Ironically, after being pulled away from this project by my primary responsibility, I'll likely be returning to this in a week or two. So it works out either way. I will parse it when I need a break from CAD work.