Unconsistent behavior in textboxscrollup and defines in MP 1.13 (3 Viewers)

[Sebastiii]

You are right. I realized while I was doing the lastest tests. And now, moved <textcolor>#test_textcolor_xml</textcolor> to myvideo.views.default.xml (thanks for your advice/explanation), are working .
I realized that if <define property="true">#test_textcolor_property_xml:ffff0000</define> is moved to myvideo.views.default.xml, works ok also. But in this case, it should work, even if it was in a diferent file (in the end, it's a property, no?) .

Thank you very much for you invaluable help, your time and your advice

Yep, it should work but when analyzing it, like on first check it didn't find the value (because it's in another file), MP think it's a text color, read here the '#test_textcolor_property_xml' is like a text like 'white' and this is why it failed.

I agree that maybe MP should read all files before but it didn't.
For a text it's different because there is another check in render code of GUITextScrollUpControl.cs but not for the color, the color is set before (surely to keep GPU/CPU usage etc.

So do you confirm me that all seems to works if we set property and value in the current XML ?
Thanks

 

[XMaM]

Quote to myself

[UPDATE]
Now I have seen your last post...

var rm="read_more ...";var o="... Read Less";var adjustheight=20; More or less it's demonstrated in my last test. If <define property="true">#test_textcolor_property_xml:ffff0000</define> is moved to myvideo.views.default.xml, works ok also, because is parsed/initiated in the first check. This is probably the same problem for the rest of properties that don't work.

All defines moved to myvideo.views.default.xml and EVERYTHING is working

Only one thing left: why isn't a property correctly parsed in that second check? I'm sure you will be able to find the reason for it .

[UPDATE]
I was writting while you send the previous post, but I had the same idea, so here is the answer...[DOUBLEPOST=1452940635][/DOUBLEPOST]

Yep, it should work but when analyzing it, like on first check it didn't find the value (because it's in another file), MP think it's a text color, read here the '#test_textcolor_property_xml' is like a text like 'white' and this is why it failed.

Yep, but not only fails with <textcolor>, it also fails with the other properties in <label>

 

[catavolt]

Just encountered this one
In general: defines work only in the xml were there are placed in. If you need a "global" define (working in different xmls) you must place those in a separate file, e.g. global.defines.xml and then <include> that file in all xmls were you want to use those global defines.
Your approach above was totally false and generated soleley a waste of time for Seb

 

[Sebastiii]

Ok

So we are agree that the fix made in 1.13 trigger a regression right ? or not lol ? (i'm lost).

@XMaM , i have try to see why it failed for the second check, it seems because the new skin is already loaded, so i think we need to go the way of @catavolt

 

[catavolt]

So we are agree that the fix made in 1.13 trigger a regression right ? or not lol ? (i'm lost).

No regression at all
Scenario of XMaM was wrong from the beginning (I assume misunderstanding of how defines have to be handled)

 

[ajs]

In general: defines work only in the xml were there are placed in. If you need a "global" define (working in different xmls) you must place those in a separate file, e.g. global.defines.xml and then <include> that file in all xmls were you want to use those global defines.

From WIKI: http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/18_Contribute/7_Skins/Skin_Architecture/Defines

• property - a boolean value; either "true" or "false. If "true" then the <define> is promoted to MediaPortal property status and can be used just as any other property is used (in any MediaPortal window).

 

[catavolt]

(in any MediaPortal window).

Please read carefully what I wrote XMaM tried to reference a define from another xml within his define tag which won´t work

 

[ajs]

Please read carefully what I wrote

From the WIKI, I realized that if the property where it is defined, it will work in any MediaPortal windows. like #Play.Current.Title As it does @XMaM ...

 

[Sebastiii]

Ok

But i'm not sure that all is ok with the fix from : https://issues.team-mediaportal.com/browse/MP1-4695.

In the fix, it doesn't try to see if we have a value for a define property when it's textboxscrollup, this mean that when it's a textcolor etc. the value is not parsed and then should failed, it's what i notice while debugging.

Peter can you confirm it ?

 

[XMaM]

Your approach above was totally false and generated soleley a waste of time for Seb

I agree, of course, but the beggining of all this (the main problem) really was that in 1.13 the defines placed in references.xml stopped working in textscrollboxup. Kindly, Sebastiii partially reverted the fix for 1.13 and have returned to work (tanks) without any regresion..

The other question is why a property don't work across the files. According to the wiki:

• 'global' <define> tags can be also be used in the references.xml to define global values

By promoting <define> tags to be tracked inside MediaPortal as properties skin designers will be able to use defines to transfer information from one page to another and to use those values in skin expressions and functions

In this last case, it's not clear in the wiki that the defines are working only in "one direcction". As you said, it seems that only work from the included file to the principal file (you can define in the include file and consume in the principal). Did I understand correctly?
Really, I don't need a "global" define (working in different xmls), only put a define in the main file and then use it in an include file, like <define>#header.label:3</define> in myvideo.xml that then is used in <import>common.time.xml</import> (Titan skin). But this not always worked with textboxscrollup and this was the reason for the fix that Sebastiii included in 1.13 (and unfortunately trigger a regresion).

So we are agree that the fix made in 1.13 trigger a regression right ? or not lol ? (i'm lost).

Yes. But your last change, solved it (if the rest of the remaining fix is the same that is in 1.13). The new core.dll that you posted, work well with the references.xml file.

Thanks and sorry for the inconveniences

[UPDATE]
Sorry but I don't read the last posts until now, so maybe that I said are no sense