I’m trying to figure out how to disable the scrolling reset that happens when clicking on a link to a scene from within a scrollable div. For clarity, here’s my setup (see corresponding image below):
I have a vertical navigation area set up as a persistent symbol (A).
(A) is not an HTML widget, just a stack of linked text links that’s considerably taller than the screen height. Because of this, it’s set to scroll.
Each link is a rectangle that’s linked to a scene. Clicking on one transitions to the desired scene, with different content visible in the main area (B).
Everything works just fine, except for one thing: clicking on any of the links resets the scrolling nav panel to the top.
This isn’t a problem for any of them that are visible normally, but clicking on any that require scrolling down to reach makes them disappear when the scrolling is reset. I’m highlighting the currently selected item in the nav, which makes this pretty problematic.
I realize this is how anchored links always work, but can’t figure out how to override Hype’s built-in behavior.
I’ve looked into using event.preventDefault() on the links, and tried some jQuery trickery, but nothing I’ve tried thus far has worked. I’m not exactly a seasoned expert with this stuff, so it’s likely I’m just doing something wrong. I’m pretty sure this would be relatively easy to resolve in a simpler non-Hype setup, but I’m at a loss here. Any help would be greatly appreciated!
Very nice description and accompanying graphic - but an example project is always valuable. For one, the (potential) responder does not have to spend time recreating the environment; and secondly - there can be other elements in your set-up that may be overlooked by You (and not knowable to us on the Forum); which may interfere with any proffered ideas to solve the issue.
When the viewer transfers from one scene to another there are “On Scene Load” & “On Scene Unload” handlers. These routines, using the relevant JavaScript, will gather the scroll positions upon the Opening & Closing of scenes. In my attached Hype project example above I have given the “Menu” persistent symbol an ID of “Menu” & will be referenced as such in the code below. “scrollTop” registers the scrolling that has occurred from the top of the element, expressed in pixels.
The following script gets the scroll position of the menu when a Scene unloads:
function sceneUnloadMenuScrollTop(hypeDocument, element, event) {
menuScroll = hypeDocument.getElementById('Menu').scrollTop; // menuScroll is a global variable
}
So when we jump to the another scene - the "On Scene Load" handler fires - and we use the "scrollTop" info contained in the global variable _menuScroll_ to set the scroll for the "Menu" persistent symbol.
function sceneLoadMenuScroll(hypeDocument, element, event) {
hypeDocument.getElementById('Menu').scrollTop = menuScroll; // menuScroll is a global variable
}
If we want to get fancy one could figure out what the "clean" scroll should be ("On Scene Load") - i.e. no text showing in the menu from a partially visible line. Just a thought.
@JimScott, hi!
i think, he means linking from inside the symbol to a specific scene.
i get the same problem, when i click on the button to the “ende-scene” or back,
the symbol scrolls automatically to top.
i used your example and changed it. here´s the result. linking from inside a symbol to a spedific scene
let the nav scroll to top, instead staying for the last click.
@JimScott, apologies for failing to include an example (this is my first time here). I’ve attached my latest, and I’m happy to say that your method for getting and setting the scroll value has almost totally solved my problem.
I say ‘almost’ because, as shown in my example, I’m using a crossfade transition between scenes – and there’s still a jump between when the initial click happens and the stored scroll value is applied. It looks like “On Scene Load” functions are applied after the new scene has completed fading in. That makes sense, but in this case it’s a problem.
Removing the crossfade and making the scene switch instantly works perfectly, but unfortunately I do need to use transitions for this project. Any ideas?
Welcome to the Forum! No problem re: posting a demo project (the key thing is that You see that it is valuable to do so). I’m almost done with another demo using @strmiska’s work as an example. Same principle just a different set of triggers - apparently You have figured the variances out for your needs - great! I will still post my new demo here for comparison… in a short bit. I will look at your project tomorrow - thanks for sending.
scrollControl_EX1_JHSv3.hype.zip (52.5 KB)
There are (3) scenes, the menu has a few “dummy” selections that do nothing except allow for a longer list. The working scenes are basically the First, Middle & Last selections (Scenes Blue, Green, Red).
The main issue with @strmiska’s version posted above was the persistent “Menu” symbol did not have an ID.
So looking at things re: the cross-fade problem. I think the best~easiest thing to do is cheat. There are at least two options in this regard; plus a “legitimate” one - which I’ve never tried - but have always been intrigued by… You open the next scene and immediately come back to the “previous” scene, the back~forth transition apparently is so quick it is not noticeable. By doing so You gain access to, and set the properties of, the next scene (that’s the theory anyway) and then make the transition to the next scene again (but with the properties of the next scene already updated). I will search for this approach this tomorrow (I will believe it when I see it , sounds too good to be true!) - or maybe someone can offer an insight in this regard sooner. It’s 2am my time… outta gas.
Sorry @JimScott didn’t get around to your document. Not sure what’s different. Of course you can apply the same to it.
Basically, to get the “nav” to stay in the same position. You need to add the “getScrollPos” function (or whatever you called it) to the “On Scene Unload”
scrollPos = hypeDocument.getElementById('scrollable-element').scrollTop; // same principal as @JimScott just different names
This gets your position after you’ve scrolled and changed scenes.
Now, same as before you have the function “on scene load” that sets the scrollTop position based on the saved scrollPos variable but and this is important you add the same function to the element that is clicked within the symbol. So effectively you use the same function twice. Once on scene load and once on mouse click of the element in the symbol.
This is the function. I’ve added a little condition to stop errors on first load of the document. (scrollPos won’t be set)
if (unloaded) {
hypeDocument.getElementById('leftNav').scrollTop = scrollPos;
} else {
}
Now, in order to check against this condition you need to do 2 things!. Add <script>unloaded = false;</script> to your head HTML and add unloaded = true; to your “On Scene Unload” function.
####The document will make this clear.
Wow. Thanks to the combined input of all three of you, my problem is now completely solved! @DBear’s solution of adding the ‘get’ function to the click event nailed it, and everything’s now working exactly as I want it to.
One thing I should mention is that it’s important to ensure that things are firing in the right order. I noticed that most of my links were acting correctly, but that some were still causing the jump even after the new JS was added. It turns out that the misbehaving ones had the “Run JavaScript” action before the “Jump to Scene” one, because I’d applied them inconsistently. Once I fixed them to all have the JS after the jump, everything was cool.
Thanks so much to all of you; I really appreciate the help on this.
I’ll be back the next time I have a perplexing problem.
Everyone was close!