Print

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

[gappie]

that was the smoothest version upgrade so far.. picked up all my 16 settings. nice.

there seems to be a problem with the text under album thumbs when using an expression (or something has changed what i have not found yet).
i use an expression under my albums

Code: [Select]

LP FormatNumber([Played Days Ago,0],1) days agoeasy. where [played days ago] is a custom library field what does what it says, and that works. in 16 this expression would give me the average of [played days ago]. now i get values that do not make any sence when looking at [played days ago]...

 
gab

oh.. i see what it does now... when all the values are the same.. say 10, it gives 10. but when it says for instance 1, 100 , 100 ,3 (so the value is different for different songs of the album) it gives 0.

[gappie]

that was the smoothest version upgrade so far.. picked up all my 16 settings. nice.

there seems to be a problem with the text under album thumbs when using an expression (or something has changed what i have not found yet).
i use an expression under my albums

Code: [Select]

LP FormatNumber([Played Days Ago,0],1) days agoeasy. where [played days ago] is a custom library field what does what it says, and that works. in 16 this expression would give me the average of [played days ago]. now i get values that do not make any sence when looking at [played days ago]...

 
gab

oh.. i see what it does now... when all the values are the same.. say 10, it gives 10. but when it says for instance 1, 100 , 100 ,3 (so the value is different for different songs of the album) it gives 0.

to quote myself, and what has changed apparently..
in all the previous versions, when you wanted to use a custom calculated database field to behave as a list or as an integer, you first have to make the field and set the userdata to integer or list, close manage library fields>options and then open again and change it to calculated with the right expression. when i do that with mc 17 the user data is reset to string when i switch to calculated and behaves that way.

 
gab

[Matt]

to quote myself, and what has changed apparently..
in all the previous versions, when you wanted to use a custom calculated database field to behave as a list or as an integer, you first have to make the field and set the userdata to integer or list, close manage library fields>options and then open again and change it to calculated with the right expression. when i do that with mc 17 the user data is reset to string when i switch to calculated and behaves that way.

 
gab

You need to add a type to the expression if you want it to be something other than a string.

For example:
Math(1+2)&DataType=[Integer]

[gappie]

You need to add a type to the expression if you want it to be something other than a string.

For example:
Math(1+2)&DataType=[Integer]

thanks math,
up from 11 til 16 it worked. now it does not. and as far as i tested your solution is not only much more complicated, but does also not work. and i just checked, i did use math already in the lib field, but for the album thumb math wont do any good.. it stil is math([varies]).. and for mc that is 0.
ill make an separate thread later cause i think this will be a long discussion, and is really three steps back for the library..

 
gab

[Matt]

your solution is not only much more complicated, but does also not work.

There was no solution for non-string expressions before.  You had found a backdoor to change the type, but that's not a less complicated solution.

Here are the supported types (the expression must end with exactly this including brackets around the type):
&DataType=[insert type here]

Where 'insert type here' is one of these
String
List
Integer
Number
Path
Month

Example:

Code: [Select]

a;b;c&DataType=[List]


[gappie]

There was no solution for non-string expressions before.  You had found a backdoor to change the type, but that's not a less complicated solution.

oof.. and i always thought it was the main entrance. 

Here are the supported types (the expression must end with exactly this including brackets around the type):
&DataType=[insert type here]

Where 'insert type here' is one of these
String
List
Integer
Number
Path
Month

Example:

Code: [Select]

a;b;c&DataType=[List]


ofcourse i know them and use them sometimes.  but i made some test fields and indeed those i never needed, work.. have to go to a bunch of old fields now to see why they dont work anymore. but i guess ill find that.

still i think not disabling the user data settings when enabling the calculated data would be a much easier solution, it always worked that way except for the route (backdoor) around the useless disabling.

anyway, i am looking forward to what 17 will bring.
thanks matt

 
gab

[Matt]

still i think not disabling the user data settings when enabling the calculated data would be a much easier solution, it always worked that way except for the route (backdoor) around the useless disabling.

Yes, that would be easier in the case of fields.  I'm not exactly sure why it's like that.  One trick is that expressions are often used outside of fields (panes, columns, etc.) and those places also need a way to specify a type.

Another solution would be for the expression editor to have a way via the menu to say "treat the output from this expression as this data type."

[gappie]

i agree matt. remember, before for using datatype=[ list ] in library fields, you had to set the user data to list before making the calculated data using lists. as in this thread: http://yabb.jriver.com/interact/index.php?topic=57477.msg390024#msg390024.. and many more.
haven't tested lists yet, but i think the problem always was (and still is) that this datatype expression is to much hidden and not clear for most people, but can be so essential to get what you are after. so adding it to the menu for expressions and library fields would make it much more clear and easier to use expressions.

 
gab

[marko]

I've used this "back door" solution on so many fields... I've also linked to gappie's threads from the expressions page on wiki, touting it as a viable solution to this issue.

still i think not disabling the user data settings when enabling the calculated data would be a much easier solution, it always worked that way except for the route (backdoor) around the useless disabling.

On the surface, this would appear to be the simplest solution, as well as keeping the "&DataType=" appendages for use in expressions elsewhere.

While we're on the subject, when using the listbuild() and listcombine() functions, in my mind, "&datatype=[ list] is implied, I mean, why else would anyone use these expressions... Even though I know, everytime, I have to go back in and add the datatype specifics after the fact!!

-marko