You are not logged in.

Dear visitor, welcome to Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.


Thursday, January 10th 2019, 6:56pm

Overload attributes with GET:


I've been using GET: a bit and it seems like if you use a GET: in a given attribute, then one cannot overload this attribute.

<hotspot name="myhotspot" type="text" visible="true" distorted="true"
ath="0" atv="0"

<hotspot name="myhotspotcopy" type="text" visible="true" distorted="true"
ath="20" atv="0"

<!-- override of myhotspotcopy -->
<!-- override of ath works perfectly, override of html does not -->
<hotspot name="myhotspotcopy" type="text" visible="true" distorted="true"
ath="90" atv="0"
html="this text should be shown"

The last override should make the myhotspotcopy hotspot move (as ath changes) and the text change (as html changes).
But only the ath gets overloaded.

Actually anywhere I use GET: , afterwards I cannot overload this attributes. Seems likes using GET: blocks any overloading.

Normal? Bug?




Posts: 3,339

Location: Netherlands

Occupation: Krpano custom coding / Virtual Tours / Photography / Musician / Recording engineer

  • Send private message


Thursday, January 10th 2019, 9:57pm


Use like get(hotspot[bla...etc );

get: has other use.

Hope it helps.
Tuur *thumbsup*


Saturday, January 12th 2019, 3:57pm

- Using get() does not seem to be possible in attributes
- documentation says GET: is meant to be used that way, and Klaus himself uses it in vtourskin.xml, what am I doing wrong?


When the value of a xml attribute starts with get: or calc::
In this case the value for the xml attribute will get from an other variable or calculated using an expression

And in the doc about overwrite, it says :


All xml elements and attributes in the krpano xml are optionally and can be defined a several times and in any order. When the same element will be defined again two or more times, then the later/following declarations will overwrite the previous one.
Nothing says GET: attributes cannot be overriden.

I can of course use get() in actions, it's a way round I was using a lot, before GET: was introduced. But styles are so nice to use, and a bit more concise than actions (a simple loadstyle instead of multiple set(attribute, value) lines)


Sunday, January 13th 2019, 10:18pm

Just from top of my head (without testing) seems that's all about timing. Although the source hotspot is written in the xml code above the hotspot with GET: statement it does not mean that the hotspot is already available when loaded for the particular scene.
I do my settings in onloaded="set(html, get(source.html))"
The "cleanest" way is apparently using onloaded"callwhen(source.loaded, set(html, source.html))"

Please correct me if I'm wrong.
Thank you,


Monday, January 14th 2019, 3:38pm

Yep, I also got to use that onloaded way-round *g*
But anyway, documentation says "the later/following declarations will overwrite the previous one", which in this case is not true


Monday, January 14th 2019, 6:11pm

i noticed that behaviour, too
it also happens when using multiple xml files

ie. you want to override your main xml in an included xml
overriding a get: statement does NOT work in this case, too
I just tested it now.

this strikes me as very odd and may be a bug.


Tuesday, January 15th 2019, 10:17am


right, once using get: or calc: it is currently not possible to overwrite that setting again with a normal value...

The reason is that attributes with get:/calc: are getting put to a special list during the xml parsing and evaluated after the main part of the xml parsing is done.

To allow overwriting these attributes again with normal values, it would be necessary to check each time for every other attribute if it is also on that list, and that could be inefficient and slow...

But I will check and measure that in detail and maybe by using a hash-table instead of a list it might be possible to keep the slow-down for supporting this as low as possible...

Best regards,


Tuesday, January 15th 2019, 10:33am

But I will check and measure that in detail and maybe by using a hash-table instead of a list it might be possible to keep the slow-down for supporting this as low as possible...

Update: I have checked and updated that now to internal hash-table usage and the performance is okay.
That means in the next version overwriting/redefining xml attributes that used get:/calc: will be possible.


Tuesday, January 15th 2019, 11:45am

happy new year klaus :)

fastest problem fixer ever :-D




Monday, January 21st 2019, 6:32pm

Thank you Klaus for fixing this behaviour!


Friday, January 25th 2019, 12:27pm

Super! Thank you for including this in the next update already