Print

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

[Doof]

Since I've been having good luck with the feature requests lately I thought I'd press my luck and ask if something like the following would be possible:

Currently, we can have either manually edited fields or calculated fields that use expressions. The thing I've been really really wanting is a single field that does both. Like an editable/overridable calculated field. By default, its value is whatever the expression resolves into, but it would allow you to enter in any other value you want and, if you do, it uses that value instead.

You can get this behavior by setting up a secondary field and changing your expression to use the value of that field if it has one and otherwise uses the calculated data, but this is limiting in that you can't have a view that shows both the value of this field and allow you change it without displaying both columns. An overridable expression field would allow you to do this without taking up extra view space. And it would reduce the number of fields necessary.

Is something like that possible?

[Matt]

I'm working on this today:
NEW: Added a checkbox to library fields "Allow custom data to override the expression" that will allow editing the value of an expression and then show the edited value instead of the expression (just empty to bring the expression back).

It's a little complicated, but you're such a good user!  Thanks for the idea

[Doof]

Wow, awesome! I can't wait to try this out! There are sooo many times when I've wished for this!

Thanks, Matt!

[Doof]

Just a thought, but could this allow for manually assigning the field the value of =[field name] or =[this] to let you lock in the default calculated value and short-circuit the expression from then on?

I have some expression fields that are somewhat expensive to run, but manually determining the correct value and assigning it is time consuming and a pain, so if I could MC do the heavy lifting of calculating it for me, let me review for any that I need to override, but otherwise let me easily "lock-in" the rest to prevent the expression from needing to be evaluated again, that would be amazing.

Honestly, these last few feature additions with this and the update to Field() are real game-changers for me. I'm going to end up re-writing a ton of expression fields now, but hopefully the end result will be a much more streamlined library. Thanks so much! I hope it hasn't been too much of a bear.

[Matt]

Yup, that should work.

[marko]

Just a thought, but could this allow for manually assigning the field the value of =[field name] or =[this] to let you lock in the default calculated value and short-circuit the expression from then on?

I have some expression fields that are somewhat expensive to run, but manually determining the correct value and assigning it is time consuming and a pain, so if I could MC do the heavy lifting of calculating it for me, let me review for any that I need to override, but otherwise let me easily "lock-in" the rest to prevent the expression from needing to be evaluated again, that would be amazing.

Honestly, these last few feature additions with this and the update to Field() are real game-changers for me. I'm going to end up re-writing a ton of expression fields now, but hopefully the end result will be a much more streamlined library. Thanks so much! I hope it hasn't been too much of a bear.

Sounds like exactly what I need for my [play history] field to easily turn off a lot of unnecessary, repetitive list parsing.
https://yabb.jriver.com/interact/index.php/topic,130266.msg907034.html#msg907034

Thanks Doof/Matt, great work.

[Doof]

Oh, this is so nice. I had 3 fields set up that I am now able to reduce to a single field.

v_x_SeriesPremiere: a hidden field that runs this expression If([v_b_isTVShow], FormatDate(ListMath(ListRemove(FieldQuery(Series, [Series], Date, 0, 2), 0), 0), yyyy),)
Series Premiere (Override): text field that lets me override the above.
Series Premiere: The field that views use and runs this expression FirstNotEmpty([Series Premiere (Override)], [v_x_SeriesPremiere])

I realize I could have combined the first and third into a single field, not sure why I set it up this way, but regardless, this has now been consolidated into the single Series Premiere field and allows me to simply manually override the default value. And even better, I can easily lock in the default for all the rest and avoid running this expression any more than necessary!

Awesome work, Matt! This is going to cause me to re-do my entire library from the ground up again (v5 here we come!), but this is amazing. Thank you!

[zybex]

Just a thought, but could this allow for manually assigning the field the value of =[field name] or =[this] to let you lock in the default calculated value and short-circuit the expression from then on?

This is excellent, thanks for the idea!

[marko]

Help! My head hurts...

I make a library field called 2020. It's calculated data using this expression:
listcount(listfilter([Play History],0,convertdate(2020),convertdate(2021)))

[Play History] contains a bunch of raw date values.

Now, if I add the field 2020 as a file list column, all of it's values are listed...
But, if I add 2020 as a pane, the only value returned is 0, also, when applying a search, -[2020]=[0] for example, no files are returned.
However, if I add an expression pane, using the same expression as the library field, all values are correctly listed in the pane.

I want to use this in a search list pane, and for some reason I cannot fathom, the search result is always zero. ?

Am I missing something obvious staring me in the face here?

OK, got it... If the "Allow Override" option is checked, expression results are displayed in a list column, but not in a pane, and, apparently, not available in searches either.

Bug?

[Matt]

I just tried creating a pane view and it's showing the values I edit in.

Not sure what you might be seeing?

[marko]

I just tried creating a pane view and it's showing the values I edit in.

Not sure what you might be seeing?

Here are the panes:


The expression pane (shown below) populates correctly, and uses the same expression as the field...


As you can see, the pane that uses the library field only shows one result, Zero.

Here is that library field:


If I untick the override option, press OK, then the pane with the single zero populates correctly with all the values. I also have the field in a file list column in this same view, and there, the data populates correctly, even with the override option ticked.

I want to create a search list, one search for each year, however, when I search for:

Code: [Select]

-[2019]=[0] nothing is returned, suggesting to me that the search is suffering the same problem as the pane?

I also tested this on a vanilla MC installation with play history data for one album, and see the same behaviour there.

Does that help?

[Matt]

Could you mail me a simple library backup showing the issue?  I haven't been able to reproduce yet.

I'm matt at jriver.  Thanks.

[marko]

Done.

[lepa]

Is there a way to determine if the value is from expression or from override?

[ferday]

this change has broken my expression fields

for example, i have a duration calculator based on album name, and if i make a change to the album name the field now resets, where before it just kept the text

is there a way around this, it's really annoying and has created days of tagging fixes

[Matt]

Could you mail me a library backup and instructions to reproduce?  I'll take a look when I get back from vacation.  Thanks.  I'm matt at jriver.

[ferday]

hi Matt, i've been super busy so my post wasn't very helpful, sorry

i'll try to reproduce faithfully and report back when i have some time, appreciate the response and the new field types!

[marko]

Is there a way to determine if the value is from expression or from override?

There is not. I want a way to know too, but, since you posted this question I've been trying to come up with a simple and subtle idea that would work for all skins without adding clutter to the view... I'm coming up blank!

Here's another one:
If we overwrite the data with something else, and then subsequently use the field in another expression, what data should be used?

In my quick visual tests using file list columns, the second expression runs the the first expression again and uses its result rather than just use the data used to overwrite that result in the actual field.

Personally, I would have expected that the overwritten data would be used rather than re-run the underlying expression.

Thoughts?

[zybex]

Personally, I would have expected that the overwritten data would be used rather than re-run the underlying expression.

I agree, it should return the override value.
To solve the first problem, MC could perhaps use the raw mode:

[myField] or field(myField)  -> returns the field value; for overridden expressions, returns the override value
[myField,0] or field(myField,0)  -> returns the raw field value; for overridden expressions, returns the expression value

This would allow determining if an expression is overriden by checking isequal([myField], [myField,0]).