You are not logged in.

Dear visitor, welcome to krpano.com 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.

1

Thursday, April 30th 2009, 11:31pm

prop limitation (bug?)

Hi Klaus,
just ran into an issue with th "prop"-attribute:
I used this feature in having a "over"-triggered preview. Have small scene-preview pictures and - moving the mouse over - a corresponding bigger (half stage width) preview appears.
This is a "no problem" - the bigger preview width and height are ...

Source code

1
2
mul(plugin[bigPrev].width, stagewidth, 0.5)
set(plugin[bigPrev].height, prop)

For further use in my layout now i have to place a frame according to the dimensons of this previewpicture.
But copying the big previews height into the height of my frame carries NOT the image pixelheight BUT "prop" into the frames height.

I think in most cases you wont have this property but the real numeric value read out...
best regards from www.PanAustria.com

Graydon

Professional

Posts: 614

Location: Texas

Occupation: Industrial gas turbine services.

  • Send private message

2

Friday, May 1st 2009, 4:02am

NOTE: the following is all theory and is a big MAYBE on getting it to work... since I've never tried it... but that's never stopped me before *g*

This may be a good case of using the parent / child function (ref: http://www.krpano.com/forum/wbb/index.ph…ad&threadID=514)...

Where the "parent" is the preview plugin... and the child is the frame.

--------

as far as the use of "prop" in your case... I'm guessing that "prop" is one of those special "variables" that is only recognized in the context of the width / height parameters... and is treated as a regular variable in all other cases.

3

Friday, May 1st 2009, 10:10am

OK, i did try this before, but it doesent work: the parent is a hotspot with picture driven prportions - depending on the picturepath the url points to. The child would be a rect frame, once prepared with special dimensions/proportions and - where needes - manually set to the required width and height (scale9grid used). Now in this case the parent/child model does not automatically resize the frame correctly around the picture, it only applies the same scaling of the parent (picture) to the frame - using its frames proportions.

My work around for the moment was to generate a frame with same proportions of my pic in this tour, but that´s not as flexible as i wanted it to be for futur use because the proportions will differ in other futur tours.

But: - hoping for it - may be in the final 1.0.8. it will be possible to assign a border to picture-plugins too (i was used to by fpp in the past);
nevertheless: Transferring the "height" from one plugin to an other SHOULD transfer the real actual pixelvalue AND NOT the method "prop" used to set for the source plugin! This only doesent work with "prop". If you e.g. have set the source width to "mul(dest.width,stagewidth,0.5)" it correctly does transfer the pixel value and not the method itself.
best regards from www.PanAustria.com

4

Sunday, August 8th 2010, 12:16pm

But: - hoping for it - may be in the final 1.0.8. it will be possible to assign a border to picture-plugins too (i was used to by fpp in the past);
nevertheless: Transferring the "height" from one plugin to an other SHOULD transfer the real actual pixelvalue AND NOT the method "prop" used to set for the source plugin! This only doesent work with "prop". If you e.g. have set the source width to "mul(dest.width,stagewidth,0.5)" it correctly does transfer the pixel value and not the method itself.


Hi,
perfect description.
It seems that the problem still exist (15 months later)??

I would like to read out the actual pixel values of height="prop" too, but there seems to be no chance at all...?

btw: same problem with (example) height="40%". it's not possible too to read out the actual pixel value...

...but i hope, i'm wrong... ;-)

Theo

This post has been edited 1 times, last edit by "lts" (Aug 8th 2010, 12:31pm)


michel

Professional

Posts: 1,153

Location: ANDORRA

Occupation: TV

  • Send private message

5

Sunday, August 8th 2010, 9:50pm

Hi,

I think there is no Bug because PROP or 40% values are features that allows the respective functions, they are not of pixels values...
So, how to retrieve the corresponding value in pixels?

Perhaps KLAUS could add new variables as plugin[..].pixelwidth and plugin[..].pixelheight... *love*

In the wait of those new variables, a possible way to convert the "height = PROP" to pixels should be using a custom action like this:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<!-- custom action to convert "plugin[name].height = PROP" to pixels....
---- usage: height_PROP_to_pixels(name);
---- the name of the plugin must be passed as argument.
---- the resulting value in pixels is set inside a custom variable:
---- plugin[name].pixelheight -->

	<action name="height_PROP_to_pixels">
		addplugin(temp);
		set(plugin[temp].visible,false);
		set(plugin[temp].url,get(plugin[%1].url));
		wait(0);
		div(divisor,plugin[temp].width,plugin[%1].width);
		div(plugin[%1].pixelheight,plugin[temp].height,divisor);
		showlog();
		trace('The current value for plugin[%1].height is = ',plugin[%1].height);
		trace('The value in pixel for plugin[%1].height is = ',plugin[%1].pixelheight);
		removeplugin(temp);
	</action>


About the "height = 40%" , it is more difficult because 40% is not a good value, as is, to make some maths.

Hope this can help...

SAlut.

6

Monday, August 9th 2010, 2:26pm

Hi Michel,
thank you very very much!

Just a hint: if one want to call the action via "onover" one has to use "delayedcall" instead of "wait". I don't know if it's a bug in krpano or in the flashplayer itself, but by using "wait" the "onovered" plugin is flickering like crazy and the action is called in an endless loop.

It took me some time to figure this out... *cursing*

Again: thank you!

Theo

This post has been edited 1 times, last edit by "lts" (Aug 9th 2010, 2:47pm)


7

Tuesday, August 10th 2010, 10:48am

Hi,

the real pixelsize will not be calculated intermediately,
first all code will be executed and if some size/position parameter has changed then a flag for recalculation/redrawing was set,
and then with the next screen update/refresh the real size was calculated,

the original width/height variables will not be changed of course,
because if they would change the % will not work with the next resize of change,

and calculating the size intermediately would be bad from the performance perspective,
the size and position calculation is bigger part and respects many settings (e.g. when there is parent also the scaling from that one),

so I could provide the calculated pixel sizes, but only after the next screen refresh, which make it not very good usable in dynamic code...

btw - it it helps - providing the original pixelsize of the image as separate variables would be possible,
at the moment they could be get by calling "plugin[name].resetsize();",
e.g.

Source code

1
2
3
4
5
6
7
push(plugin[name].width);
push(plugin[name].height);
plugin[name].resetsize();
copy(plugin[name].originalwidth, plugin[name].width);
copy(plugin[name].originalheight, plugin[name].height);
pop(plugin[name].height);
pop(plugin[name].width);


best regards,
Klaus

Similar threads