Solved Grab Record From Another Frm?

[dalski]

Off a previous topic which I thought I understood but don't - how can I grab a record from the sourcefrm & put it in the newHomefrm?

I want to use a buffer variable & feed the ID to the newHomefrm without opening the form & using openingArguments. The sourcefrm will already be open. I want to click btn in NewHome, then go to the already open SourceF, click on something then the selected record from SourceF will be put into the GrabbedID record in the NewHomefrm.

 

[MajP]

You probably need to explain in detail what you want to do. There are lots of ways to pull information off of a popup form. But what you show does not make much sense.
Normally the form you want to grab from is a Popup.
I do it the same way every time.

1. On my pop up I have an OK and Cancel button.
OK hides the popup
Cancel closes the popup.
2. I open the PopUp using ACDIALOG in the DOCMD.OPENFORM this stops code execution in calling form until the pop up hides or closes.
3. Once hidden or closed the code resumes in calling form.
Check to see if the form is hidden then grab the value and close the form
If closed do nothing.

Example
There are other ways too. You can trap a popup form event in the calling form and read the value.
You will see some examples here.

 

[MajP]

What the demo is trying to show is that the same code is reusable by the many different pop ups and many different controls.

 

[dalski]

Thanks @MajP, too complicated for me to grasp that demo & our previous topic I don't want to have to filter selections from the source each time. I'll have the SourceFrm open each time at the area I want. I select the item I want from the Sourcefrm & it puts it to the NewHomefrm.

A variable inside the SourceFrm/ Global Module (ideally would not be global but limited scope to the calling NewHomeFrm) which will hold the value of the selected ID from the the SourceFrm then create a new record in the NewHomeFrm & put the ID there. Like our previous topic but I don't want to have to open the form with opening arguments. I've tried simplifying so i can see how it works here. Just way too much for me to comprehend in the previous topic.

 

[MajP]

Here is a simple hard-wired solution. Not something I would do, but will work

Private Sub cmdSend_Click()
  If CurrentProject.AllForms("newhomef").IsLoaded Then
    If Not IsNull(Me.ID) Then
      MsgBox "Pushing selected ID, " & Me.ID & ", to New Home", vbInformation, "Push ID"
      Forms!newhomef.grabbedID = Me.ID
      Forms!newhomef.Refresh
    End If
  Else
    MsgBox "New Home form not loaded", vbInformation, "Not Loaded"
  End If
 
End Sub

 

[dalski]

Thanks @MajP, not really what I spec'd in the uncryptic 1st post . Don't worry about any more examples; I'm trying to learn all the ways to obtain a value.

I want to use a buffer variable & feed the ID to the newHomefrm without opening the form & using openingArguments. The sourcefrm will already be open. I want to click btn in NewHome, then go to the already open SourceF, click on something then the selected record from SourceF will be put into the GrabbedID record in the NewHomefrm.

I was Moreso trying to implement your previous example (attached) but simplified. Not wanting to offend - I think you may be being a bit cavalier with your words; I think this is flat wrong:

Normally the form you want to grab from is a Popup.
I do it the same way every time.

1. On my pop up I have an OK and Cancel button.
OK hides the popup
Cancel closes the popup.
2. I open the PopUp using ACDIALOG in the DOCMD.OPENFORM this stops code execution in calling form until the pop up hides or closes.
3. Once hidden or closed the code resumes in calling form.
Check to see if the form is hidden then grab the value and close the form
If closed do nothing.

There are other ways too. You can trap a popup form event in the calling form and read the value.
You will see some examples here.

• "a Popup" - the property of the form makes no difference in transferring values. I think you are incorrectly referring to opening forms with Opening Arguments & combining events. Setting a frm's popup property makes no difference. I think you're referring to this but this is not the words written.

2 - Opening in ACDIALOG (modal) does not stop execution whatsoever. It is the combination of the loadEvent & encapsulating the sourceFrm as a subForm, using the currentEvent to write the value of the current SubFrm record to it's parentFrm in the opening of the form which traps the event.

3 - Correct me if I'm wrong but the Calculator e.g. you kindly posted relies on events to feed values. Hard to tell as it contains 75,000 different functions/ subroutines...

