Add CheckBox

[insinfo]

<Window x:Class="WpfTutorialSamples.Basic_controls.CheckBoxSample"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="CheckBoxSample" Height="140" Width="250">
    <StackPanel Margin="10">
                <Label FontWeight="Bold">Application Options</Label>
                <CheckBox>Enable feature ABC</CheckBox>
                <CheckBox IsChecked="True">Enable feature XYZ</CheckBox>
                <CheckBox>Enable feature WWW</CheckBox>
        </StackPanel>
</Window>

[birbilis]

Why just text one? Could have 3 children, Checked, Unchecked, Undecided (optional for 3-state combos).

Some of those three children could also be entered via string values as properties/attributes or via binding maybe too of strings or even of more complex controls

[dotMorten]

@birnilles first that isn't a checkbox, second you use visual states for that kind of thing

[birbilis]

Why write verbose xaml when one wants to switch between 2 or three visual subtrees?

[dotMorten]

Back to what you want isn't a checkbox.

[birbilis]

Just different definition of what each one defines as a checkbox.

[dotMorten]

Seriously? A box with a checkmark in it, is a checkbox. Please again stay on topic. If you want a 3 state Content control suggest that in a different topic but don't redefine what everyone knows a checkbox is or misuse it's purpose.

[birbilis]

Is it really everyone though?

[crutkas]

I agree with @dotMorten here @birbilis. If you want a three state control, that is not a checkbox. The checkbox is a well know pattern. I would say make that a different issue if you want to have a checkbox extended to that.

This request's heart is the pure checkbox control.

[Mike-E-angelo]

If you want a three state control, that is not a checkbox. The checkbox is a well know pattern.

WPF called and wanted a chat with you, Mr. @crutkas:

https://stackoverflow.com/questions/23213775/capturing-indeterminate-state-in-wpf-threestate-checkbox

https://msdn.microsoft.com/en-us/library/system.windows.controls.primitives.togglebutton.isthreestate(v=vs.110).aspx

It would seem the 3-state has been baked into checkbox lore since the beginning, and is a "well-known" pattern. Please let me know if I have misunderstood this.

And yes, I know we're not trying to recreate WPF, but I believe we have all amassed around the understanding that it should at least be respected and/or recognized in moving forward. When I hear "checkbox" I myself think 3-states are possible/implied, due to the above. I would wager that @birbilis also understands this and that we are not the only ones with this understanding, either.

Now all THAT said, I am in agreement that flipping a boolean here to alter fundamental behavior of a control is terrible design. I think the right approach is indeed 2 discrete controls that explicitly describe their intended behavior and use.

The problem however is that we're going to be fighting against expectations/conditioning of the vaunted legacy system with lots of dark matter educated by such, and my intent/concern here is to foster awareness around this.

Is there a creative way/approach here to acknowledge/incorporate the design of the past while ensuring we get and adopt a solid/appropriate design under the Standard?

[birbilis]

From what I read Word does have a CheckboxContentControl but not as separate API type at its ContentControls. Placing a normal content control and changing its behavior with a property. Does allow to change symbols (content) for checked / unchecked state, but not sure how radically (eg just one char or some string or more XML based content)

However I don't see why to add a separate CheckboxContentControl instead of making Checkbox more generic to cover more needs.

After all a checkbox behaviour is related to a button/togglebutton behaviour and buttons get to host child content to show images etc. Why not for the checkbox then?

[birbilis]

In fact the discussion at https://github.com/Microsoft/xaml-standard/issues/153 where @dotMorten and @skendrot mention that Button is a content control that can contain images is a bit related.

With the same logic mentioned here against my suggestion for checkbox children/subtrees, could use a VisualStateManager's verbosity to show a button with image instead of having Button host children (or even suggest an ImageButton like in Delphi etc)

So to sum up, I don't want a separate threestate ToggleButton, checkbox could cover that need too

[dotMorten]

I don't want a separate threestate ToggleButton, checkbox could cover that need too

Oh the irony that Checkbox inherits from ToggleButton.

Look I get a checkbox can be restyled to be a 3-state control, but it's not its primary use. When people see a checkbox, they think a box that can be checked not a "oh let me switch between 3 completely different contents based on true, false and null". Screw your argument about breaking away from legacy - Checkbox means checkbox. End of story..

The issue here is someone wants to make sure checkbox is a 1st party simple to use control, and that is a fair ask. It's a UI Control so common in pretty much all apps, and should be a simple tag to add.

But repurposing this into a 3-content control is a horrible idea. It's unpredictable for a control with this name, and there are so many better ways (the new VisualStateTriggers for instance makes this super easy, so why aren't you instead suggesting that being part of the standard).

Now lets get back on track: If you want a Checkbox control as suggested on top, thumbs the issue up. If you want something different, open a new issue.

[Mike-E-angelo]

Screw your argument about breaking away from legacy

Insensitive and ironic -- you are, after all, the author of the very issue that asks to include ALL THE LEGACY in the standard -- remark aside...

