Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

I've asked for this a ton of times in the past.

I want a Boolean Edit type (or Data Type) for user-created Library fields.  When displayed in MC's interface, it should show with a checkbox (a checkmark or dot in Theater View).

I don't care how this value is actually stored internally, but if it were me writing it, I'd leave MC's actual field storage system alone, and just implement them as Integer fields, with the Acceptable Values automatically set to 0 and 1 only.  If you make it so the checkbox can also be a three-state checkbox (-1, 0, 1) then even better, though I won't ask for the world here.  

Right now, you can kinda hack it by using Edit Type stars and making the column two-stars wide, but this looks dumb and doesn't work as well in the Tag Action Window and other places in MC where you might want to display this information.

This thread reminded me that it annoys me:
http://yabb.jriver.com/interact/index.php?topic=92573.msg638001#msg638001

I use these kinds of boolean fields a few places (particularly with my at-work Library), but the lack of a checkbox edit type means it is clunky and you have to be a nerd to use them.

[glynor]

I betcha if I get a bunch of +1s they'll listen.

[6233638]

I betcha if I get a bunch of +1s they'll listen.

Code: [Select]

              +1
    +1      +1+1
  +1+1+1      +1
    +1        +1
            +1+1+1

[pahunt]

Add me to the list of people who would love this.

[bblue]

+1, definitely.

[StFeder]

+1

[mwillems]

Do
{+1}
While [Boolean_User_Field_Type != implemented]

[ssands]

I would find this to be useful.

+1

[marko]

Yes please.

[InflatableMouse]

+1.

That would be handy.

[Bccc1]

+1
It would be great if we had both boolean AND Boolean (two-state and three-state), but a simple two-state bool would be sufficient.

[kensn]

Ok... Just for Glynor...

+1

[mark_h]

Would be very useful.  +1

[fridden]

++1

[Dorsai]

+1

[NNTK]

--1 = +1 

[metac]

+1

[AndrewFG]

Given the nature of the OP I think that rather than +1 he was actually asking for the following..

TRUE

OR NOT FALSE

[Matt]

Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.

[glynor]

Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.

This is how awesome you are.

[ssands]

Check ++!

...and Glynor, I need some sort of palette cleanser after that video.

[wig]

Awesome!

I just came to the forum to ask (again) for this very feature.

Very exciting!

[JoeBloe]

+1
Yep!

[wig]

Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.

Thanks so much for this feature Matt. I'm starting to play around with it and have some feedback for you.

• Check Box fields don't work unless I leave the Acceptable Values field blank. Is this the proper setup?
• How do we use the Check Box fields in Smartlists and other queries? They don't seem to assign a value when checked
• The check box system is a major step forward, but I'm finding my tagging is designed around a 3 state configuration (On/Off/Unset) which is going to limit my use of it.
• What I love about this feature is the ability to quickly edit a tag without having to right-click or slow click. If you could expand this feature to open a drop-down box and display Acceptable Values (instead of simply turn a value on-off} it would be a homerun in my book.

What value does It looks like we need to leave the Acceptable Values field blank?

[Matt]

• Check Box fields don't work unless I leave the Acceptable Values field blank. Is this the proper setup?

Yes.  Don't fill the acceptable values.

• How do we use the Check Box fields in Smartlists and other queries? They don't seem to assign a value when checked

The value is "1" when set.

[wig]

The value is "1" when set.

Ok, I'm seeing that now.

I use a Calculated Data field to spit out the contents of a bunch of fields, so I was concerned that a bunch of "1" value would blow up that system. But using conditional expressions like this one in the Calculated Field will fix that for me.

if(isequal([Popular (Check)], 1, 1]), Popular, )

[6233638]

As mentioned here, unchecking the box seems to clear the field rather than setting it to 0.
This means that you cannot evaluate the field with IsEmpty()
 
I also think that there needs to be an option for whether the field is checked or unchecked when empty, with a value of 1 or 0 being set when it changes.

[Matt]

As mentioned here, unchecking the box seems to clear the field rather than setting it to 0.

Unchecking sets the field to "0".

[6233638]

Unchecking sets the field to "0".

Huh, I could have sworn that it was being cleared when I tried this yesterday.

[wig]

I don't care how this value is actually stored internally, but if it were me writing it, I'd leave MC's actual field storage system alone, and just implement them as Integer fields, with the Acceptable Values automatically set to 0 and 1 only.  If you make it so the checkbox can also be a three-state checkbox (-1, 0, 1) then even better, though I won't ask for the world here.  

Here's one more plea for the three-state setup.

I've tried converting my custom fields to the Check Box setup, but without the Off setting it just isn't the same. My smartlists are as much about exlusion as inclusion.

Green Check, Red Cross?

[glynor]

I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).

Then, the labels can actually say what they are: Off (blank), State 1, State 2.

There is currently one issue with this relating to how field values display in the Panes, but that's a separate issue.

[glynor]