The issue I face is:
There are several form selections to go through. The user often picks from the same final selection so it is frivolous to make the user select the previous other forms each time. That is the reason the previous helpful example is not as good as it can be. My thoughts were to check if it's open... I might end up opening again through openingArgs but for now i am trying to get a more coherent understanding of trapping results fed from forms. MSN article of event hierarchy is inadequate - unable to link as SPAM.
The negatives of the previous example are (which you would not be aware of as it was not portrayed in me e.g.):

1 - It relies on opening a frm causing the firing of events to trap the value desired.
2 - It creates a superfluous Subform Parent, (italic not negative) where the currentEvent feeds a buffer variable of the selected record.

 

[MajP]

• a Popup" - the property of the form makes no difference in transferring values. I think you are incorrectly referring to opening forms with Opening Arguments & combining events. Setting a frm's popup property makes no difference. I think you're referring to this but this is not the words written.

2 - Opening in ACDIALOG (modal) does not stop execution whatsoever. It is the combination of the loadEvent & encapsulating the sourceFrm as a subForm, using the currentEvent to write the value of the current SubFrm record to it's parentFrm in the opening of the form which traps the event.

3 - Correct me if I'm wrong but the Calculator e.g. you kindly posted relies on events to feed values. Hard to tell as it contains 75,000 different functions/ subroutines...

Pretty much everything you wrote is WRONG If you want help then you should spend more time listening then trying to tell me I do not know what I am talking about. I never understand this when novices do this. They come asking for help on trivial tasks then spend their efforts critiquing suggestions. It makes no sense to me why people do this. I tend to know what I am talking about..

1. If you call a form using the ACDIALOG argument. It most CERTAINLY STOPS form execution in the calling form. Do not listen to me, simply test it you self
In the calling form call Docmd.Open form
In the next line type MsgBox "Code Resumed'
Now test this using acdialog and not using acdialog and tell me when you see the msgbox. In the first case it will be immediate. The second case it will be after the called form closes or is hidden.

2. I am pretty sure I know the difference between modal, popup, and forms open in ACDIALOG. I am not referring to Open args as you suggest since the demo do not rely on. My point is that it is not a good design IMO to have two non-modal forms open at the same time where you are transferring data between each other. If you did this the code would be different than I suggest. But that is a poor design and begging for issues with data integrity. If you got to this point your database is probably not designed correctly. Most good designs have a main form with pop up modal forms so only one form can be activated and the pop up has to close. If you do it this way it drives a coding design.

3. As I mentioned there all multiple ways to pass data between forms. I provided what I believe is a very simple and flexible method.
Main form calls a modal popup.
A value can be passed in as Open Args to set default values
The pop up knows nothing about from where it was called.
The pop up can be canceled or selected (hidden or closed)
The main form reads values from the pop up if the pop up ok was selected

Flexible, lightly coupled, reuseable.

I also demonstrated the use of With Events to trap events in the called form.
WHO cares if the thing that makes the calculator work has a lot of methods. I did not even develop it, but the point was I can open it ACDIALOG and then retrieve the values. Or I demonstrated a way to use with events to grab values.
You can use with events to trap events in another form and not have to open the called form ACDIALOG. This could allow you to then set a lot of properties

 

[MajP]

Also these are just silly statements.

1 - It relies on opening a frm causing the firing of events to trap the value desired.
2 - It creates a superfluous Subform Parent, (italic not negative) where the currentEvent feeds a buffer variable of the selected record.

1. The opening of the pop up does not "fire" extra events as part of this process. Form events occur regardless. That statement does not even mean anything. For sure the code is not reliant on any opening events
2. The subform is not superfluous nor required, but a design choice. I purposely used a subform because it was a faster way than spending my time building a continuous form for a simple demo. Further it gives you all the benefits of a datasheet. You can sort and filter to find your selection. If you do not like the subform then build a continuous form. The idea would be the same though and then save the value to a class variable that can be pulled.

Again these are demos, and there are many ways this can be done. If you have more specific ways you would like it to work then need to specify.
Maybe you want a checklist where you can select multiple resources at one time. That can be done. There are all kinds of ways.

If you want something more advanced maybe something like

Faking a Multi Value Field

I have seen a few posts lately on people wanting to use multi valued fields. Most Access developers steer away from them and build their own related tables. Although they are properly normalized and work well, they can get very confusing even if you know the ins and outs. I wanted to see if I...

www.access-programmers.co.uk

Making a custom checklist that saves to a table

