Listbox-type behavior on a HUD

Has anyone ever implemented a scrolling listbox of text on a HUD before? I plan to make a HUD that has a long list of names on it. I was planning to use llSetText for the names, and I'd like each name to be selectable by clicking. I will have to implement a scrolling mechanism, since the list is too long to show all at once (especially since llSetText has the 256 character limit).

My plan is to make about 10 names visible at once, and if the user scrolls up or down via some up/down buttons, I will rearrange the llSetText to show the new set of visible names. As for the clickable aspect, I would somehow arrange a set of rectangle prims so that there is a clickable rectangle behind each llSetText name.

Does anyone see a major problem with this approach, or can you make any suggestions for a different method? Thanks!

I've made a number of HUDs which do something like this. Take a look at the EZ Animator Deluxe. Mine displays 10 names at a time, each 20 characters long and uses arrow buttons to page through them. In this case it's either the names of animations or the names of macros that the user sets up.

A UI widget set for SL is something we really need.. but it has the usual permissions problems that items made for creators have.

But I think your idea is right... a series of rectangle prims as the background, then a single prim at the bottom (or several, if you need more than 255 characters) that emits an llSetText covering the rectangles. This then detects clicks via clicks on the background rectangle prims, and do "scrolling" by changing the llSetText.

You can do it with one text emitter per box, but that adds a lot of extra prims (and means you need to set up link messages to update the box)

By "text emitter," you mean something like XyText?

Sorry, I just mean a prim that has an llSetText set on it.

Yep, I've done the same thing on a couple of HUDs I've created. It's a pain with the amount of duplicate scripts you need, all the alignment problems, and all the message passing to control everything, but it's not that hard, just time consuming. My biggest issue with it all is not being able to configure the size or location of the llSetText itself, so your prim sizes are constrained.

From reading posts here and there, I gather there are some problems regarding llSetText and UI size and screen resolution. My forum searches aren't finding anything really useful. Is there a place to read about how SL treats llSetText with respect to the UI size and screen res? Or can someone give me an overview?

Well from my observations, the size of the llSetText is independent of the view, and it's just the inter-line spacing that changes, as that is a function of the relative prim spacing.

However, when you have a HUD attachment, the viewing distance & therefore the interline spacing is fixed at a certain distance above the top of the prim, as well as the text size, as if it's just text in notepad.

Therefore, in your example, you want (eg) 3 lines displayed on your HUD, they will look like this

Line 1

Line 2

Line 3

And you cannot change the size or location of that text, which means your background prims must be sized to accommodate these fixed spacing.

Technically what I've just said is not correct about the spacing, as you can overlap the prims to have smaller spacing, but then the problem is that your touch events are messed up with clicks on multiple prims at once, so to have a nice separate division of backgrounds to match the displayed text, you are required to use the displayed text size and positioning.

Does this make sense? You could actually work around these limitations to a degree with separate touch event prims to your actual background prims, but unless you're really set on certain spacings, I don't think the effort is worth it, but that's up to you to decide. The actual text size itself, I don't believe there's any way to change.

Hope this helps.

That helps a lot - thanks!

Ultralite Soleil