Scroll Viewer doesn't show added Control

Hi, the Scroll Viewer doesn’t show a Control when it is added to an area beyond the current visible Scroll Viewer area. In other words, when a Control is added past the bottom window frame of the Scroll Viewer.

In this playground, you may have to tweak the second value so that it is added further down beyond the current visible Scroll Viewer area.

Hi Ian… thx for the report. Also hello to other helpers. :slight_smile:

I just started a little experimenting…

In my opinion, you should not need to set a large (or ANY), so I disabled line 58. In theory, tb2 should automatically y-position at bottom of tb1… using tb2 paddingTop as the vertical spacer.

One interesting thing I found… was in lines 95/96. ScrollViewer’s .children reports 2 items, but ._children reports 1 item. I don’t know if this is pertinent to the issue or not, but I thought I would tell about it. Note: sv._window._children is 2 items, too.

I’m not very experienced in ScrollViewer. Perhaps ScrollViewer is designed for only one child textBlock, and you adjust its .text to add/remove lines.

Hopefully, other weekend helpers will visit the thread and discover more information. Stay tuned for more/better help, Ian.

Ok :slight_smile: so the scrollviewer expects only one child so you can use a stackpanel:

Please note that I added a tiny change for you (line #40)

stackpanel.ignoreLayoutWarnings = true;

Alright! Cool. Thx DK. Ok so, I figged this needed to be told in the ScrollViewer docs, so I started that.

In the middle of writing about how multiple textBlocks could be added to a stackPanel, and then THAT stackpanel could become ScrollViewer’s single allowed child… I got a little brain tumor.

Right away, we notice that this gives us multi-font-styles and text colors/weights/sizes… inside of a single ScrollViewer… which is excellent! But then… I made a BIG mistake. I thought: “I wonder what OTHER controls could be put into that stackpanel, and would work fine.” WHY did I need to think about THAT? Geez, Wingy.

I was SO SO HOPING that ONLY textBlocks would be allowed in a “stack-scroller”. But nooooo… lines 88-93

Images are allowed, too (even though I can’t seem to get any space UNDER the image). Holy crap huh?

So now… my docs mod looks like this…

Live-Updating and Multiple TextBlocks

The ScrollViewer accepts only ONE textblock child. You can modify its .text property, including \n linebreaks, to add/remove text content, using that single textBlock’s font styles.

The ScrollViewer also accepts a single StackPanel for a child, and you may add/remove textBlocks (and possibly OTHER types of controls) to\from that stack panel.

Is that good enough, or should we determine WHICH controls are allowed inside a “stack-scroller” and which aren’t? I just got a tumor from thinking about all the possibilities. Ellipse works, too. Oh gosh.

Should we try to add the entire Grid control used in DK’s monster particle editor? (omg).

Can ANYTHING stop a stack-scroller? I bet a lines/multi-lines will screw it up. I tried the sprite animator thingy… and that landed at screen-bottom, outside the scroller-box. So we know at least ONE thing can baffle it. :slight_smile:

Time for a contest? See who can get the MOST all-different control-types to work fine inside a stacky scrollViewer? YEAH! :smiley:

1 Like

Actually technically the scrollviewer accepts a child. If the child is a container (stackpanel, grid, etc…) then you can have as much children as you want inside that container :slight_smile:


nod-thx. Sprite-man is working, too. I must have installed him wrong, on my earlier attempt.

Man… allowing stackpanel in scrollviewer is really quite powerful.

Any thoughts about adding it automatically? if children > 1, install it? Or maybe install it even if only one textBlock is used? (hidden stackpanel, all the time)

Just thinkin. :slight_smile:

I would rather not do stuff implicitly

Thanks guys for the solution and the documentation. :slightly_smiling_face:

1 Like

Can rectangles be used inside the ‘ScrollStacker’? I’ve noticed that rectangles obey the stacking order but the Textblocks do not stack with the rectangle.

Also, the Scroll Viewer will not scroll to show the complete rectangle.

For the rectangle to stack correctly you must give it a height:


I wonder if the “the the” and the double tb2.resizeToFIt… will live forever… thru new-saved playgrounds and code copy’n’pastes. :slight_smile:

Things like this… are similar to the material named “kosh”… a name which is now used in about 41 million playgrounds. heh. FUN! i think the first material named “kosh” happened just after the playground app was created/released… WAY back. It will live forever. :slight_smile:

I myself…dislike typing standardMaterial lines just to color a mesh. Too much work. Most times, I copied a standardMaterial from another playground and pasted it into the one I was making. Often, that material was named “kosh”, so… I am a power-enabler for this “trending”. :slight_smile:

I think we have a worthless scene.collisionsEnabled = true… in a famous physics playground, too. That puppy caused MANY user-confusions… about the difference between physics engine, and built-in collisions system. I bet 500 physics playgrounds now exist… that have collisionsEnabled.

Funnier still, I think collisions are enabled by default ANYway. :slight_smile:

Pass-along code-warts. Funny stuff (to me, at least).

Yeah I love that. Looks like being an archaeologist deducing the history of a PG:D

1 Like

Thanks Deltakosh, that fixed it :slightly_smiling_face: