Dynamic CommandBar that will show as many appbar icons as possible on the screen, and if it can't it automatically overflows to the secondary commands.
Anyone interested in this sort of control?
sounds like a good idea
I can definitely use it
Sounds like a good idea.
@ScottIsAFool are you already building this?
@Code-ScottLe I have something in mind for it, yes.
I vaguely remember reading about this being the new default behavior (overflow into menu if there's no space) in one of the Insider build notes. Can't remember which, though.
While I have not tested, I thought this was default as well.
Well if it does, you must have to do something to enable it, because I'm using a command bar in the bottom appbar and it's not overflowing to the secondary
Is it it not CommandBar.IsDynamicOverflowEnabled? Needs 1607.
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.controls.commandbar.isdynamicoverflowenabled
Yes, that's the one I read about! :)
Ok, so the purpose of this control then would be to mimic that dynamic behaviour if youre targetting/running on a lower version than 1607, or just using that property if on 1607.
I always hate this bit.. @ScottIsAFool you know whats likely outcome right ? :)
What?
Is this really neccessary then? I think > 90% of Win10 users are on 1607 already.
I don't think it's necessary to do this. This project targets the latest 2 version of Windows 10, but Windows 10 1703 is coming in a few months. I think adding a new feature and remove it 3 months later is stupid.
The feature is available in 1607 already, out almost half a year.
@lukasf so? doesnt mean devs are just automatically switching their projects to the newer target versions!
@lukasf
I mean when we regard the following principle, we'll find that this feature will only exist for 3 months.
Principle 3: All features will be supported for two Windows SDK for Windows 10 release cycles or until another principle supersedes it.
@ScottIsAFool UWP projects allow you to set min and max version. You can increase the max version to 1607 and then for users who are on 1607 already, set the property (in code behind). Only the few users who have not upgraded will stick with the old behavior. In the end it is their choice not to upgrade. Not having access to the latest features is part of that choice.
But I am not totally against this. If you want to provide some kind of attachable property or behavior to achieve this, I'm fine with that. I only think it is quite some work, and I wonder if it's worth to do it, when MS has already done that work and it is so easy to make use of it in any UWP app.
@taoyouh I don't think that it will be handled that strict.
@ScottIsAFool do you want to keep it? I think it's now a bit too niche for the toolkit