Justification for SubModelSeqSelectedItem

[TysonMN]

Quoting from the section of the tutorial about subModelSeqSelectedItem.

Unfortunately some selection-enabled WPF controls only have SelectedItem and do not support SelectedValue and SelectedValuePath.

Even if this is true, this seems like a minor point to me.

Side note about the veracity of this quote: What are some controls that satisfy that description? The SubModelSelectedItem sample does not use such a control. It uses ListView, which extends ListBox, which extends Selector, which has dependency properties SelectedItem, SelectedValuePath, and SelectedValue (as well as SelectedIndex).

Continuing from the previous tutorial quote.

Using SelectedItem is particularly cumbersome in Elmish.WPF since the value is not your sub-model, but an instance of the Elmish.WPF view-model. To help with this, Elmish.WPF provides the subModelSelectedItem binding.

This seems like the central issue to me; we don't want users having to deal with an Elmish.WPF view-model. SelectedItem is indeed cumbersome. SelectedValue is determined by SelectedValuePath, which is a "path" that is relative to SelectedItem. Thus, SelectedValue and SelectedValuePath are also cumbersome "by association" to SelectedItem.

Theresore, it doesn't matter so much if...

...some selection-enabled WPF controls only have SelectedItem and do not support SelectedValue and SelectedValuePath.

We (currently) have two types of sequence binginds: OneWaySeq and SubModelSeq.

• For OneWaySeq, the type in the user's sequence is the same type in the ObservableCollection<> that is bound to ItemSource, which is the same type as SelectedItem and SelectedValue, so the user understands the value of those properties as well as the values of SelectedValuePath and DisplayMemberPath.
• For SubModelSeq, the type in the ObservableCollection<> that is bound to ItemSource is a view-model dynamically defined by Elmish.WPF, so the user will not understand SelectedItem, SelectedValue, SelectedValuePath, or DisplayMemberPath (nor do we want users interacting with our internal view-model type).

The main reason for the existence of SubModelSeqSelectedItem is to give the users a clear and legitimate way to interactive with the selected item of their SubModelSeq binding.

Am I understanding this correctly?

As an alternative to SubModelSeqSelectedItem, maybe users could use a TwoWay binding with SelectedIndex. However, just after writing that, I see an issue. Suppose a message causes something to be added to the beginning of the list. This increases the selected index by one, which results in the dispatch of another message to correct the selected index. In the meantime, the model is inconsistent and there could be queued messages waiting to be processed. I think the moral of that story is that the context in which an index is also an ID is very narrow.

[cmeeren]

For the initial justification, check out https://github.com/elmish/Elmish.WPF/issues/77#issuecomment-481329970 and following comments.

What are some controls that satisfy that description? The SubModelSelectedItem sample does not use such a control.

That's just for simplicity.

• the user will not understand SelectedItem, SelectedValue, SelectedValuePath

Yes, the user would understand SelectedValue and SelectedValuePath because they use bindings. See the solution here https://github.com/elmish/Elmish.WPF/issues/148#issuecomment-542375235 and the correction here: https://github.com/elmish/Elmish.WPF/issues/148#issuecomment-542873045

[TysonMN]

Thanks for those links. They were very helpful.

Yes, the user would understand SelectedValue and SelectedValuePath because they use bindings.

Oh, yes. Of course. You are right. I was being dumb there. I understand that now.

What are some controls that satisfy that description? The SubModelSelectedItem sample does not use such a control.

That's just for simplicity.

That's ok.

77 seems to be specifically about SfDataGrid and generally about DataGrid, which extends MultiSelector, which extends Selector just like ListView (eventually) does.

I will look more into SfDataGrid at some point.

[TysonMN]

I am trying to compile a list of controls the involve selection. The implicit assumption is that we want to support all of them.

• Standard Library
  • ListView
  • DataGrid (#77, filtered/sorted)
  • TreeView
• Syncfusion
  • SfDataGrid (#77)
• DevExpress
  • GridControl (#188, support response)

Anything I missed that I should add? If so, I will edit this comment to add it.

[BentTranberg]

I think you missed some, and most notably ListBox, though it's sort of covered through its descendant ListView.

• ItemsControl
  • TreeView
  • Selector
  • ComboBox
  • TabControl
  • Ribbon
  • ListBox
    • ListView
  • MultiSelector
    • DataGrid

ItemsControl is an important visual control in its own right, but does not have support for selection built in. I only wanted it listed as the root in this hierarchy.

TreeView has SelectedItem, SelectedValue and SelectedValuePath, despite not being a descendant of Selector. That last fact is most probably due to it not being a plain list.

edit: I don't understand why ListBox and ListView (others?) are not a descendants of MultiSelector - but never mind, I don't need to know right now.

edit2: I can spend some time this weekend finding relevant controls in DevExpress. I have good hopes they're not that many.

[BentTranberg]

Wading through the DevExpress documentation on the lookout for components with selection is rather frustrating, but eventually I found these. I won't be surprised if there are more - or if there aren't more.

GridControl TreeListControl TreeMapControl PropertyGridControl GanttControl

https://documentation.devexpress.com/WPF/6933/Controls-and-Libraries/Data-Editors/Included-Components#selection

ListBoxEdit ComboBoxEdit FontEdit LookUpEdit / SearchLookUpEdit / MultiSelectLookUpEdit / TokenLookUpEdit AutoSuggestEdit

[MicaelMor]

Hi,

While I know Syncfusion SfDataGrid is already on the list figured I would share my findings.

The only form of multi selection supported by SfDataGrid is SelectedItems which ofc does not work with subModelSelectedItem.

In single selection the only 2 ways of binding it are using SelectedItem, or using SelectedIndex, there is no SelectedValue or SelectedValuePath.

I explored making multi selection work with SfDataGrid, and much like expected there is no way to bind the underlying IsSelected property of rows, like one can do with DataGrid, even submitted a ticket to syncfusion to make sure, here is the reply:

https://i.imgur.com/GDXmfmq.png

Thanks for your patience.

We have checked the reported scenario. In SfDataGrid, it is not possible to bind the underlying Boolean property to the selection state of the rows. However SfDataGrid have support for GridCheckBoxSelectorColumn to select or deselect individual rows. Kindly refer the help documentation given below.

UG reference : https://help.syncfusion.com/wpf/datagrid/column-types#gridcheckboxselectorcolumn

Please have a look at this and revert to use with details if this doesn’t meet your requirement.

The provided link does not solve the issue since while GridCheckBoxSelectorColumn is a perfect representation of the desired behaviour, it does not bind to the underlying source (as described in the documentation), have ofc tried to bind it anyway but was unsuccessful. Have also submitted a follow-up ticket to confirm there isn't any way of binding it, will update if there is, but seems doubtful, at least not without some amount of code behind.

So right now the solution to multiselection on SfDataGrid, is at least as far as I have been able to make work, to have single selection in the wpf control, and then have a checkbox column bound to bool property with a twoway bind, which is the solution @BentTranberg came up with for DevExpress gridcontrol.

[TysonMN]

Thanks @MicaelMor for your time spent investigating and sharing your findings. I do intend to eventually add first-class support for multiselect, but I am currently spending my limited time on preparing v4 (c.f. #253) and especially the composable bindings API (c.f. #263). I am glad that you found a workaround that you can use in the meantime.