Print

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

[cncb]

7. NEW: Editing a checkbox type field in the new Tag Action Window will show a checkbox instead of a dropbox.

As reported before, the checked value doesn't "stick" (click off the file to clear selection and re-select then it reverts to unchecked).

[RoderickGI]

7. NEW: Editing a checkbox type field in the new Tag Action Window will show a checkbox instead of a dropbox.

As reported before, the checked value doesn't "stick" (click off the file to clear selection and re-select then it reverts to unchecked).

I tried to duplicate your problem with a couple of Checkbox fields I set up recently. One is a String field, Edit Type Check, Relational with one value per Series, restricted to video and TV data types. The other is a simple String field, non-relational, Checkbox set for individual files.

I couldn't create the problem.

Then I remembered, when I first created the fields they would not work properly. Not exactly as you describe, but I had some trouble making it stick, and then filtering on it didn't work as I expected.

The problem was the I hadn't initialised the new field before trying to use it. It had no value, and as a Checkbox type field it should have had a 0 or 1 in it. I selected all files, checked the box, let it update, then un-checked it again. After that the checkbox and filtering on the field worked.

Could this be your issue as well?

Note: As per the build thread, I did manage to crash MC using the checkbox functionality, consistently.

[glynor]

Don't make your checkbox fields Strings.  Make them Integer fields instead (and make acceptable values: 0;1 for good measure). Integer fields always pre-initialize to zero. Strings initialize blank, which is treated as an unchecked box, but doesn't actually contain zero (and so is distinct from one you checked and then unchecked).

Plus then you can do math on them if you ever need to, which can come in handy.

FWIW, I too remember seeing some wonkiness with the new Checkbox-in-the-Tag AW control too. I remember distinctly being busy doing something, and finding some weird behavior and thinking "I have to report that" but being busy... And now I don't recall.

So, I'm useless.

But, don't make them strings unless you want them not pre-initialized for some reason.

[RoderickGI]

So, I'm useless.

Hardly! 

Good tip. I'll change them to Integers, if that is possible . . . looks like I can, so I will later.

I was copying someone else's setup. I wondered about whether a String field was right. Soon fixed.

[glynor]

if that is possible . . . looks like I can, so I will later.

Yep. Should have no ill effects, as long as you aren't relying upon them for anything super-complicated (and don't care that your blanks will all become zeroes).

[cncb]

Don't make your checkbox fields Strings.  Make them Integer fields instead (and make acceptable values: 0;1 for good measure). Integer fields always pre-initialize to zero. Strings initialize blank, which is treated as an unchecked box, but doesn't actually contain zero (and so is distinct from one you checked and then unchecked).

I just created a new field exactly in this manner but it still won't work for me.  I check the box in the Tag Window, click off the file to deselect everything, and when I re-select the file it is unchecked.

[blgentry]

Ok, I can confirm this, but it's really weird.  If you set a checkbox field, while in a file list of some sort, the checks will stick as long as you STAY IN THE SAME PLACE in the view.  Clicking around on different files, you'll see the value (set or unset) of the check box.  Including the ones you just checked.  But go to a different part of the view (like click on a different album in albums view for example), and then come back to the files you were working on and the check disappears.

It's even weirder:  Make your checkbox field visible as a column at the same time.  Check some values using the Tagging Window.  Switch to another album.  Switch back.  The checks are still there!  But wait.  Switch away again.  Switch back.  Checks are all gone!

I haven't tested all permutations of this, but the steps I describe above definitely exhibit the bad behavior for me.

BTW:  MC21.0.19 on Mac.

Brian.

[Matt]

I'm having troubles reproducing any problems.

I made the field a string and then clicked between different albums in the Artists view.

Setting and unsetting just works perfectly.

Any other tips?

Thanks.

[blgentry]

I'm doing my testing with fields that are Integer type with Edit type set to Checkbox.  Doing all of the setting and unsetting in the Tagging Window.  The regular one, not the experimental one.  I've done all my testing from the Albums view.  I just tried from the Artists view and I found something new:

If you set the checkbox for the whole album, it works just fine.  But if you click in the songs list below and set the checkbox for individual songs, then the bug appears.  Set it for a song or two.  Switch to a different album and back.  The checks disappear.

Brian.

[cncb]

For me, a view of image thumbnails, all I have to do is check the field and then deselect all files instead of selecting another file.   Then it will be unchecked when I select the file again.

[RoderickGI]

Note, I'm testing again on my MC Client Workstation.

For me, a view of image thumbnails, all I have to do is check the field and then deselect all files instead of selecting another file.

Do you leave the checkbox field "open" with the box still displayed? Because that would leave the tag in an unsaved state. If I do what you are doing, but using a TV Series display, then when I highlight the series again (without leaving the view, just clicking on another series after checking the box), the checkbox is still "open" in edit mode. Clicking on the tag name in the tag window closes the edit mode and saves the value "1" in to the field, which is what is displayed in the tag value field.

Perhaps clicking anywhere away from the checkbox tag field should save the value and close the field for edit. It definitely isn't doing that at the moment.

Then it will be unchecked when I select the file again.

