Filling unbound listbox with data from query in continiuous form

[Tectu]

For the purpose of learning Access I want to create a small Access application to keep track of electronic components. My current design and the corresponding continuous from looks like this:








Now to my issue: I want to populate the content of the unbound listbox at the very right of the form either through a query or through VBA code. I already have a working query that uses the component ID (there is a component ID field on the form that is hidden to the user) and returns the corresponding SupplierName with the corresponding Link and Price of the component.
My problem is that all listboxes on the continuous form show the exact same content. It seems like the query is only run once when the continuous form loads and then all listboxes use this data. But what I need is that the query is run for each individual form of the continuous form. How do I do that?

[CJ_London]

If the listbox is unbound, it will the same for each row. Rather than using a listbox, use a subform

[Tectu]

A subform cannot be used within a continuous form. Any other solutions?

[ItsMe]

What Ajax is saying and what you already have discovered is that you cannot use the listbox in a continuous form the way you would like to. An alternative would be to put the listbox in the form's header or footer. I am not sure how I would go about this. I do not use contiguous forms very often. For what you are doing, a continuous form may not be the best solution.

As I try to imagine various scenarios, I hit a hurdle. A user could select a single record/item from the continuous form and trigger an event. In turn, a single list of vendors could be presented to the user (maybe in the form's Header/Footer). An alternative may be to use a Report. Reports are useful when it comes to Grouping things like this.

[Tectu]

I would prefer not to have such a listbox or anything with this functionality in the header/footer.

How would you build this form without using a continuous form? The reason why I am currently using a continuous form is because the user can enter any value into the text box and there are most likely multiple results, not just one. Using a continuous form the users sees all components on first glance. When it is a single form the user has to go through the components using the record selectors or other navigation buttons that are part of the form itself.
Any ideas?

[June7]

Maybe this alternative will meet your needs http://www.fmsinc.com/MicrosoftAcces...edSubforms.asp

Nope, just took another look at OP. Don't think that approach will accomplish.

[CJ_London]

I'm confused - you say it is an unbound control but you also say 'The reason why I am currently using a continuous form is because the user can enter any value into the text box'. If this is the case, the control needs to be bound.

I was going to suggest you could modify Allen Browne's solution here

http://allenbrowne.com/ser-42.html

basically replace the comma separator with vbcrlf and call it in your form recordsource and bind a textbox to it, but the result will not be editable

[Tectu]

I'm confused - you say it is an unbound control but you also say 'The reason why I am currently using a continuous form is because the user can enter any value into the text box'. If this is the case, the control needs to be bound.

I was referring to the search text box, sorry.

I assume that having a form where a search term can be entered and a query will return multiple results is a very common case. How are the search results usually presented to the user? You mentioned that the continuous form is probably not the best solution for my problem anyway but what other options are there? Should the search results just fill a list and a form opens upon clicking a list entry?
The reason why I like(d) the continuous form solution is because the users gets presented with all the information about the components that were found during the search - in a neat form with easy and fast navigation by simply scrolling.

I was going to suggest you could modify Allen Browne's solution here

http://allenbrowne.com/ser-42.html

I am not sure whether I understand how this helps in my case. How is using DLookUp() or the suggested ELookUp() different from running a real query?

[June7]

Maybe you better consider a report. Report opened in Report View can be interactive.

[Tectu]

Thank you for your suggestion. I will take a look at that. So far I have not touched reports at all. I thought their only purpose is to generate printable documents.
Good that this is a project to learn without any deadline

[June7]

Reports are intended for data manipulation and output (printing) but can be interactive (scrolling, clicking) with Report View (not Print Preview).

Forms are intended for data entry and screen display but can be printed.

[CJ_London]

How are the search results usually presented to the user?

depends on the purpose of the results, number of fields etc. but for data entry it is usually single form - suggest review the split form option (I presume it is available in 2013)

How is using DLookUp() or the suggested ELookUp() different from running a real query?

I was suggesting ELookup, not DLookup. It can be called from a query and the result bound textbox which is currently unbound (the one that has test1, test, test3 in it