how to simulate AFTER dirty event

hey guys,

i would like to have an AFTER dirty event but on dirty is actually just before it's dirty - that's why we have the cancel.

how do i simulate the AFTER dirty event?

here's what i'm trying to achieve.

1) form is continuous form and form's me.allowadditions is false
2) user clicks a button "Add Row" and me.allowadditions becomes true
3) here's the problem:

when the user dirties the form, and the control's value is already updated, i want to automatically set the me.allowadditions to false again.

so from a UI perspective, the user sees that he / she clicks on "Add Row", when they start typing in the control or selecting a value from the combobox and the value is committed to the control, there is no extra row below that suddenly pops up.

if allowadditions is true, everytime we add a row, another row below will immediately appear. i want to stop that extra row from popping up.

essentially, when the user wants to add a row, i want him / her to always have to click on "Add Row".

how can i achieve this guys? thanks!! = ))

P.S. i cannot insert a me.dirty = false in the on dirty event because me.dirty is already false in the on dirty event - once again thus the option to cancel the dirtying of form
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
essentially, when the user wants to add a row, i want him / her to always have to click on "Add Row".
Set the form to "AllowAdditions = False", then set that back to true in the AfterInsert event, which fires when a New Record is first dirtied.
developingprogrammerAuthor Commented:
hi LSMConsulting, i tried that previously already and the event only fires after i've dirtied the form and am moving to the next form.

Before Insert --> Before Update --> After Update --> After Insert

i need something that will fire after the first control (any control) is updated so that i can set allowadditions to false
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
BeforeInsert is the earliest Form event you'll find with New records (other than the Current event, of course). The event trail goes like this:

Current (form) ¿ Enter (control) ¿ GotFocus (control) ¿ BeforeInsert (form) ¿ AfterInsert (form)

From here:

But I still don't see the issue with this. You wanted to force the user to click a button to add a new Row, and then disable that feature when the user enters data in any control. The Form's BeforeInsert event should do that, I would think.

You could try the Form's Current event and check the state of the record:

Me.YourButton.Enabled = Not Me.NewRecord

That would toggle the button.
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

developingprogrammerAuthor Commented:
hi LSMConsulting, i've been testing a lot before i posted and i also tried again after you posted but it doesn't work. does it work for you? if it does and it's not too much trouble, could you post a basic demo database?

yup i can disable the add button when i'm at a new record no problem, but i want to prevent the additional line from appearing when i type for the first time in the new form's control.

here's my demo database where the events you mention doesn't work to achieve the results i'm hoping to get. perhaps i'm doing it wrongly, if i am i'm more than happy to be corrected!

thanks LSMConsulting
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
but i want to prevent the additional line from appearing when i type for the first time in the new form's control.
Perhaps when the user clicks the AddNew button you do this:

Me.AllowAdditions = True
DoCmd.GoToRecord , , acNewRec
Me.Dirty = False
Me.AllowAdditions = False

You'd probably have to do something else with this, like set focus to the control, or dirty one of the fields, to make it work.

Other than that, have you tried using the OnEnter or GotFocus event to check for a new record:

If Me.NewRecord Then
  Me.AllowAdditions = False
End If

I would not do that. One reason is that a user which knows Access and other such database frontends knows that an additional row appears. But more important: You would need to first save the record to disable the additional row by setting AllowAdditions to false. That means, you have now an empty record which must be setup to allow that. The user cannot undo that, if he decides to not add the record and leave the form. So you must check if the record is used or not and delete it again. If the user do not leave the form but switches his PC off or cuts the network, the record will never be deleted. In the end your table is full of empty records. And for what: Just to not show this additional row? Makes no sense for me. The user can be stopped to leave the row he wants to add by using the Cancel=True in the BeforeUpdate event if there is anything missing. And if it's OK he can simply go on with the next record if he want - or leave the form.
That's why in my opinion a "Save" or "Add" button is really not needed in a continous form. The Record Selector can do the save (or by leaving the record or form), you can test the record in the BeforeUpdate event and prohibit saving or even undo the entered data like you want, that's more than enough.


Jeffrey CoachmanMIS LiasonCommented:

<No points wanted, ...really>

Just a few more notes notes and I will allow you to continue, uninterrupted, with the previous experts.

Based of your recent questions here, I think you are over-reaching a bit here on some issues that are generally no need for concern.

Sure you can "force" Access to do whatever you like.  But anytime you try to Fight/defeat/bypass/modify the Access built in functionality/events, you are in for a tough fight.
No matter what you do, another of Access's functionalists may kick in, and force you to write even more code to deal with that.
Even if you get past all of this, ...the user will inevitably always find some odd combination of moves that will cause another unwanted effect, where do you stop?

In any event...
The "new" row you see after a new record is being created has been that way for ages in Access, and once a user is accustomed to it, it is normally not a big deal.

If it really bothers you (or the user), then don't use a continuous form...
...Just use a "Single Form"  view form (to add records).
Problem solved...?

In fact, ...One of the first lessons I learned here from LSMConsulting is that if you really want "total control", you will have to take the plunge and go "un-bound" on all your forms.

In my 15 year of developing in Access, I have never had the need to go unbound.
To me, it defeats the purpose of a RAD development platform like MS Access
If I ever need this much control, it will be time to go with a product like

...again, just some hings to ponder...


Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I agree with everything Christian and Jeff said. Simply put, there are some things that need to stay the way they are, and the "New Row" is one of them. Users expect this, and when you start showing/hiding things "auto-magically" they get nervous and concerned.

