Print

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

[Denti]

However, MC itself already has this special Name Category function. 

What or where is this? You just mean at the Category level of Standard View?

[Denti]

I think the reason it works is that, internally, the special Name Category gets data from the source Category "already processed".  So it never sees the list-type fields as semicolon delimited strings, but just individual string items.

Then, it can reprocess them itself.

That's pretty cool. To be clear, that's why I left this thread open and didn't want it all to move to the other discussion. The issue isn't a sorting problem. It is something more fundamental.

However, MC itself already has this special Name Category function.  What we need, I think, is a more generic version of that: a "pointer category".  If we had that, it might solve this and a whole class of display issues in MC.

Any way to rally support for this?

Or should I resign myself to duplicating files...

[glynor]

What or where is this? You just mean at the Category level of Standard View?

Yes.  That's what I meant.

I've had some more thoughts on this over the past week, but no time.  I'll come back with more this weekend.

[Denti]

Bump. Still interested in solving this.

[Matt]

My reading of this is that there might be a bug somewhere, but it's so long and dense that I'm struggling to find it.

Would you be willing to state the bug as simply as possible?  Give a simple example if it's possible.

Thanks.

[6233638]

My reading of this is that there might be a bug somewhere, but it's so long and dense that I'm struggling to find it.
Would you be willing to state the bug as simply as possible?  Give a dirt simple example if it's possible.
Thanks.

In short:
In Standard View [Name] returns the name of a category.
In Theater View [Name] is applied to the items inside the category.
 
The simplest example I can think of is to create a new view where the rule for files to display points to a single compilation album. (i.e one with multiple artists)
In Standard View, set the category to [Artist] and thumbnail display to [Name]
In Theater View, set the expression to group by [Artist] and the expression to display to [Name]
 
Standard View returns artist names for [Name]
Theater View returns track names for [Name]
 
So any expression which tries to modify [Name] e.g. an expression to swap first and last names, tends to break in Theater View.

[Hendrik]

Personally I think the Theater View behavior is more consistent, if anything. I assume any other fields also behave the same way even in Standard View, ie. reporting data for the files inside the category, instead of being "special"?
This special name behavior should probably just be a function instead of overriding the Name field.

I don't know why they behave differently though, and it may in the end be easier to override the Theater View [Name] field instead of mocking with a new expression, which probably doesn't even know the value for this field, since it would be on the "outside".

[glynor]

This special name behavior should probably just be a function instead of overriding the Name field.

It should be a separate "field" called [Category] (or an equivalent function), because that is what it is.  Using [Name] has always been weird. It violates the "rules" of square-bracket field notation.

[Denti]

It should be a separate "field" called [Category] (or an equivalent function), because that is what it is.  Using [Name] has always been weird. It violates the "rules" of square-bracket field notation.

This would be great!

What is the expression behind the [Name] field in Theater View? Is it an expression? If so, I would be perfectly happy creating my own custom field with it.

[6233638]

Thinking about it some more, I agree.
It would be more consistent to change how [Name] behaves, and introduce a new field.
 
[Name] returning track/file names should be what it does, since that is what's inside the name tag.
A new field to display or modify the category name, such as [Category] would be more consistent.
 
Only I don't know what you would want to do about Standard View.
Would you modify it to use the same logic as Theater View? That would probably break all existing views, which use [Name] for the "Thumbnail Text" by default.

[glynor]

Personally I think the Theater View behavior is more consistent, if anything. I assume any other fields also behave the same way even in Standard View, ie. reporting data for the files inside the category, instead of being "special"?

Theater View is more consistent. The special behavior only applies to Standard Media Views set to Categories style. Those in Panes style behave exactly like Theater Views, as do those in Media Network Views.

The special use of the term [Name] is limited to only Categories-style Standard Views.

[Hendrik]

I bet it would unleash quite the storm if I were to break this use-case of [Name], and move it to a different field or something, huh.
Not like [Name] is actually useful on a category group, you can't really do anything useful with that, so maybe I should just leave it be and make Theater View also do that? I bet for some reason that would also break someone elses workflow, though. Somehow something is always broken for someone with such changes. :p

[JimH]

You're screwed. 

[Denti]

I bet it would unleash quite the storm if I were to break this use-case of [Name], and move it to a different field or something, huh.
Not like [Name] is actually useful on a category group, you can't really do anything useful with that, so maybe I should just leave it be and make Theater View also do that? I bet for some reason that would also break someone elses workflow, though. Somehow something is always broken for someone with such changes. :p

I doubt anyone uses [Name] in the Theater View for song titles, which is what it displays, I think. I mean, really, who would use that? I think you're safe making it do what it does inn Standard View.

Please. 

[glynor]

I use [Name] as a category fairly often in Theater View (and Panes-style Standard Views, and Media Network Views).  Two reasons:

* Grouped (so it shows A-B, C-D, etc).
* To combine episodes of shows with movies into a single View (which I do with Documentaries). Here it does a If(IsEqual([Genre]) test to check what the type is, and then displays either [Series] or [Name] as the Category output depending on the result.

That way be dragons.

[Hendrik]

If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?

[Denti]

If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?

I'm not following. I simply want [Name] to do the same thing in Theater View as it does in Standard View. Can we somehow make that possible? Even if it simply means creating a new field for it.

[glynor]

I'm not following. I simply want [Name] to do the same thing in Theater View as it does in Standard View.

It only does it in certain conditions in Standard View (only within Views set to Categories view mode). Most of mine are not in Categories, so to me, having [Name] altered across the board spells danger.

If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?

Thinking on it. I don't know.

It definitely seems counter-to-expectations that all square-bracket notation works one way, except for [Name] which is weirdo. Whomever decided to use that notation for the special behavior of Categories style views probably didn't think it out fully.  We don't know what we don't know, you know?

I'd be much more comfortable with "fixing it right" and using [Category] or CategoryName() or something like that, surely. It would cause some short-term pain in fixing a few Views for people, but perhaps at the MC21 division this wouldn't be so bad?

Not sure. But, thinking on it.

[Denti]

I'd be much more comfortable with "fixing it right" and using [Category] or CategoryName() or something like that, surely. It would cause some short-term pain in fixing a few Views for people, but perhaps at the MC21 division this wouldn't be so bad?

This seems reasonable. How feasible/doable is it, Hendrik?

[Denti]

Checking back. I'm stubborn, and while patient, I'm not giving up on this.   

[Denti]

So, any developments?

[Denti]

So then, it will be addressed? Nice. I can be patient.

Any chance this has been or will be addressed? I'm still hoping!

[Dawgincontrol]

They are done with version 20.  Try asking on the version 21 board if you are thinking of upgrading.

[Arindelle]

its not necessarily a version issue

I replied (euh, at length  ) to this in Denti's other post here http://yabb.jriver.com/interact/index.php?topic=101338.msg704591#msg704591