Unanswered: Best way to populate multi-column combobox with deliminated string?
I'm in a bit of a quandry trying to figure this one out.
Basically I have a comma deliminated string that I need to use to populate a multi-column combobox. I'm confused because passing a comma deliminated string works properly for populating a listbox, and combo boxes are SUPPOSED to display the same behavior as a listbox in that respect.
So say I have a combo box with the following format:
0;1.5;1.5 for widths
Bound to column 1
Then I want to pass the following values into the 3 columns:
The values come from the following string:
In an ideal world, I would love if there was a way to simply "locate" a record within the current recordset for the listbox. I see no such method though, so I think I'm stuck.
Other options I've considered is creating a temporary dataset and binding the control to that set, but I don't know if that's possible.
Is there a route that I haven't considered yet that would be feasable?
If it helps, the context of my request is to retrieve a users stored parameter preferences for a given report. In this case, it would be an ID field, a name (company, or entity) and a city. I make user preferences available to be stored and retrieved as some of the reports are HIGHLY parameterized and the users were starting to complain about constantly needing to recreate a set of preferences, while still complaining about lack of flexibility
I'm pretty stuck on this one, any input would be greatly appreciated.
I'm not entirely sure what you're trying to achieve with the combo, but how about storing user preferences in a table and retrieving these preferences when the user opens the form where he/she chooses the report and filters, criteria etc. The combo where they do this could have as its row source a query dragging up the relevant fields from the preferences table and you could give them the option to save these preferences afterwards and update the table.
This table holds all preferences, for all reports, for all users. There are varying parameters that may be specified for each report. of varying datatypes.
The only schema solution to this would result in MASSIVE bloat. I would need to create one preference table for each report contained within my application, which is a fair number of reports.
Essentially there is a form that allows a user to completely parameterize a report in any way they would like. Then there is a command button that will allow them to "save" their preference, which applies an insert statement to the preferences table.
There is another button on the parameter selection form that will allow a user to "load" preferences. This button opens another form which has a very large listbox and "load" and "Cancel" buttons.
The listbox is dynamically formated (from specifications in the report table), then populated with the deliminated string stored in the preferences table.
When the user selects a preference, the values are dumped back into the parameter selection form.
This works perfectly UNLESS there is a multi-column combo box in the parameter selection form. In which case it borks.
The idea here is to eliminate the need to have a seperate "preferences" form for every single report, while still maintaining flexibility.