Wpf: Remove Command, CommandParameter and CommandTarget TemplateBindings from RibbonApplicationSplitMenuItem template

[shadowaltar]

Current Ribbon API's SplitMenuItem is buggy (https://social.msdn.microsoft.com/Forums/vstudio/en-US/da13b5f5-5252-4332-9ec3-0b78c6395693/ribbonapplicationsplitmenuitem-triggers-command-twice?forum=wpf)
Will this API be open-sourced too so that the community could fix it instead of downloading the source file and manually override the generic xaml file?
Thanks.

[vatsan-madhavan]

It is indeed part of our roadmap. In the meantime, please consider opening an issue against it here, with a self-contained minimal reproduction app that illustrates the problem (and possibly also illustrates the workaround) - it will help the community vote on it and it will help us prioritize future work.

[karelz]

@vatsan-madhavan why not to reuse this issue for the voting? We can change title and modify description if needed ...

[terrajobst]

I'm using the ribbon control in my app. In my opinion the biggest issue is the default style set as it looks fairly bad on Windows 10, especially when maximized. I've tried to provide local assets but I gave up as doing a style set for this large of a control was more work than what I was willing to invest. My guess would be that open sourcing this would help tremendously, so that people can collaborate on this.

[stevenbrix]

I gathered from the referenced msdn forum that this item is about fixing the template for RibbonApplicationSplitMenuItem. If that is wrong, then please let me know.

I would like to set some expectations just so that we are all on the same page.

In general, we really want to focus our attention and effort on ensuring that porting your .NET Framework application to .NET Core is as easy as possible. With that goal in mind, we're primarily focused on making sure that there are no regressions or breaking changes that accidently sneak into .NET Core. While I'm fairly confident a change like this is safe, one thing to keep in mind is to make sure that the (other) workaround provided in that forum still works:

Based on my research, this behavior is by design. The UIElement which receive the Command is RibbonButton at the first time and the second is RibbonApplicationSplitMenuItems.

Although this is the nature of RibbonControl you can try to workaround this by parsing the ExecutedRoutedEventArgs and check if the OriginalSource is the same as Source, if yes then get this command executed.

For that reason, I'm going to move this into the "Future" milestone so that we (WPF community) can look into making this fix as soon as we RTM. If anyone feels strongly about this please let respond and we can reassess, thanks!