Using a multi-instanced form as a child form (1 Viewer)

[NeuronRider]

Kind of a strange one here.
I know how to create the instances, but I don't then know how to refer to them to set the new instance as the Source Object of a subform control.

For example, I have a form with a tab control consisting of 19 different tabs. Each tab needs to display a different record of the same table. My intent is to use the same form for this each time. Here's a snippet of what I came up with:

Dim SummerQForm As Form

Select Case intPic
        Case 0
            q = 1
            For n = LBound(SummerQs) To UBound(SummerQs)
                Set SummerQForm = New Form_frm_QuestionSub
                frmName.Controls("Q" & q).SourceObject = SummerQForm

I've exluded the rest of the Select and For loops.

Using this structure, I get a type mismatch, which makes perfect sense to me. I'm trying to assign a form object to what is essentially going to need to be a string value. From what I can figure, what I really need to do is get the instanced form's name and use that for my Source Object declaration.

Any ideas are appreciated. This thing's been giving me a headache all day

 

[Travis]

Just a question. Why not just put the forms in each of the Tabs through the Designer?

 

[MarkK]

Make your tab control transparent, put ONE subform under it, and modify that subform's filter or recordsource in the Tab_Change() event handler.

 

[wazz]

THAT...is a neat idea!
w

 

[dt01pqt]

Make your tab control transparent, put ONE subform under it, and modify that subform's filter or recordsource in the Tab_Change() event handler.

He could do this but really he should question why he is using a tab control at all, it is quite messy and it would be better to use a combobox instead. This would save on space. But when you are filtering through records you don't need 'instances' of the same sub interface. The whole point of tab controls it to save screen space and windows, when the tab control is taking up more space than interface itself that destroys the whole purpose.

 

[NeuronRider]

hrm. I'll have to mess around with that idea Lag, thanks.

The reasoning behind the tab control is as an entry to a table recording answers to randomized questions. Currently, each question generates its own record within the table, keyed to the session ID, and two different values associated with its randomly assigned order. This was neccessary to ensure a unique key field.

So, in order to display all of these questions and give a combo box of acceptable answers within a subform, the tab control made the most inherent sense to me. I'm certainly open to suggestions, but I just can't envision a good way of presenting this info in a combo box format, even a multi-tiered one. I think it would just be too confusing.

The point of instancing the forms was to avoid making n copies of the same form and setting them as static assignments in the tab subform control.

The problem with only using one form, setting the subform control source to that is that all my tabs are then showing the same record. This is when I started to investigate instanced forms to get where I wanted.

I'm going to mess around with LagBolt's idea here and see if I actually understand what he suggested

Any further suggestions or questions are welcome, including those on my goofy table structure

 

[NeuronRider]

Hopefully I've explained what I'm shooting for well enough for this question to make sense.

Would I be better off simply using a static source object to the one form on all tabs and changing the filter thru the Tab_Change event handler?

I suppose it might pretty much achieve the same basic result of LagBolt's suggestion. My initial concerns with your idea Lag, is that I'm doing this twice, over different domains, on two subforms in the same parent. So, I believe I'd still need to instance it at least twice, or create two subforms to handle all occurances with my parent design. I'm thinking just changing the filters on this event would allow me to limit myself to just one form.

Have I confused anyone else other than myself with this question ?

 

[MarkK]

Would I be better off simply using a static source object to the one form on all tabs and changing the filter thru the Tab_Change event handler?

Yes, that's what I'd do.

 

[dt01pqt]

The reasoning behind the tab control is as an entry to a table recording answers to randomized questions. Currently, each question generates its own record within the table, keyed to the session ID, and two different values associated with its randomly assigned order. This was neccessary to ensure a unique key field.

So, in order to display all of these questions and give a combo box of acceptable answers within a subform, the tab control made the most inherent sense to me. I'm certainly open to suggestions, but I just can't envision a good way of presenting this info in a combo box format, even a multi-tiered one. I think it would just be too confusing.

I'll have to take your word for it. Personally I would still use a combo box then maybe a listbox or option group in the subform. Are you trying to create a multiple-choice test? If so why don't you ask one question per page? You could select a number of questions randomly and filter the rest out. Like you said the best interfaces are intuitive, but the best test of that is someone else.

The point of instancing the forms was to avoid making n copies of the same form and setting them as static assignments in the tab subform control.

The problem with only using one form, setting the subform control source to that is that all my tabs are then showing the same record. This is when I started to investigate instanced forms to get where I wanted.

You need to query or filter the form so it shows what you want it to when you want to. Instancing forms where do I start? You don't actually instance forms, you instance windows (forget the access definition of forms for a sec). Forms are actually templates or instructions to create a window. Another thing: subforms despite the name are not forms they are controls and reside in the controls collection. So in actual fact you have only got the one form open. However you are barking up the wrong tree. What you are really talking about is the correct record(s) in the recordset not the instance of a form.

 

[NeuronRider]

Yeah, it's essentially a multiple choice questionaire, with the questions randomly ordered each time. I am actually shooting for one question per page. The thing I was shooting to avoid with the instanced forms is making up 38 identical copies of a form (one for each question) as a sub for each individual page. I was having problems conceptualizing how to not use a sub for each page, as each question and it's response is actually a seperate record within my source table. Couldn't seem to wrap my mind around having 38 seperate controls (it's 19 questions with 19 answers across 2 seperate domains, thus the 38 total questions, but only 38 controls on any one of the forms) all pointing to different records within the same table. Essentially, if I could have gotten it to work, I believe I would have just created 38 dynamic relationships (there are lookup tables involved) per domain of 19, which didn't seem very desirable to me.

I see your point though dt01pqt, and definitly appreciate the thoughts. Especially the clarification on what an instance and subform actually are. I understand why I was having problems making my conceptualizations work in actual practice. Turns out they weren't accurate

Thanks to you too Lag. I'm currently playing around with this idea, though trying to make it work without another subform (the parent in this case already being a sub of another).

Merci beaucoup guys Let's hope that I can make this work now, hehe.

 

[MarkK]

bienvenue, et bon chance

 

[dt01pqt]

Yeah, it's essentially a multiple choice questionaire, with the questions randomly ordered each time. I am actually shooting for one question per page. The thing I was shooting to avoid with the instanced forms is making up 38 identical copies of a form (one for each question) as a sub for each individual page. I was having problems conceptualizing how to not use a sub for each page, as each question and it's response is actually a seperate record within my source table. Couldn't seem to wrap my mind around having 38 seperate controls (it's 19 questions with 19 answers across 2 seperate domains, thus the 38 total questions, but only 38 controls on any one of the forms) all pointing to different records within the same table. Essentially, if I could have gotten it to work, I believe I would have just created 38 dynamic relationships (there are lookup tables involved) per domain of 19, which didn't seem very desirable to me.

Ok you need:

Questions Table * 19 Records, a column for the question #, a column for the question + columns for possible answers
Results Table * 19 Columns for answers of question # + Domain (set all the fields to required)
Domain Table

Although this is a data entry task the table will be linked to the questions and therefore needs to be data view, giving a total of 19 questions to answer. The answers will not be bound to the form so it is ok to prevent editing of the questions. Right in order to record the result you need to open a recordset of you results table on loading the form. Each page contains a question and the answer is placed in the corresponding column in the results table. You can get the domain from the login. OnCurrent (and load) you fill in an option groups labels with the possible answers. OnChange of the option group you record the choice. Since every field is required in the in the results table if you don't answer every question the record is not saved (you can change this to suit your needs).

Hope this helps.