[friendlyfriend]

I didn't fix it but learned a couple things. I tried having the program modify the subform's RecordSource rather than modifying Me.Filter. That didn't fix the problem, but it did speed things up because I had separate calls for changing the Filter and OrderBy properties. Combining them into a single change of the RecordSource property really smoothed out some blinking going on while I toggle back and forth between single-form and datasheet views.

The best I could do to deal with the NewRow problem was to create this

Private Sub NewLineBugHack()
    blnSuppressCurrentEffects = True
    DoCmd.RunCommand acCmdSubformDatasheet  'switch to single-form view
    DoCmd.RunCommand acCmdSubformDatasheet  'switch back to datasheet view
    blnSuppressCurrentEffects = False
End Sub

Then I put a call to it right after Me.Undo. It's pretty quick so not really visible. I needed to use a flag to suppress the code I have in the OnCurrent event handler which would otherwise run for each of these commands.

Another thing I learned is that if you have code to modify the RecordSource property of a subform and the parent form's AllowAdditions property is set to True, the modification will go through okay but an irritating popup will appear asking you how you want to handle changing the parent form's Recordsource even though you're not touching that RecordSource. It says "to complete this operation access must modify the recordsource property of the current form" and refers to the parent form's RecordSource. You can't get around it by Docmd.SetWarnings on/off, because the default button is Yes, and ignoring means you accept the default option. This wil eliminate the first popup, but just takes you more automatically to another complex popup for creating a query.

So you have to set the parent's AllowAdditions property to False if you want to be able to edit the subform's RecordSource property. Makes perfect sense, right? :/

I really can't believe how amateur Microsoft Access seems to be sometimes.

[friendlyfriend]

Well, that didn't last long. The irritating "to complete this operation Access must" blah blah blah popup came back randomly. Then I changed the parent form's AllowFilters property to False and the problem stopped. Who knows what will happen next. Oh yeah, and a different subform just randomly started refusing to take the focus even though its Enabled property and that of its controls are all True.

How am I supposed to sell this thing with so much random behavior? Has all the qualified talent just decided not to work in the Access group?

[friendlyfriend]

I decided to just put here everything that Access is doing wrong. Maybe it will dissuade someone from getting started with it.

Today I get the message "Method Parent of object _Form_MyForm failed. I click Debug and go to the line with the problem. I click the run button and it continues merrily along. So what was the problem? Something wasn't ready. After the couple of seconds it took me to click the run button, things were ready and it worked.

This is a typical problem with Access. Race conditions are everywhere. If something takes longer to happen than other times then the sequence of events takes a totally different course - usually it is an error message appearing.

[OBP]

You are obviously having a negative experience with Access, but you should not be trying to put off others from using it.
If it is used as intended with Forms, Subforms or Split forms it does a fairly good job, not everybody wants to manipulate the forms and data the way you are trying to do.

[friendlyfriend]

Got another one...

I have a main form with multiple subforms. When the focus is in subform A, I click a box in subform B. The Current event fires for subform A, but there is no reason for it to do this. It only does this sometimes.

And another...

The vertical scroll just sometimes stops working. The mouse wheel doesn't make it scroll and the thumb ignores my clicking and trying to drag it. This only happens some of the time.

[friendlyfriend]

Why should I not be trying to put off others from using it?? This is exactly what I should be doing.

There ARE alternatives. Learning a software tool is a huge investment and choosing where to invest this time is a really hard decision to make with no omnipotent and impartial guide out there to help anyone make it. Transparent languages may be harder to learn but in the long run, it is well worth it. I did not choose wisely. It would be nice if others could learn from my mistake.

If it contains a feature and I am using the feature, then I AM using it as intended. I am using forms and subforms and have no use for split forms in this application.

Access lets you create field names containing spaces, puts fields on your forms as controls with no prefix tags, sometimes accepts references with "." and sometimes complains if you don't use "!", sometimes lets you refer to a field without a control and sometimes doesn't. Looking to Access to tell you what is the best way is kind of a joke.

But this random quirkiness is just a deal breaker that everyone evaluating platform options needs to know immediately. And they never even bothered to get it to work on a Mac. That makes about as much sense as the Berlin Wall.