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

    Code
    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...

  • 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/inde…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.

  • 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.

  • 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... *wink*

    Theo

    Edited once, last by lts (August 8, 2010 at 12:31 PM).

  • 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:

    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.

  • 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

    Edited once, last by lts (August 9, 2010 at 2:47 PM).

  • 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.

    Code
    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

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!