I’m home and don’t have Access here. I’ll check it on Monday.Here with modified db
Thanks.
I’m home and don’t have Access here. I’ll check it on Monday.Here with modified db
See #11. In this special case, while inputting some data, the user needs some additional references to other data sets that has no relation to current data.(Tolerance limits, Surface finishes, tool standards……).I guess the question is, why do you have to move focus to a different form while you are editing the main form?
Didn’t know about that. Though we don’t need a 22 inch size form, but it’s good to know the limits.When considering options, be aware that Access forms have a displayed size limit. If you are "packing" a form with lots of sub-forms, you will be doing your best to widen the form to keep as much together in parallel. When doing so, the outermost (and therefore the widest) form will be limited to a width of 22.75 inches. Since modern displays can get fairly big, just watch out for that particular limit.
It is bad and problematic to start editing a record in a bound form and then do something completely different before finishing - perhaps the user will add a visit to the doctor?The data on the main form should not be saved until the user checks a lot of options and see if the result is acceptable (simulation, stress and other factor’s result).
The suggested unbound listbox offers that behavior. If saving the record by switching to a subform is not the behavior needed, you might want to consider deleting the saved record. Alternatively, an unbound form does not have a dirty property, but you would handle the saving process yourself.I need to click on one of the records of the subforms while the main form is dirty.
I like your posts and read every single of them. I also admire your intelligence and the way you solve problems. Your answers, specially the queries you offer has been always a surprise.perhaps the user will add a visit to the doctor?
Then you have to give them a pen and a paper and tell them to calculate first and when you have all the pieces, come back to the form and input whatever you have. Sometimes data entering is not just a simple order to type it from an order sheet. In our case, each calculation is based on previous results and the form gets dirty with first set of input.Shouldn't it be the case that when you enter a record, all mandatory entries must be present and enterable?
I think I like this idea. I‘ll do some experiments to see how it goes.A simple solution would be to use the main form for the new creation
I like to exaggerate identified problems to make them clearly visible. In this specific case, the chosen statement may not be understandable to everyone and may be misinterpreted. However, it should point out that there is a possibility that the user will not achieve a result in a timely manner or not at all with the necessary side actions. What then happens to the unfinished record?but sometimes I find your sarcastic comments hurts very bad
Hi PatI guess the question is, why do you have to move focus to a different form while you are editing the main form?
Mike didn't tell us in words what he did but it looks like he removed the subform and replaced it with a query in the ControlSource of the subform control. Therefore, the control isn't showing a subform and so the save trigger isn't activated
For the third and final time. Delete the parent forms BeforeUpdate event and you can select all the records you want in the sub-form.because the moment I click on subform, the form tries to save the record and BeforeUpdate event of the main form is fired.
If I delete Cancel=True, the main form's record gets saved. I don't want the main form's record being saved. I think I've been clear in my request.For the third and final time. Delete the parent forms BeforeUpdate event and you can select all the records you want in the sub-form.
For the third and final time. Delete the parent forms BeforeUpdate event and you can select all the records you want in the sub-form.
code in first form
....
....
domcd.openform "newform"
'pause loop
'wait for "newform" to close before continuing
while isopen("newform")
doevents
wend
Public Function IsOpen(strForm As String, Optional doctype As Long = acForm) As Boolean
IsOpen = (SysCmd(acSysCmdGetObjectState, doctype, strForm) <> 0)
End Function
Yes I understand. The whole thing here defies logic as Pat pointed out earlier. That said, I did some more experimenting and found that the OP's parent forms Data Entry property was set to Yes. With Data Entry set to Yes, you could not even scroll through the Parent form Record Source. I had no idea why someone would want to bind a control on a form and then not save it after making or editing the field. It made no sense. Then I thought OK maybe the OP wants to just scroll the Parent forms data without editing or adding or deleting anything and still select records on the sub-form. It was just a guess. So I set the Data Entry property to No, set the Allow Additions to No, set Allow Deletions to No. Low and behold you could scroll the Record Source and select records in the sub-form without triggering Cancel = Yes.LarryE, KitaYama doesn't want the main form to save when doing this selection. Selecting at least one record in the sub-form will do the unwanted action and that is the nexus of this discussion.
If you have no user-defined BeforeUpdate event, it doesn't matter - because Access DOES have its own internalized BeforeUpdate event. What did you think actually fired YOUR BeforeUpdate event? An update will occur whether or not you have any VBA in place. Just like a form will have an Open, Load, and Current event whether you added your own macro or VBA. In fact, it is possible to have a basic form with sub-forms that have no code ANYWHERE. Every event that could happen to such forms WILL happen.
Now, if you dirty the main form then switch to the sub-form, the main form data gets saved during the sequence of events triggered by the change of focus. If you then switch to a SECOND sub-form on the same main without stepping into the main, it won't matter, because the main form is no longer dirty and you don't save clean forms. BUT having no BeforeUpdate event wouldn't prevent the initial main form data save.
It is sort of like the old conundrum of "If a tree falls in a forest and no one is around to hear it, does it make a noise?" Well in this case, "If a bound form changes records but has no VBA code or macro associated defined within it, does the Current Event still happen?" In the latter case, YES. It doesn't do much - but it still happens.
I'm out of words. How many times and how can I explain it any clearer? I am EXPERIMENTING to see if it's possible to use sub forms instead of list boxes and combo boxes in a data entry form. Because list boxes can not use conditional formatting.I am still in the dark as to why the OP is doing this