INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: gappie: Data type of expression fields  (Read 2900 times)

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4566
gappie: Data type of expression fields
« on: November 05, 2011, 08:00:37 am »

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.
Logged

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4566
gappie: Data type of expression fields
« Reply #1 on: November 05, 2011, 10:52:11 am »

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
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42028
  • Shoes gone again!
gappie: Data type of expression fields
« Reply #2 on: November 07, 2011, 11:47:07 am »

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]
Logged
Matt Ashland, JRiver Media Center

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4566
gappie: Data type of expression fields
« Reply #3 on: November 07, 2011, 01:52:05 pm »

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
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42028
  • Shoes gone again!
Re: gappie: Data type of expression fields
« Reply #4 on: November 07, 2011, 02:52:13 pm »

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]
Logged
Matt Ashland, JRiver Media Center

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4566
Re: gappie: Data type of expression fields
« Reply #5 on: November 07, 2011, 04:25:38 pm »

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.  8) 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
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42028
  • Shoes gone again!
Re: gappie: Data type of expression fields
« Reply #6 on: November 07, 2011, 04:46:15 pm »

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."
Logged
Matt Ashland, JRiver Media Center

gappie

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 4566
Re: gappie: Data type of expression fields
« Reply #7 on: November 07, 2011, 05:14:06 pm »

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
Logged

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8967
Re: gappie: Data type of expression fields
« Reply #8 on: November 08, 2011, 12:35:24 am »

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.

Quote
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
Pages: [1]   Go Up