I have the Checkbox field visible as a column in my view. When I click on the Checkbox at the Series level, with the files list open below, checking the box takes a deliberate click. I have been able to confuse it a bit by checking and unchecking the box a lot, so that sometimes it takes longer to get the check to stick, but usually it works first go. However, the tick mark isn't always immediately displayed, and sometimes not until I move the mouse over it, both at the series level and the file level. So there is some delay in the field value display update.

Usually, however, it updates in the tag window pretty much immediately, and when it does the checkboxes at the series and file level in the view update immediately. I thought maybe you were double clicking the field, so checking and then unchecking, but that seems unlikely.

If clicking the tag name to close the checkbox field for edit doesn't make the check stick, what happens if you click the checkbox, then press enter to uncheck it, and then press enter to recheck it, and then click the tag name? Did that make it stick?


And then a can of worms fell open . . .
On a different, but possibly related issue, and another form of weirdness observed while testing.

I know the space bar is interpreted as Pause/Play, but while testing if the checkbox could be set using the space bar, I saw some unexpected behaviour.
1. If I clicked on a series name or program file and pressed the space bar, nothing happened, as expected.
3. If I then clicked on the Keywords tag name in the tag window, which opened it for edit, and then clicked on it again to close the edit, then pressed the space bar, the first file in the series starts to play. When I mouse up to the top of the screen the Media Controls pop down as usual and I can stop playback.
2. If I clicked the tag name of a checkbox field and left the field "open" for edit, and then pressed the space bar, the first file in the series starts to play. When I mouse up to the top of the screen the Media Controls do not pop down as usual. I have to use Ctrl-1 to get back to Standard View and stop playback there.
3. If I then click on the tag name of the checkbox field to close the field for edit, and then press the space bar, the first file in the series starts to play. Now again when I mouse up to the top of the screen the Media Controls pop down as usual and I can stop playback.

Conclusions:
a. Pressing the space bar after clicking on a tag name in the tag window causes MC to start playing the currently selected Series/File, unless the tag is open for edit and "space" is a valid input. In contrast, pressing the space bar when just highlighting the series or file in a view does not cause MC to start playing the file.
b. Leaving a tag field in the "open" for edit status prevents MC from displaying the Media Controls at the top of Display View.

Neither sound right to me.

[cncb]

Do you leave the checkbox field "open" with the box still displayed? Because that would leave the tag in an unsaved state. If I do what you are doing, but using a TV Series display, then when I highlight the series again (without leaving the view, just clicking on another series after checking the box), the checkbox is still "open" in edit mode. Clicking on the tag name in the tag window closes the edit mode and saves the value "1" in to the field, which is what is displayed in the tag value field.

This is exactly what is happening.  Thanks!  It seems that all the other edit types "commit" the setting when you click off the Tag Window so it seems that this should behave the same way.

Another strange thing I found while testing this is that when you edit a field in the Tag Window with no files selected, the change is applied to all files in the list?  This does not seem right to me at all.  In my opinion, if nothing is selected then the Tag Window should be disabled.

[glynor]

Another strange thing I found while testing this is that when you edit a field in the Tag Window with no files selected, the change is applied to all files in the list?  This does not seem right to me at all.  In my opinion, if nothing is selected then the Tag Window should be disabled.

This is correct.  I think it is to allow you to speedily mass-edit tags. So, for example, to apply a tag to an entire artist worth of files, you can just select the pane in question (then all files are, in effect, selected) and change something in the Tag AW.

But, I agree, it is dangerous, and probably not worth the tradeoff if it is that way on purpose (and it has been that way a long, long time, as long as I can remember).  In fact, it could be related to this:
https://yabb.jriver.com/interact/index.php?topic=101408.0

I moved the rest of my post over to that thread because it makes more sense there (and a subsequent related reply from cncb).

[glynor]

I found a bug here that I can reproduce and which I think matches the "weirdness" I saw before.

When you edit a field using the Tag AW, and you "click away from" the field in the AW by clicking onto another field, this will typically "de-select" the currently editing field and then enter edit mode on the one you clicked.

This is broken when you are editing a Check-style field in the Action Window.  When you "de-select" it by clicking onto another field in the Action Window, it does jump and start editing a field, but not the one you clicked on.  It seems to pick one somewhat at random (I'm sure it is offset from the current one, or clicked position somehow, but in any case, it is not the one you chose).  It also seems to go screwy with the Action Window editor type in certain cases (I've sometimes had it open up normal string-type fields in the full height list-type field editor).

This only happens if you actually change the value of the Check field.  If you just click onto, and then off of it, everything works correctly.

This is easier to show than explain:
https://vimeo.com/147379666

[RoderickGI]

I found a bug here that I can reproduce and which I think matches the "weirdness" I saw before.

I thought I had written something about that before. In fact I'm sure I did, amongst other tagging comments. Ah yes, here it is: http://yabb.jriver.com/interact/index.php?topic=101400.msg703375#msg703375

If I clicked on a tag name instead of the value area, MC didn't crash.
If I clicked on a different series name in the view, MC didn't crash, but it did leave the tag value area in edit mode, even on the new series.
Unchecking the Checkbox didn't have the same effect, but it did do strange things, like opening the value field for edit on a completely different tag, way down the list.

Anyway, your video clearly shows what I also saw happening.