Thanks Marko but could you tell me how one strips off the time portion of [Last Played] so the comparison works? I couldn't find anything useful in the wiki regarding syntax for these expressions.
First of all, I'll show you how to strip the time from [last played] in case you want it later somewhere else, then I'll explain why you don't need to do that in order for the above examples to work...
So, to strip the time from an MC default date field, you tell the expression engine to work with the raw library data by adding a zero to the field, like so: [last played,0]
You then use that with the
FormatDate function to tell the expression engine how you would like the date to be formatted.
So, using the examples above, you would enter:
formatdate([last played,0],dd//MM//yyyy)You must use two 'forward slashes'. The first is referred to as an 'escape character' and tells the expression engine to treat the character that comes next literally, rather than a part of the expression formula itself. The end result is that a single forward slash is output in the expression result.
Why do you not need this extra typing in the four examples in post #1?
If you look at them, you will see "
,8". This figure instructs the expression engine in how you would like the two components to be compared.
In this case, I've used the figure, 8, which means that the compare should be a 'case insensitive sub-string compare' or in plain english, "ignore the case, if [last played]
contains this string, we have a match, and if not, we don't"
If the expression examples are not working for you, then the "day/month/year" (dd//MM//yyyy) part of the expression must be wrong for your locale. I think the USA use MM//dd//yyyy for example. Simply check how MC is displaying the date part of [last played] and mirror that in your expression, then everything should work as expected.
I couldn't find anything useful in the wiki regarding syntax for these expressions.
This Page on the wiki contains a list of expression functions, and endeavours to explain how to use them, which brings us to....
I'm going offtopic here for a second. I believe the wiki describing the Functions has the wrong structure. Or maybe the reason for the current structure escapes me.
The 'examples' are examples of syntax. Not of the functions returning actual results. If I'm an extraterrestrial from somewhere (I am - to programmers) I need to know that 1 + 1 = 2, not only that the function Addition is 1 + 1. The practical outcome is not shown. For me the extraterrestrial the meaning of 1 + 1 can be your sign for a blue medusa or a flying carpet or anything in between (colorful enough?). Therefore the learning process is shot to hell.
If you check the discussion tab of the wiki page linked above, which I presume is the one you're referring to, you'll see that over a year ago, I posted that I felt the page was a little inadequate and unwieldy. There are also currently two, possibly three expression functions that are so far not documented on that page, and I keep meaning to add them.
I will do, but, in the absence of any other firm ideas, they will get added in the same format as all the rest.
Way back, when expressions were first introduced, JRiver kept a simple web page buried in the 'dev zone' with a current list of expression functions. When the wiki was introduced, I basically ported that page into the wiki and kept adding to it, and that is why it is the way it is.
Any re-write of that page is going to take some time, so in order to for that time not be wasted, it needs to be 'done right' from the get-go.
I understand that you're saying you would find it more helpful if the expected output were given alongside the given syntax examples, which when compared to re-writing the entire page, possibly breaking it up into different pages, shouldn't take too long at all, but, is there anything else that you, or anyone else with an interest who's reading, can suggest for making the expression pages more user friendly?
-marko.