• Dear Klaus (and others),

    I did some digging following up my checkbox issue, and found that this event listener which comes from one of krpano's main container div elements (direct child node of the krpanoSWFObject div) is what's blocking the checkbox's functionality on mobile devices. If and when I remove this listener through the developer tools, the checkbox starts working properly.



    Sadly I'm not an expert in JS to a degree that I could understand what's really going on here or hack around it myself, could you please let me know if this is a bug or a necessity and if there is an actual way of fixing this? I think making checkboxes work inside krpano plugins is a valid concern...

    Cheers!

  • the function get(style[hotspotstyle].onover return null as the onout does.

    Hi, Since pr13 style vars are not accessible anymore with calc
    eg : trace(calc(style[mystyle].bgborder));
    was working with pr12 ?


    Hi,

    this was unfortunately an unexpected side effect of this new possibility:

    Quote

    New: In action code called by layer or hotspot events, it's now possible to access also object attributes from them (e.g '<layer ... onclick="trace(item[...].name)" ...' - when item was an array object of the layer itself).


    Because of this change the 'style[name].*' was now referring to the 'style' property of the hotspot or layer instead of to the global style array.

    For the next release (1.19-pr14) I have now added an additional check to improve compatibility - when there is an array access like 'style[...]' then there will be also a check if the property at the caller (the layer or hotspot) itself is also an array when looking for the right access scope.

    With that change the style access will work again like in older versions.
    And as already posted above - as workaround for the moment it would be possible to add 'global.' before the 'style' to make sure that the right object will be addressed.

  • I'm sorry if this is a bit silly question. There is still the "pr" in the current Version number. The "pr" originally meant prerelease. Is this still true? If so krpano has been in prerelease state for more than two years. Is there a stable production version at the horizon?


    The pre-release or 'pr' currently is because the version is still not feature-complete, there are still several features planed and also in work for the 'final' 1.19.

    Beside of this the releases have also their own dynamic - sometimes there a new OS or browser releases that require additional unplanned work (especially iOS releases), or there are unexpected bugs or unexpected needs or there are new ideas or interesting requests and so the originally planned next release becomes a whole different one.

    But even then - each version is considered as stable, otherwise I wouldn't release them. Unfortunately that doesn't mean that there could be no unexpected bugs.

    Finally it could be said the version numbers or names are just numbers and names. The latest released version is typically also the most developed one and I would always recommend using that one.

    For the development history of 1.19 please see here and the there linked forum posts:
    https://krpano.com/news/

    Best regards,
    Klaus

  • I have succeeded in making the checkboxes work by explicitely flipping their "checked" property on a touchstart event. While not elegant at all, at least it works, for now anyway.

    However I just realized that the same div touchend listener attached by krpano I was referring to earlier, is causing another issue: input fields do not behave like they should, there is no caret/cursor indicator inside of them. So it is possible to type inside the input, but only "in append mode", because you can't tap in the middle of the text to edit it properly.

    Klaus, please can you look into this matter? This touchend listener creates a lot of unwanted issues it seems.


    Edit: I tried to check if maybe setting control.usercontrol to off temporarily would solve this, and looks like I found another bug. Doing this doesn't disable touch control of the panorama, not in pr13 or pr10 versions anyway. It disabled the mouse and keyboard control all right, but not the touch control. Can you confirm this?

    Edited 2 times, last by webseta (October 16, 2017 at 2:59 PM).

  • Klaus, please can you look into this matter?

    Of course!

    The reason for all the event problems with custom elements inside layers is a side effect of this fix:

    Quote

    Fix: Avoid a 'screen blinking' on iOS when touching a textfield in some cases.

    When tapping a textfield iOS was unnecessarily highlighting the viewer and I've tried fixing that problem by preventing the default processing of the touch events in this case. And that's the problem here - the default event processing is necessary for browser-controlled elements.

    For the next release I've removed that default event processing and hide the iOS highlighting now via the -webkit-tap-highlight-color style.


    I tried to check if maybe setting control.usercontrol to off temporarily would solve this, and looks like I found another bug. Doing this doesn't disable touch control of the panorama, not in pr13 or pr10 versions anyway. It disabled the mouse and keyboard control all right, but not the touch control. Can you confirm this?

    No, I can't confirm this, due my tests control.usercontrol is working fine - for mouse, keyboard, touch and gestures.

    Best regards,
    Klaus

  • Probably a stupid question.

    I've got this message inspite my browser firefox and chrome seem work correctly:

    "ERROR: HTML5 Browser with WebGL support required!"


    I'm sorry for this banal question

  • Hi,

    it basically means what it means - WebGL support is required to be able to display the pano...

    WebGL is browser API for rendering hardware accelerated graphics.
    It depends on the individual system (graphics hardware and drivers) and the browser itself if the browser will be able to use the graphics hardware.

    Best regards,
    Klaus

  • Thanks a lot Sergey74 , I do not have problem with browsers
    but with the new krpanoTools.exe
    the only situation in which webGl doesen't work. So I can't find a way to fix it

    thanks again

  • Hi,

    Thanks a lot Sergey74 , I do not have problem with browsers
    but with the new krpanoTools.exe the only situation in which webGl doesen't work. So I can't find a way to fix it


    This is unfortunately a problematic case - the current krpano Tools GUI is based on NodeWebkit 0.9.2 (which is based on Chrome 32) and has already all GPU blacklisted disabled - and when that WebGL is not supported there, there is not much that could be done (except of changing the GPU card or maybe trying to update the GPU drivers).

    Just for interest - what GPU do you have?

    Best regards,
    Klaus

  • Hi everybody. I've been an avid KRPano user for many years but this is my first forum entry. I noticed that the VR mode doesn't work on my iPhone anymore (iPhone 6, iOS 11.0.3). It doesn't give a split screen. It works fine on my iPad (iOS 11.0.3) and on the MacBook pro (MacOS Sierra 10.12.6). As I love the VR feature and I've been pushing all of my friends to buy themselves a VR headset, it is essential that it works on the phone.
    Has anyone else noticed this ?

    Instead of entering VR mode it seems to go into gyro mode.

    VR mode worked fine until I installed the new IOS on the phone.

Participate now!

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