Unable to return to Form (1 Viewer)

[Matt Greatorex]

I have a form, containing a subform.

The form displays various fields for the user to enter order details.

The subform is populated with all previous deals for the person whose deal is being recorded. This subform is purely for display purposes and the data shown cannot be edited.

The problems I have are:

1) When a user clicks anywhere on the subform. They can tab through the fields or scroll around the subform without any problems. However, when they try to return to the main form, all controls on it appear to be locked.

2) Clicking on the subform removes focus from the main form, so saves the record being edited on the form. This is a big problem, as the order may be in error and/or incomplete. I only want the user to be able to save or cancel the record, using specific buttons on the main form.

Is there any property for the sub form I can set to prevent the above from happening?

Thanks in advance.

 

[Banana]

Sounds like there is something in subform that must be updated before it lets you move off the subform; do you have any code that may save record before it's really done? Did you suppress any errors that would have popped up?

 

[Matt Greatorex]

Thanks for the reply.

I don't specifically save the record, but I was under the impression that it would automatically be saved, unless I expressly instructed otherwise? is that not the case?

I have no error suppression on the subform, at all.

Can I set some overriding property to prevent the subform from allowing/expecting updates? I currently have it set to only allow filters (allow edits, allow additions, allow deletions and data entry are all set to No).

 

[Banana]

Yes, it is done automatically, which is why there could be problems. A common example would be if a subform had a field that was related to a lookup table, and you didn't include that field on the form, or the user didn't select a value, it'd seize up because relationship requires that a value in that field be one of value in the lookup table.

Hmm, you only want to read from the form? Even strange as the behavior you described is what I'd expect if someone was editing a subform but didn't properly save or fill in all required information. Does it works with filters off?

 

[Matt Greatorex]

With AllowFilters set to false, nothing is changed. The subform still works, but I still get locked out of the main form after clicking anywhere in the sub.

 

[Banana]

Just want to test- Does subform function okay when you open directly (e.g. without the master form)? Can you run subform's recordsource's query and edit values there?

I honestly do not know what is causing this, and since you're not editing it in anyway, there should be no reason why it's locking you out...

Unless- is there anything in subform or form that you didn't include but may be required?

 

[Matt Greatorex]

I think I've cracked it.

The inability to return to the main form was being caused by the following:
When I opened the main form, it was set to Allow Edits = True.
As long as focus stayed on that form, it worked just fine.
As soon as it lost focus, the record was being saved automatically, meaning that when I tried to return to it, I was editing an existing record, as opposed to inserting a new one (as i mistakenly thought).
What I added was a command to return focus to the main form and set it's AllowEdits property to True, whenever a user clciked on the subform.
This works great.

The fact that an incomplete record was being saved I was able to get around by altering the code behind the <Cancel> button, on the main form.
Now, instead of just undoing any changes made it also checks to see if a record with that unique ID number has already been saved. If so, it deletes it.
Not as good as preventing the save in the first place, but indistinguishable to the user and no overhead, time-wise.

Thanks again for your comments, they definitely led me down the right path. Amazing how somebody suggesting something can get you thinking along different lines?

 

[Banana]

Glad you got it working.

However, I'm bit worried that the solution may create more problems down the road; under normal circumstances, you don't have to save record on the master form to go between subform and master form.

If you wanted, you would want to try and test if you can structure the master form so you can change focus between master and sub form without the workaround you described.

If not, at least you know what to expect.

 

[Matt Greatorex]

If you wanted, you would want to try and test if you can structure the master form so you can change focus between master and sub form without the workaround you described.

That's the plan, but unfortunately there's a lot to get done in a short time, at the moment. I've noted it and shall return to it as soon as possible.

 

[Matt Greatorex]

Okay, back to this problem sooner than expected.

To recap, I have a form and a subform. The subform shows all previous deals for an individual while the form is used to enter a new deal. To save entered information, the user clicks on a <Save> button.

However, if the user moves from the form to the subform, by clicking on any of the fields therein, the record being entered is automatically being saved. Is there any way to prevent this from happening?

 

[Banana]

I would think that is expected behavior. Access always save records in events like this. If you do not want that, you would want to use Ghudson's Mousetrap to catch that and move user back to the form and complete it before going into subform.

 

[Matt Greatorex]

The mousetrap led me to what I needed.

Certain fields are mandatory, certain fields aren't. I set a check in the before update event to see if these fields have been completed. If not, the user isn't allowed to leave the main form.

Thanks for the help.

 

[Banana]

Glad to help.