INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: chrisjj on June 21, 2013, 05:35:12 pm
-
Can anyone tell me what makes [Filename (path)] preferred over FilePath(...), as stated below? Thanks.
http://wiki.jriver.com/index.php/Media_Center_expression_language#FilePath.28....29:_Returns_the_path_from_a_specified_filename says
FilePath(...): Returns the path from a specified filename ... Media Center has a [Filename (path)] library field by default, which is probably easier to use or reference than this function.
-
I'm not sure, but guessing...
[Filename (Path)] is a Database function.
FilePath(...) is an expression.
I'd guess speed (though internally one might just route to the other). There are still a few places in MC where you can't use Expressions but database fields are cool. Maybe just that...
-
I believe certain functions predate the availability of their equivalent field reference syntax (i.e. [fieldname]). Hence, some functions are now syntactically deprecated.
Ultimately [Filename (path)] and FilePath() end up calling the same code.
-
From the header of that wiki section:
Taken at face value, all of the functions in this section would appear to be a little on the redundant side, falling neatly into the "a long way for a shortcut" category. Media Center could possibly rely on these functions internally, exalting their status to "highly useful" or "essential" even, but as this page is designed for end users, not Media Center, end users will find these functions redundant, and they are included here in the name of completeness only.
They both return exactly the same result, and if you need the file path, or want to base other conditions around it, the library field is just so much easier to work with. The path of least resistance, if you like ;)
-marko
-
Thanks all
"all of the functions in this section would appear to be a little on the redundant side, falling neatly into the "a long way for a shortcut"
That puzzles me, because this function call is shorter than the field reference.
Thanks alland if you need the file path, or want to base other conditions around it, the library field is just so much easier to work with.
Aha. I'm sure I must have missed something here. Can you give me an example?
-
The 'Filename (path)' field is just a shortcut. This way the list of fields when you right-click on a column header, etc. includes an easy way to show the path.
Also, FilePath(...) is a little more generalized. It takes an optional filename, so you can do something like this as opposed to only looking at the current file:
FilePath(C:\Test\1.mp3)
FilePath(Load(v))
etc.
-
Also take note, some functions under the "Redundant Functions" section in the wiki have been promoted. For example, Filename() was modified to accept a parameter to suppress the file suffix. Thus, it has additional use over the shortcut [Filename], so is no longer "redundant".
-
The 'Filename (path)' field is just a shortcut.
I have to say it looks like a long cut to me.
This way the list of fields when you right-click on a column header, etc. includes an easy way to show the path.
Yes, I appreciate that advantage having the alias 'Filename (path)'.
Also, FilePath(...) is a little more generalized. It takes an optional filename
That suggests its categorisation as redundant is incorrect.
-
Also take note, some functions under the "Redundant Functions" section in the wiki have been promoted.
Not this function, though.
For example, Filename() was modified to accept a parameter to suppress the file suffix. Thus, it has additional use over the shortcut [Filename], so is no longer "redundant".
It seems the same applies to this function.
-
Its true. Technically the function FilePath() can be used with an arbitrary path. And marco probably knew that when he wrote the excellent wiki page. Practically speaking though, the function would almost always been used with only the current Filename, so in that sense, doesn't need to be used.
For accuracy, I'll probably move the function and add some clarification. I'd like that you sleep better.
-
For accuracy
Sounds like a good reason to me :)