Dragging the mousse left/right does not help to scroll horizontally my repeated cards within the scroll view component (horizontal scroll enabled!).
Looks like there used to be a thumbnail carousel component but itâs gone.
Any tip appreciated!
Anyone with a clue or is there really no hope?
(Tested in desktop web preview)
I guess they left the carousel in for those like me with it already installed for legacy reasons. The component plug for looking it up in the marketplace is custom-409e7bd8-4c2f-4ca2-a6e9-9eb696970215. However, it showed no results for me either, so it mustâve been formally removed.
As for horizontally-scrolling scroll views, I just tested it as part of my community contribution for the year and it still works, just buggy. I had to set all three top fields to true, including Show Vertical Scroll Indicator. However, by setting a firm height of 100px and width of 100% (works fine with pixel widths too) it displays fine without the vertical scrollbar. Of course, set the Layout to Horizontal, but you folks knew that. 
It does NOT work with Show Vertical Scroll Indicator set to false.
1 Like
Thanks for this!
Indeed I do have a scroll bar now, but itâs not pretty and the left/right dragging for scrolling with the mousse is not enabled.
I guess I have to forget about the scroll view component.
Iâm not sure drag (presumably referring to clicking in the body of the scroll view and pulling either left or right) or rolling the mouse wheel has ever worked for manipulating the horizontal scroll view (HSV). If it did, I would suggest experimenting with removing the horizontal scroll bar to make it more visually appealing. But I believe thatâll just just break it again.
Ironically, clicking with the mouse wheel in the scroll view to activate the automatic scroll function does work. Iâll bet drag would work on mobile too, so not entirely useless for everyoneâŚ
To be fair, HSVs have been broken like that since 2021. 
Thanks for the tip! Although still not optimal user UX when using the pad on a laptop.
So Iâve resorted to the conditional renderer, which I see youâve used before. I guess the advantage of it over a simple conditional display is that the renderer will only load the elements (containers) that meet the condition.
However, the wrap overflowing elements option does not work inside this renderer.
The overflowing components go through the left and right margins, hiding the first few and last few components. Maybe you know of a trick, much like the one for horizontal scroll view?
1 Like
No problem, but Iâm not 100% sure what youâre trying to do. It sounds like a slideshow viewer (for a product page, for example), in which case, conditional renderers will generally work fine. Perhaps, a square image in a CR with two buttons centered on either side (absolute). You could then bind the buttons to logic to show the next image in the CR, etc. Would work fine, Iâd imagine.
If youâre feeling ambitious, you could even try experimenting with the âAnimate Componentâ logic node from the Marketplace to add slide-in/out or fade-in/out-type effects when transitioning to the next image.
You could also try⌠sliders maybe? Never tried it myself directly, but perhaps a slider as a visual aid bound to logic connected to your CR. Still canât be scrolled, but is another option.
As usual, results may vary.
As for the the CRâs overflowing issue, I donât believe Composer allows for any kind of styling (including clipping overflow), which means Iâm not sure of a direct solution. Perhaps, you could nest the CR into a container with firm dimensions set (i.e. 512px W x 512px H), and then make sure your images inside the CR match the holding containerâs dimensions as well to force the CR to the correct size.
You would then set the holding container to clip overflowing components.
No idea if it would work, but thatâs what I would try if I understand you.
I didnât understand anything of your first reply LOL
But I realize the scroll view within the conditional renderer does work well (native condition).
If this complexe âformattingâ works within the CR, so should a basic wrap overflowing option.
I think I am messing up the web condition setup in the CR. What to do next from here?
Already nested inside a container, which is its self inside a simple âcardâ container.
Just not sure how to setup the second render ID. Unbelievable, always stuck on the simplest things.
I didnât think you were still doing scroll views there.
To avoid any confusion, a conditional renderer only supports direct visibility of different âsetsâ of visual data. An example would be the GIF below where we use a CR to control which UI is visible (Security settings vs a userâs Bio) with a click or tap.
Pardon the crappy state of the UI. Iâve been working on bringing it into alignment with the new platform theme!
In a sense, itâs almost identical to the logic behind soft tabs described here, but simpler: Soft Tabs - View components The idea is that, if youâre trying to do some kind of product display carousel, it can be used in a similar manner to fake a slideshow of sorts.
-
Youâll need a page variable of type âtextâ. I named mine âcv_moduleTypeâ.
-
Drop your images individually into a CR in the editor. In this case, I dropped in each UI module, such as âmod_bioâ in the Tree:
-
As seen in the image above, bind the CRâs âActive Render IDâ to your variable. The Render IDs are values that are set in your aforementioned variable. So I have a button in my tab setup in the GIF that sets the variable to âbioâ, and the User Bio UI will show. Likewise with âsecurityâ and âaccountâ.
You can swap between the images/modules in-editor or rename the IDs by clicking or double-clicking the list of IDs, respectively. Whatever the default value of your page variable is (i.e. âimage1â or âbioâ for me), is the image/UI module that will appear to the user upon page load.
Just not sure how to setup the second render ID.
Just drag another component (image or whatever it is) in the CR and double-click the resulting Render ID to change its name to something you want to refer to with the page var.
So that said, Iâm not entirely sure how you were planning on using a horizontal SV with your CR. I canât really imagine a way that would work.
NOTE: Never use more than one CR on a single page. You will almost certainly trigger infinite loading loops and crashes in the desktop preview, and possibly (not verified), in your final build.
Source: Experience.
Nope, sorry I canât get this CR to work on both conditions (native with scroll / web with wrap overflow).
Works well with native view (render condition #1), where the horizontal scroll does its job.
Web view : wrap overflowing component fails : missing the few first and last images in the repeat list.
Setup seems fine:
Ah, now I think I see what youâre trying to do: Controlling the visibility of one container vs the other depending on mobile phone view vs desktop view?
So if itâs on desktop where youâre having issues, we did get the horizontal scroll working. If youâre NOT using a horizontal SV but trying simply with a container with horizontal layout and wrapping overflowing components, my gut says you might need to give the holding container a firm width and no height (i.e. 400px max width, min width / blank height setting).
Try that because, for the most part, it seems almost identical to our âuser background selection boxâ in which there are a number of theme boxes (containers; âClassicâ, âNatureâ, etc) each with a number of preview image buttons which do respect wrapping the components with a horizontal layout, as imaged below. In our case, the scroll view is irrelevant â just a means to pack more content in limited space.
Do you mean to have your âbudgetâ buttons stack vertically with five per row?
If not, could you clarify in greater detail what the overall goal is for that desktop view container. Does it need to slide left and right like on mobile or stack in eventual vertical rows like in the image above?
TL;DR With a third reading of your last answer, indeed, your container having a firm width and no firm height should actually allow wrapping just fine. 
-
Also, could you screenshot your formula logic which youâve implemented to control the visibility of each respective holding container (native vs desktop)?
-
Is that logic bound to the visibility field of each container in the renderer?
I would assume so, but just double-checking.
Bravo Sir! Youâre the expert in handling these types of components. Somehow, I canât use any of them, I just donât like how they are setup and I can never wrap my head around these things.
For our readers trying to figure out this component, Iâll answer your other important question:
The dynamic binding for the active render ID is the value of this appVar, which is defined on app launch in the global canvas.
But somehow I feel this is unnecessarily complicated. I could simply bind the active render ID to systemVar.runtime
1 Like
Well done. Glad that worked out. Honestly, itâs just a gut instinct you pick up for some of the⌠ânuancesâ of building UIs in Appgyver.
Since I only build web apps for use with desktop and mobile browsers, didnât know there was a âDetect native or webâ. Itâs been a while but we used to have separate UIs for desktop vs mobile on the same page â one scroll view for each view. We would control the visibility of either UI view by screen width. I believe it was the systemVars.dimensions.screen.width formula.
While I donât have the time to run a test at the moment, were I working on something like you, I wouldâve tried binding the visibility field of each container in your renderer to something like the following examples.
Used to show the native version when the screen width is less than 500px:
systemVars.dimensions.screen.width <=500
Used to show the desktop version when the screen width is greater than 500px:
systemVars.dimensions.screen.width >=500
If you feel like it, you could test adapting that formula code for âruntimeâ and plug it in. Could just break it too. lol
1 Like
The issue I see with that solution is you overload stuff, since all elements for both UI (desktop and mobile) are loaded, whereas the conditional renderer only loads the elements that match the condition.
Donât misunderstand, we would use CRs today for that too. At that time, there were no CRs yet.
It was more a matter of Mevi pointing out that hidden objects werenât loaded in memory at that point in time. Iâm not really sure on that because it goes against the common logic of both components being loaded in memory to allow swapping on the fly.
Either way, definitely stick with CRs with that kind of fun, folks. The same logic implemented into the vis fields should still work.
@Fred_Kuzyk
Ah, now I remember why we didnât use CRs to control the visibility of whole page-width/height elements, and thatâs because it requires firm set dimensions of internal components to control its own width. In other words, you canât simply set the conditional renderer to 100% W/H, respectively.
Something that might work is creating a 100% W/H page container, nesting the CR inside, and then nesting whole page UIs inside that. Something to test for, but no guarantees.
Iâm just curious if Appgyver actually truly hides hidden components to the degree that they wouldnât be accessible to frontend hackers. An example would be one UI (whole-page container) showing the normal profile page of a user alongside another UI showing a âProfile is Privateâ-type interface.
For an MVP, a simple Bool relation in the backend database of âisSubscribed?â is enough to control whether a second user can see the first userâs full profile. But if its possible to expose the full profile container in something like Chromeâs Inspect interface when it should be hidden, then thatâs clearly not nearly secure enough.
Kind of would like confirmation from an AG team member, which really only leaves @Mevi. 
But if anyone knows betterâŚ