Huh, I could have sworn that it was being cleared when I tried this yesterday.

Remember, Zero == Clear for Integer Type fields.

Your best bet is probably to use IsEqual() to test these fields.  However, you can use IsEmpty() if you're careful to set the mode appropriately for your goal.  All Integer Type fields will be set to Zero for any "untagged" (newly imported) item.

[rudyrednose]

Is there an undefined (greyed) value ?
Am I ok to assume:

-1=undefined
0=unchecked=false
1=checked=true

[glynor]

Is there an undefined (greyed) value ?
Am I ok to assume:

-1=undefined
0=unchecked=false
1=checked=true

There is not.  They did not implement that part of it.  Values are 0 (unchecked) and 1 (checked).  That's why I said this:

I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).

Then, the labels can actually say what they are: Off (blank), State 1, State 2.

[Hendrik]

I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.

[6233638]

Remember, Zero == Clear for Integer Type fields.

Your best bet is probably to use IsEqual() to test these fields.  However, you can use IsEmpty() if you're careful to set the mode appropriately for your goal.  All Integer Type fields will be set to Zero for any "untagged" (newly imported) item.

That must be it. The first time I created a field must have been integer, and the second time will have been string.
 
IsEqual() doesn't really help since the checkbox field is empty by default.
0 or 1 would not be empty, while an unchecked field that had never been used would be.
But if it's simply a case of using string rather than integer for the field type, it's not a big deal.

I still think it is important to be able to set a field as checked by default (with no value) rather than unchecked.
This would be my main use-case.


What is the intended function of these tri-state checkboxes? Would -1 be equal to "empty" as I am using it above? (I'd prefer empty rather than -1)

[wig]

I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).

Then, the labels can actually say what they are: Off (blank), State 1, State 2.

There is currently one issue with this relating to how field values display in the Panes, but that's a separate issue.

Is this a polite way of saying I'm abnormal?  

I actually agree with you. Almost all of my custom 'tag' fields are String Fields like you describe. The problem is that updating them takes SOOOOO LOOOONG. I have to use the slow-click method or the keyboard to update the tags, and it's an ungainly process. I love the simplicity of the Check Field, but it's not just versatile enough in it's current setup.

In my perfect solution, I would to be able to choose from my Acceptable Values quickly, and using only my mouse. I've suggested a drop-down carrot that appears when you hover over a field, but I'm sure there are other solutions that would work.