Checkbox means checkbox. End of story..

It would seem that WPF (legacy) and UWP (modern) both say that Checkbox means Checkbox with up to three states. While XF does not have a Checkbox (?!) a top search suggestion also provides 3-states. Soooo... the story continues? 😄

[birbilis]

I don't want a separate threestate ToggleButton, checkbox could cover that need too

Oh the irony that Checkbox inherits from ToggleButton.

From my understanding XAML Standard defines a flat vocabulary only, not a control hierarchy and PME model etc.

So I don't see any way to describe control inheritance in the standard with the current approach.

Also, regarding your approach at #153 that there can't be both simple properties like "Text" for a button and content children at the same time supported at a control, I don't see where there is a problem to that. Could either throw an exception (compile time based on the parser and how much metadata or hardcoded knowledge about the standard it has access to, or runtime one by the control itself), or accept that Content has priority and ignore the Text property in the button (plus maybe when Text is queried return ToString() from the content if available). So in the case of the Checkbox, could have the classic checkbox with properties (attributes) to change the text/symbol of the check/uncheck (like Word does) and have children if someone wants to switch visual subtrees. And no, VisualStateManager counter-argument is not enough, apart from being more verbose (for my taste at least), that argument would apply to the Button too as I explained above (someone could argue why have content for it, just use VSM instead...)

Anyway, I'm not trying to push my opinion, it's just that design rationale and use cases should be logged and obviously MS will choose the approach they prefer

[birbilis]

btw, speaking of ToggleButton above, don't remember seeing any issue for that one to log use cases info. Could check if it's in the draft doc at least already, but probably one issue should be logged (as work item and as place for feedback) for each item that is already in the draft spec

In my opinion the checkbox when set to not use the "null" (undecided) state covers the current ToggleButton usecase (speaking of a flat vocabulary here, not implementation hierarchies - so could even have ToggleButton extend Checkbox in some implementation if the XAML standard is a flat vocabulary).

With a separate ToggleButton in the standard, to make it more general, it could be enhanced to support N states (click to toggle to next state with loop at the end and option too if the loop will be a palindrome one). Then an implementation could chose to use that to implement the Checkbox but could also choose otherways.

In any case, even with a N-state ToggleButton, a Checkbox could still be defined to support the 3-state (nullable boolean) children as a specialization of the N-state (list) ToggleButton. And could fallback to native implementation of a classic checkbox in the simplest usecases for rendering, but that's again implementation specific

[dotMorten]

@mike-eee I'm saying to NOT break away from legacy. You're the one saying ignore legacy and wants to redefine what a checkbox is and ignore decades of known naming.

[Mike-E-angelo]

LOL @dotMorten did I just walk into bizzarro/reverse world? I provided examples/links that show legacy components do indeed offer 3-state functionality and values, and why they should be adhered to if at all possible. So you are saying those are good, then? What is confusing me is you said:

When people see a checkbox, they think a box that can be checked not a "oh let me switch between 3 completely different contents based on true, false and null". Screw your argument about breaking away from legacy - Checkbox means checkbox. End of story..

Unless you are missing a quote somewhere and are stating something from the perspective of someone else, I have shown what you say there is debatable at best. Every modern checkbox control that I have worked with (again, links above) have 3-states/values.

[dotMorten]

Sigh. I'm well aware of the indeterminate state of a checkbox. Your argument that legacy shouldn't hold us back is what I'm arguing against. Ignoring legacy often also means ignoring well-established patterns, which is exactly what people seems to be doing in this thread. That's what I'm rallying against. XAML Standard should not break existing behavior. Lots of people wouldn't move to it if it did. That is NOT what I or my customers wants at least.

Let's be clear here: A 3-state checkbox, doesn't mean XAML should promote this as "the" way to do a 3-content content-control (even though it can be done today, and I even have done this in one of my weaker moments). It's a horrible misuse of Checkbox and what it stands for. So can we please for the love of god stop wasting time on ruining XAML, and just vote on the issue: Do you want a Checkbox control to be part of the standard or not?

If you want to add more functionality added to checkbox, or want a control that can swizzle between N number of contents, log your own issue, instead if hijacking this. There's WAY too much hijacking of most of the issues here, and it's getting VERY frustrating that you, @birbilis and @insinfo can't stay on topic but feel the need to do a complete unfiltered brain dump on every single issue, never stopping to think if this is related to the logged issue, and just brainstorming + side-railing the discussions.

I seriously don't understand how "Let's add a checkbox to the standard" turns into "Lets create a control that holds N number of contents". What are the maintainers of this repo supposed to do with this issue, when it's a giant mess of unrelated discussions? Now I just broke the etiquette too and wrote a bunch of unrelated stuff here, but enough is enough, and someone needs to speak up. Microsoft have to be political correct, but I don't. So please... get your acts together and stop ruining it for the rest of us who'd actually like to see this standard move forward.

I hope the maintainers would just erase all these comments (including mine), so we can get back on track to the issue at hand (checkbox or not a checkbox)

[Mike-E-angelo]

I am seriously laughing here, @dotMorten ... I am positively confused on how you feel that I am saying what I am saying. Please quote me and we can take it from there, because it seems you are 100% misunderstanding me, or I have not represented myself accurately, or a combination of both.

From my perspective this is 100% on topic as we are discussing what exactly a checkbox means in the standard. I am also very interested (and amused) in how the thread creator can hijack their own thread. 😆

But, don't get me wrong, I enjoy reading your unfiltered brain dumps as well and am glad to have inspired you. 😄

In either case, I do not feel we have deviated from the topic at all and has been very relevant.

[Mike-E-angelo]

I apologize for getting you riled up here, @dotMorten. I thought we were constructively tackling this issue, albeit in a rather confusing manner.

So can we please for the love of god stop wasting time on ruining XAML, and just vote on the issue: Do you want a Checkbox control to be part of the standard or not?

The issue here is that it is not that simple. Much like development/software as I am sure you are aware, the devil is in the details. You are going to have people say "yes give me that checkbox" and expect it pure, but then others who hear "checkbox" and expect it to be WPF and even UWP's version. Is that not the core of the issue here?

FWIW, I have no problem bowing out of this, but the issue will still remain that certain (newer?) developers will expect pure checkboxes, while seasoned developers will want/expect 3-state. No amount of downvoting will change this, and from my take that is what we were discussing (and aiming to possibly solve).

Maybe at this point it's better to have someone else solve it for us. 😛

[birbilis]

Actually a design rationale has to cover arguments and counter-arguments, link to related items etc. If you're getting too much e-mail just turn it off and use the github notifications ui instead.

Not everyone comes from the same background in software and some have been using various technologies for years now to be able to have an opinion on how they'd design a UI architecture.

So in my opinion it's inconsistent at least to have a button as a content control and not a checkbox. People are asking for a button with an optional Text property and they're suggested instead to make the more verbose choice of always using a child control. But no, the Checkbox is suggested to be plain simple instead. I'd go for both simple properties and child controls. The 2nd would override the former or throw exception if both are used.

[GeraudFabien]

I realy don't understand the problems @dotMorten. The only difference between Toggle switch and checkbox is checkbox have three state toggle has two (even bing agree with this a key or command that toggles between two modes, such as the caps lock key). All plateform and framework in all development (WinForm, WPF, UWP, Xamarin.Form, Cocoa, opengl,..) have checkbox with three state. I have just found out that Android did have a checkbox with just two state. Xamarin.Form alone have no checkbox for this reason (Too confusing).
To copy your phrase : Ignoring legacy often also means ignoring well-established patterns, which is exactly what people seems to be doing in this thread. That's what I'm rallying against. XAML Standard should not break existing behavior.

I want to say I would love to see how we style this checkbox. Do we copy WPF way? It may be also interesting to propose a 4 picture (Background, Check, Uncheck, Undertermine) way to make personalization more easily (less verbose for small need). The template way can consume easily the 4 template.

[dotMorten]

@GeraudFabien I'm not saying anywhere a checkbox is two-state only (in fact I make that quite clear I'm well aware of the indeterminate state). The Checkbox doc on MSDN is quite clear on this too:

From checkbox reference: https://msdn.microsoft.com/en-us/library/system.windows.controls.checkbox(v=vs.110).aspx

Checkbox doesn't even have the 'IsChecked' property but this is inherited from ToggleButton and as such they are exactly the same. I'm not sure where you get the idea that ToggleButton only have two states? It also has the indeterminate state, as clearly stated here: https://msdn.microsoft.com/en-us/library/system.windows.controls.primitives.togglebutton.ischecked(v=vs.110).aspx

Wrt to styling the checkbox that's an entirely different topic. If you want a consistent way of restyling controls, suggest a new issue for that. I think the current general idea is the default styles of a checkbox matches that of the platform, and therefore you would rarely want to have styles in your cross-platform section, questioning the need for it to be part of the platform (but we can discuss that more if you log an issue on a XAML Standard way for re-templating controls)

[rashadrivera]

Another basic building block that we need. 😁

[ChrisProlls]

Maybe the indeterminate state could be an option of the CheckBox control ? I see in our project that we need this kind of behavior from our CheckBox control, but not necessarily all the time, and create 2 controls to handle this behavior it's too bad. IsChecked could be a bool? (just an idea).

There is another question here : is indeterminate state the same as partial state ? (like in a TreeView control with selection, where the parent checkbox is partially checked if only some leafs are checked)

[birbilis]

indeed, one use for the so-called indeterminate state is to show at a parent node that there is partial selection in subnodes of a checkbox tree

speaking of such a view, if there will be a hierarchical/tree control it would be nice if it had functionality to do some action on its children and return a result (e.g. could have then actions to calculate aggregate state of children, select/deselect all, reverse selection etc.). Could use LINQ or something I guess if it has a hierarchical model underneath