MVF Technical Discussion and Uses (If you plan to Use Them)

[gemma-the-husky]

I don't understand why MS didn't provide a multiselect list box control with checkboxes that maps to normalized tables. It would've actually been easier to implement that solution from the very beginning. So now we have users creating denormalized structures just to support desired user interfaces, and developers who simply won't use MVF controls because of all its shortcomings. MS should've done a better job in enforcing proper relational design.

Because multi select anything is really not relational, more presentational. I had a system where selling prices were displayed in a grid with products as row entries, and packsizes as column entries. That's non relational, so I stored the data as relational, Rows with column entries for product, pack size, price, but then reprocessed the items to present them in a grid.

Then after changes were made, I had to turn the grid back into the normalised storage arrangement..

Just because the users/company wanted the data presented in a particular way - admittedly a useful feature.

 

[MajP]

As @Pat Hartman stated they do not want you messing with the table because in order to get the presentation of an MVF the hidden table needs to be very standard. The hidden table has specific field names and datatypes. If you alter this it could easily mess things up. I think they could of mad it visible and even editable, but likely the average user could screw it up. So they are hiding it to be safe. I think they may have erred on the cautious side. They were cautious so a user cannot mess it up, but this made it so obfuscated that most users would not use them. I think they would have been better off making it visible and they would have been more adopted.

The MVF was a solution to Sharepoint. Sharepoint does not have any kind of subform and mostly just a "datasheet" view. So they needed somehow to make an interface to display and select multiple choices. So they needed it to work with SP and then figured make it available for Access.

 

[MajP]

Why is it necessary to put non_MVF multiselect controls in an Access subform? Is it because you can only store one value per record in a detail table?

I do not understand that question. On a main form you can have a an multiselect listbox and not in a subform. This demo shows that

Form Design to Allow Multiple Selections (Add your Ideas)

In response to this @DakotaRidge and I are very interested in examining all possibilities for implementing controls with multiselection capability and store those values in normal child tables...

www.access-programmers.co.uk

Here is a listbox on the mainform showing selections for that record.

You cannot do this in a continuous form because it is an unbound control formatted through code. If it was continuous each record would display the same results.

 

[MajP]

thought the demo solutions presented in this thread are using popup modal subforms to simulate multiselect listbox controls?

Not sure what to say. Either look at the demo or look at the very clear summary. One of four uses a subform.

This thread is designed to allow people to showcase techniques they use.
The example I am posting is the common checklist.
This uses 4 modifications to the same technique
1. using a subform
2. using a multi select listbox
3. Using an in memory ADO recordset
4. using a crosstab