What is the intended function of these tri-state checkboxes? Would -1 be equal to "empty" as I am using it above? (I'd prefer empty rather than -1)

Here's how I would use them. I have a custom field called Popular. It's starts empty, but I can then choose between 2 Acceptable Values, Popular and No. Those 3 states (Positive, Negative, Unset) are very handy when creating Smartlists for different types of listening.

[6233638]

OK, I wasn't misunderstanding then.
 
It is a three state checkbox, if you use string as the data type instead of integer.
It's empty rather than -1 though.
 
If you use integer you get <empty> or 1, not 0 or 1.
 
However this seems to persist if you change the data type.
I toggled some check marks while the type was set to integer, and they were set to 0 rather than empty when I changed it to string.

[wig]

I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.

After doing some more reading about tri-state checkboxes, I realize I'm actually using that term wrong.

What I was proposing is actually closer to a voting mechanism, like on YouTube.



A simple positive/negative model would be fabulous.

I had to admit, though, that while looking at my post preview and seeing the numbers next to the thumbs, the ability to 'vote' more than once would be extremely cool. It would open up all sort of filtering possiblities for stats nerds like me.  

[6233638]

Well that's something very different.
 
I have previously suggested an alternate rating system loosely based around that idea, but I don't think there are any plans to change the current one.
 
What I proposed would not be upvote/downvote, but better/worse/equal.
Is the currently playing track better, worse, or equal to the last?
 
I am useless when it comes to assigning hard 1-5 values for tracks - the values I assign often just depend on my mood, and I don't find Media Center's rating scale useful at all. (2 should be a neutral rating, not 3)
 
However I have no trouble making a better/worse/equal decision when comparing the current track to the previous one, which Media Center could then use to figure out a ranking for the tracks, instead of a basic 1-5 rating.

[JimH]

Is this a polite way of saying I'm abnormal?  

I thought about asking glynor for the phone number of this "normal" human being so we could hire her.

[Hendrik]

If you use integer you get <empty> or 1, not 0 or 1.

Thats to be expected, 0 in an integer field behaves the same internally as empty, as a plain integer doesn't have a "empty" state, it has to be some number.

[rudyrednose]

Tristate checkboxes can be very useful.
Default to unchecked, but have greyed as an option for users that want to use it !

If we base it on type integer (signed) we can have, whithout creating a new datatype AND WITH NO AMBIGUITY if there is a residual value:
 
value of 0 --> "unchecked" or false
value positive (1 to 0x7FFFFFFF) --> "checked" or true
value negative (0xFFFFFFFF to 0x80000000) --> "grayed" or undefined or not yet defined

This is assuming integers are 32 bit signed values in JR.  Adjust accordingly.

The benefits are
- much faster than string manipulations
- defaults to 0 (unchecked) like most new instances of an integer
- no need to define expected values / robust operation as there are no possible "out of range" values wreaking havoc
- does not prevents users of using "undefined"
- as integers, it can be used in straight IF/ELSE decisions, any value takes the IF, 0 takes the ELSE branch

[6233638]

Thats to be expected, 0 in an integer field behaves the same internally as empty, as a plain integer doesn't have a "empty" state, it has to be some number.

Well I wouldn't say that it was expected, but I understand the behavior now that Glynor explained it.
 
Rudyrednose's suggestions sound good, though I would add that it would be very useful if we could select the default state for the checkbox in its "undefined" state; checked/unchecked/inactive. (50% opacity?)

[NNTK]

I think Check type is aim to easy change tag with Check and Uncheck that have only 2 value.
So I think it should can add two Acceptable Value for explain check is, uncheck is.  Acceptable Value for explain should show in panes of panes view instead of 0, 1 and can Pane Tagging.  At pane always show two value even if them have one value.
Last, Default value should is uncheck not Unassigned.

Thank again to add Check type it mark change some tag is easily.

[rudyrednose]

I have a few additional thoughts regarding the potential third state, undefined.  

As in .Net and elsewhere in Windows, I expect it would appear as a 50% grayed unchecked box.

I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.

It is true that the undefined choice might confuse some people.

I think that in Pane Tagging mode, the mouse left click should allow to toggle between checked and unchecked (invert the current state), but would not allow to "undefine" the checkbox.  It is through the tag editor that a drop down menu would allow the three choices (0=uncheck;1=check;-1=undefined).

IMHO  

[6233638]

As in .Net and elsewhere in Windows, I expect it would appear as a 50% grayed unchecked box.
It is true that the undefined choice might confuse some people.

I can't think of the last time I saw this. I think most people would expect the unchecked appearance for undefined, not a third state.
That is why I suggested that the default state of an undefined checkbox be defined in the field as checked/unchecked/inactive.
I already have one use where I'd prefer the default state to be checked rather than unchecked or "inactive".
 
Inactive being "grayed out" either by displaying the unchecked graphic at 50% opacity, or with a third graphic if the skin includes it.
I would like to replace the current check graphic in my skin, but I'm not sure where it's being loaded from to replace it.

I think that in Pane Tagging mode, the mouse left click should allow to toggle between checked and unchecked (invert the current state), but would not allow to "undefine" the checkbox.  It is through the tag editor that a drop down menu would allow the three choices (0=uncheck;1=check;-1=undefined)

Perhaps a right-click could "undefine" the checkbox.

[rudyrednose]

I think most people would expect the unchecked appearance for undefined, not a third state.

undefined is a third state 
And opening the door to predefine the checked or unchecked status of an undefined box is opening the Pandora Box.  KISS-->undefined would be unchecked grey...

Perhaps a right-click could "undefine" the checkbox.

I thought about it, but I think it is not wise.  Right click is universally a context menu (apart for lefties who invert their mouse buttons), better not touch that...

[wig]

Well that's something very different.

A Voting field type IS different. It's also instantly familiar to anyone who's been on the internet for more than 30 minutes.

It's also useful. And fun.

I've been simulating it using my custom fields for years, but without the handy interface.

[6233638]

undefined is a third state  
And opening the door to predefine the checked or unchecked status of an undefined box is opening the Pandora Box.  KISS-->undefined would be unchecked grey...

KISS would mean that it has two states. On or off.
 
From a general user's point of view, there is no need for undefined to exist as a separate state. It is equivalent to the default state - which would usually be off, but in certain fields should be on instead. Hence the preference for the default state being on/off/inactive.

As before, an example of that would be iTunes' checked track behavior, where all tracks are enabled (checked) by default, and if the user unchecks them, they will not be played, nor will they be synced to mobile devices.

I thought about it, but I think it is not wise.  Right click is universally a context menu (apart for lefties who invert their mouse buttons), better not touch that...

Media Center already uses a lot of non-standard controls/behaviors. It wouldn't be the first.
For example, if I drag a selection with the right-mouse button rather than the left, Media Center does not then display a context menu to let me play all those files at once. I have to right-click a second time to bring up the menu.
 
You could always bring up a context menu which lets you select the state if you right-click a checkbox, but that makes things more complicated. I doubt a user is likely to right-click a checkbox unintentionally.

A Voting field type IS different. It's also instantly familiar to anyone who's been on the internet for more than 30 minutes.
It's also useful. And fun.
I've been simulating it using my custom fields for years, but without the handy interface.

Yes, but I don't see the usefulness in Media Center outside of the example I presented, which is not really "voting".
Voting is useful when you have a lot of users rating a single piece of content. Not a single user rating many pieces of content. And its discussion doesn't really belong in this topic.