You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Had a problem which I discovered derived from the ambiguity of variable types in Javascript. I mentioned it in the Scrollable forums and was able to solve it myself. You can find that discussion here:
It related to me using a.attr( "href" ) as the source for the index value in a seekTo call. Even though the value was numeric ( i.e. 5 ), being href, it was cast as String. This caused seekTo() to cast the new index value as a String in the scrollable object, essentially fubarring the function of move(), next(), and prev(). What should have been 5 + 1 = 6, would instead become "5" + 1 = "51".
Admittedly, I should have cast the href as a number BEFORE passing it to seekTo, which was my eventual workaround, but the library should also assume that it might get inappropriately cast variables and make sure the Types of internal properties don't get changed.
Anyway, I hope that was clear. I didn't poke around too much in the code, but I would suggest adding something like
i = Number(i);
at the opening of the seekTo() declaration.
S.
The text was updated successfully, but these errors were encountered:
Had a problem which I discovered derived from the ambiguity of variable types in Javascript. I mentioned it in the Scrollable forums and was able to solve it myself. You can find that discussion here:
http://flowplayer.org/tools/forum/35/46212#post-46316
It related to me using a.attr( "href" ) as the source for the index value in a seekTo call. Even though the value was numeric ( i.e. 5 ), being href, it was cast as String. This caused seekTo() to cast the new index value as a String in the scrollable object, essentially fubarring the function of move(), next(), and prev(). What should have been 5 + 1 = 6, would instead become "5" + 1 = "51".
Admittedly, I should have cast the href as a number BEFORE passing it to seekTo, which was my eventual workaround, but the library should also assume that it might get inappropriately cast variables and make sure the Types of internal properties don't get changed.
Anyway, I hope that was clear. I didn't poke around too much in the code, but I would suggest adding something like
i = Number(i);
at the opening of the seekTo() declaration.
S.
The text was updated successfully, but these errors were encountered: