In _most_ cases that will work, as you've enclosed the string returned from
Window.Property in double quotes. Where it won't work is if the path
happens to contain a double quote character (pretty unlikely, but still).
What will work in _every_ case** is:
<onclick>PlayMedia($ESCINFO[Window.Property(LatestMovie.1.Path)])</onclick>
Notice there's no need for the quotes.
Just remember: Whenever you pass a parameter from an $INFO object into a
builtin function, use $ESCINFO rather than $INFO.
Cheers,
Jonathan
** ofcourse, I'm assuming no bugs are present :p
2012/3/1 Predrag Mitić <[email protected]>
> OK so in this case:
>
> <onclick>PlayMedia("$INFO[Window.Property(LatestMovie.1.Path)]")</onclick>
>
> There's no need for $ESCINFO[] or did I get it wrong again?
>
>
> On 1. 3. 2012, at 4:02, Jonathan Marshall wrote:
>
> Jezz_X: I think you'll find that if you use $ESCINFO[] in any label at all
> you'll end up with quotes around the string, and with any quotes inside the
> string escaped (preceded by a backslash).
>
> All: Ok, I've taken a look, and discovered that sure enough it's
> non-trivial. However, I think there may be a way to do it. First some
> background:
>
> The builtin parser basically looks for
> function(param,param,function(param,param)) type stuff - i.e. it knows how
> to look for functions, it uses parantheses for function calling, and uses
> comma's to separate parameters. To pass in a param that has a comma you
> can quote it (and then to pass quotes you can double the quotes).
>
> The info parser, on the other hand, uses the well known
> $INFO[param,prefix,postfix] expression. Thus, square brackets determine
> start and end of "functions", comma's separate parameters again. Note that
> there's nothing stopping you combining multiple $INFO into a single "info
> object" such as: $INFO[ListItem.Label]$INFO[ListItem.Label2, - ,].
>
> At the moment, when XBMC is asked to execute an action we current pass it
> through the info parser, to resolve the $INFO[] stuff for the entire action
> string, and then pass the resulting string through the builtin parser. At
> this point, though, any comma's that result from the $INFO[] parsing that
> are inside a function get interpreted as separators for parameters. This
> is bad if that is not what we're wanting (i.e. most of the time). The
> reason it's not an easy fix is that "most of the time" doesn't cut it - if
> we want a working automatic handling it has to work all of the time, and
> currently with 2 distinct parsers this is simply not possible.
>
> However, what if we preprocess the string to convert all
> $INFO[foo,bar,zed] into Info(foo,"bar","zed"). Then, theoretically at
> least, the built-in parser will know what to do with it. What it doesn't
> know what to do with, ofcourse, is the resulting bits at the end (i.e. what
> to do with the Info functions), but I think that's the easy bit. The only
> problem is the case where two or more $INFO[] blocks are to be combined
> into a single parameter, but from a quick look the builtin parser should
> ignore that (basically as soon as you start a (...) block it ignores commas
> until you get out of it again).
>
> I doubt this will make Eden, unfortunately, as the potential for screwing
> something up is pretty high, and the potential for screwups without it
> being fixed is pretty low.
>
> Thus, I'll start work on it, but for now you'll be stuck with $ESCINFO.
> Simple rules though:
>
> 1. If you're passing $INFO as a parameter into a builtin function (eg
> SetProperty, PlayMedia etc.) then use $ESCINFO instead.
> 2. The prefix/postfix stuff won't work with $ESCINFO[].
>
> Cheers,
> Jonathan
>
> On Thu, Mar 1, 2012 at 10:49 AM, Jezz_X <[email protected]> wrote:
> Isn't the "easy alternative" just making all $INFO[] read the same as
> $ESCINFO[] ? why can we just not assume that if a , or a " is in a
> info then we want to be treated as plain text ? or does $ESCINFO use
> lots more resources ? because it seems to me like it should be the
> default way anyway
>
> 2012/3/1 Jonathan Marshall <[email protected]>:
> > While I completely agree that the skinner shouldn't have to care about
> this
> > stuff, the problem is the disconnect in that the built in function parser
> > receives only a string to parse. By the time it gets it the string is
> > already formed by piecing together the info labels that the skinner uses.
> > Thus, if the string isn't already suitably escaped, the built-in parser
> is
> > going to get it wrong.
> >
> > I can't recall the exact details, but I'm fairly sure that there wasn't
> an
> > (easy) alternative, else ofcourse I would have done it. I'll take
> another
> > look - no promises on how long it'll take to do this, as I'm quite busy
> atm.
> >
> > Cheers,
> > Jonathan
> >
> >
> > 2012/3/1 Predrag Mitić <[email protected]>
> >>
> >> Hi,
> >>
> >> thanks for feedback. Few comments from my side
> >>
> >> $ESC moves parsing string logic to the last instance that has nothing to
> >> do with coding - UI design. I don't know what are the reasons why XBMC
> is
> >> parsing strings inside $INFO and not taking it verbatim, I don't know
> why
> >> comma is being used as parameter separator inside $INFO. The way I see
> it is
> >> that this all should be handled before reaching skin. I have no idea
> what's
> >> going in background and I don't really want to know. I would like to
> >> _design_ if possible leaving all non related things to programmers as I
> have
> >> no control and knowledge about them.
> >>
> >> I'm following commits through RSS ATM and yes it's far from ideal but
> >> bigger problem is that even if I see them I may interpreting them in a
> wrong
> >> way. For instance:
> >>
> >> https://github.com/xbmc/xbmc/pull/124 - I have read as not concerning
> me
> >> as I don't use skin.properties in that way.
> >>
> >> Let's be honest - there is almost a zero chance that any skinner would
> >> think as: hey I'm trying to solve recently added layout on home screen,
> but
> >> wait.. I've seen commit about $ESC some months ago. Hmm.. This I better
> use
> >> because some character could decide to use comma in his path and since
> >> that's probably being hidden in this
> >>
> <onclick>PlayMedia("$INFO[Window.Property(LatestMovie.5.Path)]")</onclick>
> >> I'll better use them.
> >>
> >> Last but not least I would like to be sure when skin related part ends
> and
> >> XBMC code begins for trouble shooting purposes. It is already very
> messy and
> >> confusing for user as they are often sent from skin thread to script
> and/or
> >> xbmc code threads and back again in order to find where their problems
> are
> >> coming from.
> >>
> >> Peca
> >>
> >> On 28. 2. 2012, at 20:52, ronie wrote:
> >>
> >> On 28-02-12 11:27, Predrag Mitić wrote:
> >> > Use $ESCINFO[] rather than $INFO[]
> >> >
> >> > When was this changed? Consider me dumb, but except for recently added
> >> > example I have no idea where else should it be used?? I just don't
> get it.
> >> >
> >> > Do skins really need to think about this kind of issues?
> >> >
> >> > Why don't we post such things to forum? It is very hard to follow this
> >> > list as info gets mixed with code.
> >> hi,
> >>
> >> $ESCINFO[] was added about 10 months ago:
> >>
> >>
> https://github.com/xbmc/xbmc/commit/7d77070d7e14aa7d1a225e705c9c28f8755a48f7
> >>
> >> some info on why it was added can be found on the PR:
> >> https://github.com/xbmc/xbmc/pull/124
> >>
> >> the usecase is not only passing an infolabel to playmedia, basically it
> >> should be used when you pass an infolabel
> >> that may contain either quotes or commas, to a built-in function.
> >>
> >> i stumbled upon this issue last year when i was trying to copy an
> >> infolabel to a windowproperty.
> >> for example: SetProperty(MoviePlot,$INFO[ListItem.Plot])
> >> since the movie description is likely to contain a comma, the built-in
> >> function will fail in this case
> >> as it will interpret it as multiple arguments being passed to it.
> >>
> >> it's likely this info never hit the forum, as i either only used trac to
> >> report the issue or discussed it
> >> with some of the devs on irc... can't remember :-)
> >>
> >> currently the best way to stay up-to-date with skin engine changes is to
> >> keep an eye on the commits on git
> >> or check the timeline on trac. i understand many skinners consider this
> to
> >> be far from ideal, so i'm planning
> >> to start a thread in the skin-dev forum after eden, where we can collect
> >> all skin related changes for frodo.
> >> that way, everyone should have an easy overview of what's new and which
> >> things have changed.
> >>
> >>
> >> cheers,
> >> ronie
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Virtualization & Cloud Management Using Capacity Planning
> >> Cloud computing makes use of virtualization - but cloud computing
> >> also focuses on allowing computing to be delivered as a service.
> >> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> >> _______________________________________________
> >> Xbmc-addons mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/xbmc-addons
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Xbmc-addons mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/xbmc-addons
> >
>
>
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Xbmc-addons mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbmc-addons
