[Bug] Samples: "SubModelSeq" - weird selection and moveUp/Down behaviors

[YkTru]

BUG.Sample.ElmishWPF.-.SubModelSeq.mp4

Problematic sample: repo

Issues when pressing ''arrow up/down'' buttons:

• Deselects selected item
• Toggle item in place

Note: SelecteItem has no binding associated.

[TysonMN]

I know what you mean by the first issue

Deselects selected item

What do you mean by the second issue

Toggle item in place

?

[TysonMN]

Have you tried to fix this problem? If so, what have you tried?

Note: SelecteItem has no binding associated.

Have you tried adding a binding?

[YkTru]

What do you mean by the second issue

Toggle item in place

@TysonMN Apologies for the delayed response—I only just noticed your reply. What I meant is that, as shown in the video, the initially selected item swaps cyclically ("toggle") with its predecessor when I click the "MoveUp" button two or more times, instead of continuing to move up.

---

Have you tried adding a binding?

First, I must say the SubModelSeq sample is quite complex and challenging for a +/- beginner like me, and because of this I don’t feel confident proposing anything that would be a valuable use of anyone’s time.

(I find the binding signatures ('Self,Parent") and InOutMsg pattern quite overwhelming honnestly, I wouldn't know how to make a MRE out of it without breaking a lot of stuff)

However, I attempted something similar based on the SubModelSeq sample's bindings here, and I provided a detailed (though overly exhaustive) account of all my attempts/intuitions here. (I only managed to resolve - I think - the MoveUp/Down issue by using Cmd.ofMsg (SelectItem(Some id)), though I’m not happy with that approach at all))

[YkTru]

That said, if anyone has clues or insights on how to resolve these two issues in the SubModelSeq sample, I could try to create a simplified version based on it to make it more accessible for beginners.

[YkTru]

(@xperiandri are you experiencing similar issues (unexcepted UI deselection etc.) with the Elmish.UNO "port/version" of that sample?)

[TysonMN]

What I meant is that, as shown in the video, the initially selected item swaps cyclically ("toggle") with its predecessor when I click the "MoveUp" button two or more times, instead of continuing to move up.

That is the intended behavior. Each time you click the "MoveUp" button, it is a different button. That is, all even clicks are on one button and all odd clicks are on another button.

(I only managed to resolve - I think - the MoveUp/Down issue by using Cmd.ofMsg (SelectItem(Some id)), though I’m not happy with that approach at all))

Yes, that solution is a hack.

When I have some free time, I will work on this issue since I think it is the simplest of the problems that you have raised. I do not currently know when I will have any free time.

[YkTru]

That is the intended behavior.

Omg sorry I was dumb here haha.. However in my own attempt, I indeed encountered some issues while trying to implement a global moveUp, which led me to resort to hacking around with Cmd.ofMsg (it's the only way I was able to trigger moveUp button successively, but it didn't resolved the UI (visual blue background) deselection issue - as you can see in the GIF - which is quite strange).

---

When I have some free time, I will work on this issue.

Thank you so much! My intuition suggests that if the unwanted deselection issue is addressed, we may not need the Cmd.ofMsg hack to reselect the previously selected item.

However, I suspect there could be a problem with how F# records interact with WPF, possibly due to hashcode-related issues. Maybe using >> Binding.addLazy could help by setting an appropriate equality function?