Good evening all! I have a need to build a checklist form. We have 19 steps that our leads have to do every engagement. Items 1-4 are pre-engagement, 5- 8 are mid-engagement, and 9- 19 are post-engagememt. I need a checklist form that saves checked items for the next time the DB is opened and I...

www.access-programmers.co.uk

 

[dalski]

Thanks, was not intended as a critique, it was a post on a forum to try to fully grasp something.

Yes it was a great solution & I am grateful; I have been studying it since you posted it trying to grasp what's going on.

Modal - Only if the form is unopen it wall cause cessation of executed code. If the form is already open, & you open the form again (default instance loaded), then this will not stop the code running. This was the 2nd sentence of the OP & the main topic of the post. There was no caveat mentioned that the form instances must be completely purged, despite only the default instance is affected in docmd operations.

I am trying to use it for this situation & will be, but have to understand it properly. Thank you for confirming that execution can be halted by modal, & not just the events. They are very powerful tools.

 

[MajP]

Opening a modal form alone does not stop code execution. Only the ACDIALOG argument does.
If you open a modal form without using ACDIALOG code execution continues in the calling form.

 

[dalski]

No - I reiterate as my previous post was unambiguous - doCmd open ACDIALOG an existing already open form (main topic of post) you'll see it does not stop execution. AGAIN I reiterate - you have to close the form, then open in ACDIALOG. Using an open form was the main topic of the post.

1. If you call a form using the ACDIALOG argument. It most CERTAINLY STOPS form execution in the calling form. Do not listen to me, simply test it you self
In the calling form call Docmd.Open form
In the next line type MsgBox "Code Resumed'
Now test this using acdialog and not using acdialog and tell me when you see the msgbox. In the first case it will be immediate. The second case it will be after the called form closes or is hidden.

 

[Pat Hartman]

@dalski You are arguing with an expert. And YOU are the one who doesn't know what you are talking about.
1. Forms don't store data. Tables store data. Get your head around this. It is an important concept and it should change the way you think about this problem.
2. When formA opens formB in dialog using the OpenForm Method, The code in formA stops until formB is closed. And if you think it doesn't, you are wrong.
3. Duplicating records in multiple tables is 99% wrong when done by novices. So, you are asking for bad advice and Maj has been patiently trying to provide it.
4. A more logical scenario is you have only formA open. You want to copy the current record showing on formA to a different table and then open formB in dialog mode to that record. If this option makes sense, let us know and someone will provide the code.
5. Telling an expert what you don't want to do - with no explanation - is just poor form.

 

[MajP]

Why would you "open" an open form? If a door is already open we do not say we re-opened it. You can't. That is not "opening" that is merely setting focus.

I already explained why in my opinion working with two non modal forms is a poor design. But up to you.

 

[dalski]

@dalski You are arguing with an expert. And YOU are the one who doesn't know what you are talking about...

Thank you for your comments, agree completely. Sorry @MajP I should've questioned if I could remove the subform in the other post rather than poorly wording it here & don't doubt your way is the best way & have implemented all your suggestions. Big thanks for all your help.

 

[MajP]

don't doubt your way is the best way & have implemented all your suggestions.

To be clear I never suggested this was the "best" way. I suggested it was a good clean and flexible way to do it. I am pretty sure I stated.

There are lots of ways to pull information off of a popup form.

I did suggest that I would never do what you show and have two non-modal forms open at the same time and allow the user to push information back and forth. To me that is not a good user experience, hard to control the flow of information, hard to ensure data integrity.
IMO if the user needs two non-modal forms open at the same time there is probably a fundamental problem in the database or just a bad UI design. If you need to constantly see the information in the other form then consider a subform on the main form.

 

[dalski]

Thanks, I'm altering my design to accommodate & you're making me aware of things which I've not accounted for; like 2 forms open at the same time which I'm changing & am most grateful for. I wouldn't even be able to load the form if it wasn't for yourself so mega thanks.

 

[MajP]

Your example was not very insightful because 99% of the time you would pull that ID using a combobox on your form. GrabbedID would be a combo with Source information. Sometimes you may want a pop up if you want to show a lot of information and maybe a lot of columns. Then I would use a popup form with a listbox. Still uses the same idea.

 

[dalski]

Thank you very much, grateful of another method of pulling values & no events behind it, very effective.