Incorporate UI into a Query??

[nick404]

Is it possible to somehow have a query appear in a switchboard format? Where I could place a back button? I have a UI that the user navigates through to order certain laboratory parts. They needed a specific order format for parts made by the supplier 'Fisher' (specific format is not needed for any other supplier) so I made a query that separates all the Fisher parts from others. In the query I have a "need part" field where they check the box whether they need the part or not, and then can use a form to display only the checked items, and then they can fill out some order information on the form and finally send the order form. Is it possible to somehow get the query to not run in a different tab, but instead have it run as a 'part of' the switchboard I am using (much like how a form and report are a 'part of' the switchboard)? i.e. I don't want to have the user have to click the parts they need in the query, then close the query or click back to the switchboard. It would be better as one entity. Any ideas? Thanks!



All the queries are a part of a macro and the switchboard runs the macro corresponding to the query I need.

[June7]

Not sure what you mean by 'switchboard format'. A form can be set as Continuous and controls arranged to look like Datasheet, and buttons can be in form header. Can use form/subform arrangement. And then there is the Split form object.

[ranman256]

You could have a list for the supplier Fisher's queries and default queries.
The user picks Fisher, so Fisher queries show.

[nick404]

I admit that was a poor way of putting it...
So what I have is a button the user presses to select the parts they need to order. They click it and the query for the specific supplier runs and opens. They use the 'need part' field and checkbox what they need to purchase. At this point they either have to close the query, or click the switchboard tab to go back. Is there a more user intuitive method of going back to the switchboard (for those lacking technology assimilation)? They have to go back to select the form they need to show the parts they just selected. Perhaps a sort of 'button' i could insert into the query that would close the query after they are done selecting the parts they need?

[June7]

Users should not interact directly with tables and queries, only forms and reports. Cannot have buttons on tables and queries and no code behind them (except for Data Macros introduced with Access 2010).

[nick404]

Hmmm...yes, okay I will have to rethink my method. Thank you

[Micron]

Isn't June's suggestion of a continuous form with the buttons you want located in the header right up your alley, so to speak? I tend to over-complicate things, but this is what I'm thinking.
Create a temp table, create a copy of your select query as an append query, populate the table with it and open the form based on the table. After the user clicks the boxes to order the parts, you open a report that is based on the temp table if that is the output you want. You will have to clean up the temp table when the process is done. If this is a split db where each user has a copy, the temp table needs to be in the front end. If it is split but users share one file, you will have to take extra precaution that you don't wipe out other user's data when cleaning up. If it's not split - Whoa!