How to show/hide widgets only when certain things are visible in the viewport REGARDLESS of screen resolutions using Window.Scroll

I have a “staticTotal” widget and a “stickyTotal” widget. (I’ve followed the steps for creating a sticky header/footer in the documentation. I didn’t need step 12 because the page is already long enough to scroll.)

My staticTotal is at the bottom of a form where users have to input percentages into many fields and the page is long, so I’ve created stickyTotal to “float” and show the total (stuck to the bottom of the viewport) as the user inputs so they can always see it, not just when they get to the bottom of the form where staticTotal is.

I need stickyTotal to only be displayed after the bottom of the Equities input field (for example) is visible in the viewport (it’s the second input field out of 10 or so that are all stacked vertically down the left side of the screen) and for it to be hidden when the bottom of the staticTotal is visible in the viewport (because staticTotal replaces stickyTotal — again, I’m following the instructions on how to create a sticky header/footer).

The issue is that I can’t use something like:

(text value) [[Window.scrollY]] is greater than or equals (text value) 400
and
(text value) [[Window.scrollY]] is less than or equals (text value) 2001

because when I change the screen resolution and preview it, stickyTotal shows and hides in the wrong place. In other words, I designed it in 1920 x 1200, previewed it, and it looked great. I then changed the resolution to 1440 x 900 and it showed too soon and hid too soon (i.e. too high up the screen in both instances).

I need it to show and hide in the same place regardless of the user’s screen resolution, something that scrollX and scrollY don’t seem to account for. They should be resolution agnostic but aren’t (rather, I want them to be! :wink:).

(Ignore the “at XXXXpx” bit in the Case titles in the image below. They’re irrelevant now.)

Then, following @josephxbrick’s advice in the thread Edit element when it gets scrolled into viewport, I tried to set a local variable LVAR1 = widget “Equity input field” and used the top and bottom of LVAR1 to show and hide like this:

(text value) [[LVAR1.top]] is greater than or equals [[Window.scrollY]]
and
(text value) [[LVAR1.bottom]] is less than or equals [[Window.scrollY + Window.height]]

(Again, ignore the “at XXXXpx” bit in the Case titles in the image below. Still irrelevant.)

but the problem with that is that stickyTotal never hides when you scroll back up (among other things) because it’s looking only at LVAR1.

So now, I’m trying to implement @mbc66’s advice in the same thread:

Yes, you could set up a hotspot (or any widget) as a dynamic panel, pin the panel to the browser window (so it will not get scrolled) and send it to back (don’t pin to front of window!) --and keep the default “Fit to Content” option. Set the hotspot widget (inside that dynamic panel) to size itself to the viewport (e.g., [[Window.height]]) in its Loaded event to make the dynamic panel the same height (and/or width) of your viewport area. Then, in the Window Scrolled event test with conditional case if the area of your widget is over the area of the dynamic panel.

but I’m not sure how this will work because

  1. I’m not entirely sure what “(inside that dynamic panel)” in the sentence “Set the hotspot widget (inside that dynamic panel) to size itself…” refers to and

  2. This sounds like I can’t specify that I want the stickyTotal to hide when the bottom of staticTotal reaches the bottom of the viewport/hotspot so that staticTotal seamlessly replaces stickyTotal and the page can keep scrolling along.

It all needs to be reversed when the page is scrolled back up, of course. I.e., when the bottom of staticTotal reaches the bottom of the viewport, stickyTotal needs to replace it on the journey back up and then stickyTotal needs to hide once the bottom of the Equity input field hits the bottom of the viewport.

Are there any other solutions that are resolution agnostic or can someone explain the best way to go about this, or just explain the above solutions in general?

1 Like

Here is a demo, if I understand your requirements correctly. Everything is calculated with referential pointers, not hard numbers, so it should work for any screen size.

Sticky Panel based on scrolling.rp (52.6 KB)

1 Like

Thanks so much! I’ll give this a try and let you know how it goes.

OMG! I never would’ve figured that out on my own! That makes so much sense now that I can see it. Thank you so much, @mbc66!

One question: I don’t see that the global variables WinScroll and WinHeight are used anywhere but you’ve added them to the cases and have one for Window Resized. They don’t appear to affect anything if removed. Am I missing something?

Right. I forgot to mention those… They are just for demonstration purposes so you can see what the current window height is–if you resize the browser window on the fly–and the current Window.scrollY value. (You can see these dynamically if you open the Console panel when previewing.) Hopefully it helps make the relationship of window height and scrollY more concrete when trying to determine if widget A is in view, at the bottom of window, etc.

1 Like

Ah! I see! Thanks so much, @mbc66! This is very helpful. :slight_smile:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.