Sie sind nicht angemeldet.

Bug defining width with calc: on Krpano 1.19 pr10

Lieber Besucher, herzlich willkommen bei: krpano.com Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

360boy

Fortgeschrittener

  • »360boy« ist der Autor dieses Themas

Beiträge: 249

Wohnort: Mexico City

Beruf: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Nachricht senden

1

Mittwoch, 2. August 2017, 18:28

Bug defining width with calc: on Krpano 1.19 pr10

Dear Klaus,

I just found this very strange issue with defining width of a layer with --> calc: command EXAMPLE HERE . Three layer containers, one is supposed to have a width assigned by the addition of the widths of the other two (red one at the link example). Same code works fine when they're not inside another container. Krpano 1.19-pr10.

It was some hours till I found this, please check this out.

Best

Luis

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<krpano>
		    		    
	<preview type="grid(cube,16,16,512,0xCCCCCC,0xFFFFFF,0x999999);" details="16" />  		    

	<layer name="interface_container" type="container" keep="true" enabled="true" bgalpha="0.5" width="600" height="600">
        <layer	name="button1" type="container" width="calc:(layer[button2].width + layer[button3].width)" height="30" bgalpha="0.5" bgcolor="0xFF0000" bgborder="0,1,1,1 0xeeeeee 1" align="lefttop" y="130" x="20"/>
        <layer	name="button2" type="container" width="70" height="110" x="290" y="20" bgalpha="0.5" align="lefttop"/>
        <layer	name="button3" type="container" width="270" height="110" bgalpha="0.7" bgcolor="0xFFFFFF" x="20" y="20" bgborder="1 0xEEEEEE 1" align="lefttop" />   
    </layer>

	<layer	name="button4" type="container" width="calc:(layer[button5].width + layer[button6].width)" height="30" bgalpha="0.7" bgcolor="0xFF0000" bgborder="0,1,1,1 0xeeeeee 1" align="righttop" y="130" x="20"/>
	<layer	name="button5" type="container" width="70" height="110" x="290" y="20" bgalpha="0.5" align="righttop"/>
	<layer	name="button6" type="container" width="270" height="110" bgalpha="0.7" bgcolor="0xFFFFFF" x="20" y="20" bgborder="1 0xEEEEEE 1" align="righttop" />   
    
</krpano>
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

klaus.krpano

Administrator

Beiträge: 13 499

  • Nachricht senden

2

Donnerstag, 3. August 2017, 00:43

Hi,

that's a bit a special case - or said in a other way: there is a reason why this code isn't working.

First it necessary to know that defining <layer> elements inside other <layer> elements is internally a 'shortcut' for setting their parent setting.

E.g. this:

Quellcode

 
1
2
3
4

<layer name="parent_layer" ...>
  <layer name="child_layer_1" ... />
  <layer name="child_layer_2" ... />
</layer>

is the same as:

Quellcode

 
1
2
3

<layer name="parent_layer" ... />
<layer name="child_layer_1" ... parent="parent_layer" />
<layer name="child_layer_2" ... parent="parent_layer" />


The second thing is that the 'get:' and 'calc:' in attributes will be resolved at 'xml parsing time'. That means during parsing and transforming the xml code into read- and work-able data-structures. First all attributes with such get/calc values will be 'collected' and once the whole xml is parsed - and so all other attributes and values are accessible - they will be resolved.

But at this time, the xml data structure is still a 'raw' one, the <layer> children elements weren't converted yet to 'root-level' <layer> elements with a parent="..." setting. That happens during the next internal step after the xml parsing is done when creating the internal image, layer and hotspots objects that will be used for rendering and interacting.


That means for get:/calc: attributes the FULL 'xml path' would need to be used to address the right object/value:
E.g.

Quellcode

 
1

layer[interface_container].layer[button2].width

Or here a full example code:

Quellcode

 
1
2
3
4
5

<layer name="interface_container" type="container" keep="true" enabled="true" bgalpha="0.5" width="600" height="600">
  <layer name="button1" type="container" width="calc:(layer[interface_container].layer[button2].width + layer[interface_container].layer[button3].width)" height="30" bgalpha="0.5" bgcolor="0xFF0000" bgborder="0,1,1,1 0xeeeeee 1" align="lefttop" y="130" x="20"/>
  <layer name="button2" type="container" width="70" height="110" x="290" y="20" bgalpha="0.5" align="lefttop"/>
  <layer name="button3" type="container" width="270" height="110" bgalpha="0.7" bgcolor="0xFFFFFF" x="20" y="20" bgborder="1 0xEEEEEE 1" align="lefttop" />   
</layer>


But I agree that this is confusing and it would make more sense to have access to the 'flat' <layer> structure also for get:/calc: attribute values. I will look if that can be changed.

Best regards,
Klaus

360boy

Fortgeschrittener

  • »360boy« ist der Autor dieses Themas

Beiträge: 249

Wohnort: Mexico City

Beruf: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Nachricht senden

3

Freitag, 4. August 2017, 21:41

Very clear and concise as always. Thanks Klaus, already tried your solution and it works great.

I think it would be very useful if you could do something about this in next releases as sometimes in code layers are very nested and it's not easy to follow all that long path for defining values in the pre-parsing stage. I think that some others will arrive at this issue equally.

Best

Luis *thumbup*
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

klaus.krpano

Administrator

Beiträge: 13 499

  • Nachricht senden

4

Freitag, 4. August 2017, 23:04

Yes, I agree, I will try to change that. I was already looking at it in detail and it seems to be possible without too big changes.

But the new 1.19-pr12 version was now released without that change, because I wanted to avoid potentially side-effects for this release ;-).

Best regards,
Klaus

Ähnliche Themen