In other words, just leave it alone ...
developingprogrammerAuthor Commented:
guys i'm being chased of the cafe cause they're closing early, so just a quick comment -

firstly thanks so much for all your help on this Christian, Jeff and LSMConsulting!! = ))

hrmm i think if there's one thing i can contribute to Experts Exchange it's the view of a dumb user - cause i'm a dumb user!! haha = PP

ok i think the thing here is that - user are not familiar with Access for 2 reasons. organisations are banning it like... hrmm no, not like cocaine, not like morphine... they're banning it like... badly fried chicken wings!! as shown in FMS's website article on this. so users don't have that much opportunity to interact with it.

2ndly is that users spend more time on the web and on the iphone / mobile devices than Access. and in these devices or the web, things are a lot more robust - robust meaning they can implement anything - just like what Jeff said bout VB.NET.

and what do developers do when they've got something so robust? 1 thing - they imitate the cause and effect behaviour.

why do we have buttons? so that the use sees something they can cause, such that the effect of an additional row will pop up. when they type something in it, if a new row below it pops up, they get mind boggled. they're thinking - hrmm i had to click add row for the new row to appear, but once i typed in the new row, suddenly another new row appeared below - thus negating the cause-effect rule i just observed when i clicked the add row.

"so to add a row i needed to click the add row button"
"but when i type, i did NOT need to click the add row button anymore"


well just a small thing, but yes as developers we create our own universe and that's the addictive thing about programming. we're like our own game developers - just with a valid business purpose (unless you're an angry birds developer - but then your business purpose is still dough again haha = PP  ). so we want to try and "force" our way into implementing whatever we think is good or makes sense - in that the limiting factor shouldn't be the programme or the language, but rather our skill level.

so what i wanted to do here is to follow strictly the so called "HIG" (human interface guidelines) and implement what's most human intuitive.

the workaround solution is that instead of calling the button Add - which semantically means add 1 row, i could call it - "Allow Additions". that semantically makes a link with the user and thus problem solved - sorta. haha - but just annoying that we as the developer can't get our way!!!!!!! (i thought of inserting an empty record, if the button is pressed again, will check for empty record using dmax, looping fields through recordset, then if all fields null except autonumber then delete - and before form closing also delete all empty records using that logic - but yes, it's quite a chore haha). ARGH!!!! = PP
developingprogrammerAuthor Commented:
i have been officially chased out of the cafe. hahaha
developingprogrammerAuthor Commented:
oh guys! sorry i forgot to mention the crucial point! i can't use VB.NET cause organisation doesn't allow. Access is already REALLY pushing the limit. unbelievable huh. haha = )
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I think your assumptions are wrong regarding the way users interact with data. Microsoft (and many other companies) spend a ton of money doing UI testing, and the paradigms they come up with are generally the ones that are most acceptable for users. Granted they sometimes force things on users (like the Ribbons), but overall the concept of "type data in a row to add a new one" is fairly consistent across the desktop platform.

You could use an unbound form to do this, but that would require quite a bit of effort on your part.
developingprogrammerAuthor Commented:
ok got it! thanks LSMConsulting!! = ))
developingprogrammerAuthor Commented:
so in conclusion i think the closest to getting this effect of 1 additional row only is

1) like what LSMConsulting said - use unbound forms,
2) add an empty record as Christian mentioned (but we'll have to delete it if the user doesn't use it - troublesome)
3) the much lesser work around i suggested - change the button name to "Allow Additions".

thanks guys!!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jeffrey CoachmanMIS LiasonCommented:
...Or just use a single view form....
developingprogrammerAuthor Commented:
Hrmm but single form won't have the rows view I'm looking for.

BUT, yes we can use single forms too to achieve this!! = )) thanks Jeff!! = ))
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I don't think anyone is saying "Do it the way Microsoft/IBM/Oracle/Google etc does it". I think we're saying don't interject your own personal likes/dislikes into the mix, and don't try to munge one platform into another (see Windows 8 on a non-touch screen environment for an example of this). The desktop platform is NOT the mobile platform, and the way the two are used have enough differences that you can't automatically conclude that "It's done on my phone that way, so that's the right way to do it" (or vice-versa).

Regardless of the death-knell being sounded from the Wired crowd, the PC desktop isn't going anywhere anytime soon. Granted there aren't going to be any real improvements in it other than perhaps the addition of touch screen monitors (which are just not suited for the environment) but the old keyboard+mouse interaction is here to stay for a while yet - so don't discount the tried-and-true paradigms that have been put in place by YEARS of usage.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"the PC desktop isn't going anywhere anytime soon"
I could not agree MORE.
developingprogrammerAuthor Commented:
agree guys! i'll keep that in mind for all form i build moving forward! thanks guys!! = ))
developingprogrammerAuthor Commented:
whilst i agree very much with what Jeff, Christian and LSMConsulting said, i did read one of harfang's article (and gustav has said that harfang is NEVER wrong haha = P  ) where he said:

"However, I was looking over the shoulder of a user the other day, much younger than myself, and she was obviously looking for a way to clear a combo box using the mouse. This is quite logical, now that I've seen it, and it does make perfect sense to offer an additional option to clear the selection in a combo, besides the [Del] key that it. When the option was added in the next update, it was felt as an improvement."

so i think yes Microsoft and other companies have invested a lot into UI testing (and failed quite terribly despite having the first mover advantage for ages - couldn't create a smartphone market Apple did) but if big blue and all the corporations are right, then it's the end of our evolution and we're ready to pop the pill and sleep forever = P reeeeebelll!! = ))   = PPP
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.