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[].


On Thu, Mar 1, 2012 at 10:49 AM, Jezz_X <> 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 <>:
> 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ć <>
>> 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:
>>  - I have read as not concerning me
>> as I don't use 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:
>> some info on why it was added can be found on the PR:
>> 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.
>> _______________________________________________
>> Xbmc-addons mailing list
> ------------------------------------------------------------------------------
> 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.
> _______________________________________________
> Xbmc-addons mailing list