Instance Of Same Form (1 Viewer)

Gasman

Enthusiastic Amateur
Local time
Today, 06:40
Joined
Sep 21, 2011
Messages
14,216
Ok now this problem has been solved
But the problem remained the subform
How can each new instance have a separate table
Use a query instead of the table directly.?
Same data though? :unsure:
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 01:40
Joined
May 21, 2018
Messages
8,516
How can each new instance have a separate table
You will have to explain that better. Obviously you do not want a separate table. Explain what the subform is and what would be different in each subform.
 

HASAN-1993

Member
Local time
Today, 08:40
Joined
Jan 22, 2021
Messages
89
Ok the problem is
When more than one instance form is opened, the records entered on the subform must be separate from the other instance form. In addition, if I use a query, this is difficult for the reason that I have complex codes that are not compatible with the query.
Even if i try to deal with the issue, what is filtering like and how will query know that it is another instance form?

Why should it be separate
Because this subform saves records temporarily until the user saves the invoice, The code inserts the records into the main table
 
Last edited:

HASAN-1993

Member
Local time
Today, 08:40
Joined
Jan 22, 2021
Messages
89
Ok the problem was solved
I used the query and were filtering according to the frm.Hwnd
But the problem remained, how to access this form
I have an account selection form
When selecting an account, it inserts it in the form, but in this case it does not find the form
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 01:40
Joined
May 21, 2018
Messages
8,516
In theory what you want to do is very simple. You open a form instance with a subform. So the form instance is filtered to a specific record and the child records would then be filtered to a set of records. Since every instance is a filtered set no instance sees the same records. It all appears like a separate "table" but each instance is just filtered.

Now you can take my advice or leave it, but in my opinion your implementation needs to get fixed. The query you showed is ridiculous. I have seen thousands and thousands of queries, but nothing that overly complex. I would get rid of that. The 5000 record subform is a poor implementation that I would also get rid of. Not sure what that is, but I am assuming it is a temp table to hold records and used for an insert query. That is not needed and only adds complexity. Part of the problem is that you have this spaghetti code and query, that is so complex it is unusable. If you design a database that is so complex that you can no longer use it you might just have a problem. Being able to write complex code is not what makes a good programmer, being able to write clean, concise, reuseable code is.

I know a little about designing Access applications so if you do not want to listen to my advice then you can keep putting these band-aids over top other band-aids, and hopefully somehow else can help out. Unfortunately for you on this forum there are a handful of people that routinely deal with recursion and form instances. You can look up my posts and I have posted numerous threads on both topics.

If you want my help, post the form query (not an image) and let me help you redesign it. If you simplify this then everything else is simplified. As I said what you want to do is very simple, your implementation; however, is overly complex. If you want a band aid then make the subform unbounded and do an insert query. This way everything in the subform is "seperated". Or use an ADODB disconnected recordset for each subform to allow you to really add disconnected records. That should add some good additional complexity.

You may not know Rube Goldberg, but I get a sense this is what you are trying to build.
RubeGoldberg.jpg
 

HASAN-1993

Member
Local time
Today, 08:40
Joined
Jan 22, 2021
Messages
89
Thank you, my dear brother
But believe me, I'm doing something cool, but it's already a little complicated
But thanks to your information, I have now reached my goal
But one thing remained, and that was how I call instance form from another form
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 01:40
Joined
May 21, 2018
Messages
8,516
I call instance form from another form
Form instances are best managed in a custom collection. That class usually holds an HWND as a key, but not often that useful because we do not converse in HWND. Often my key would be the something more concrete. If I open Acct 1, 2, and 5 as form instances. Then I would store the primary key or the name as the key. Also this ensures I do not open that same record in two instances. Then if Instance 1 needs to reference instance 5 it pulls it from the collection by Key. This is really no different from calling a form from another form by the forms collection.
 

HASAN-1993

Member
Local time
Today, 08:40
Joined
Jan 22, 2021
Messages
89
I have a nice thing, which is that the Form that I want to choose account from is normal, not instance, but how it will be
 

HASAN-1993

Member
Local time
Today, 08:40
Joined
Jan 22, 2021
Messages
89
The solution has been found

[In the form that will be storing the variable (unbound)]
Private WithEvents dlg As Form_frmCustomDistList

Private Sub dlg_Finished(vReturnValue As Variant)
BLAH BLAH..
End Sub

Private Sub cmdDistributionList_Click()
Set dlg = New Form_frmCustomDistList
dlg.Visible = True
End Sub

[In the dialog form]
Public Event Finished(vReturnValue As Variant)
Private Sub Form_Unload(Cancel As Integer)
RaiseEvent Finished(vDistListSelected)
End Sub
 

Users who are viewing this thread

Top Bottom