I can extend the mechanism to text based posts and just insta mute them and have someone review the post in an admin channel at a later time

vbox has no visible field ? In the builder I get an error about that - in my app targetting HL it doesn't worry and it seems to work as expected. Odd .. My hx class does have a visible field but that's just used by the code to hide the entire UI VBox or not. So that would seem to be a visible field on the VBox. Anyhow odd, but not what I was trying to get you - working on the example of the optionbox thing

So this demonstrates the issue. On the Materials tab (? what are the sections of an accordion called) of the accordion there is a 3 optionbox set at the top and a 2 set at the bottom. I have selected one in each in the initial XML. If I do not specify componentGroup for at least one set then only the first ob of the top set shows set. However I have code in the first tab of the accordion which disables the lighting controls if the optionbox id="simple" (the first in the second set) is selected. So it doesn't look selected but other bits of the code do. If you uncomment the bits that have the componentGroups you can see the difference in behaviour

visible is from openfl... hidden is "pure" haxeui

is there anyway you can reduce that down to something a little clearer, its probably because im knackered, but im having trouble following

(side note: im liking the UI 🙂 )

I was hoping it wasn't too confusing. Let me reduce it - I'll be out most of today so it may well not be until tomorrow. (re side note: thanx. The UI has a couple of problems I don't know how I want to fix yet - it's all just a demo OpenGL rig really). I have to say I really like the XML UI model and the @:bind stuff. It makes it really quick to add things and move things about

yeah, writing apps without xml, for me at least, seems so unnecessarily painful. Especially when you come to move parts of it around

Try this the two optionbox sets are separated by a few spacers. The slider at the top should be enabled and disabled by the selection of the Simple Lighting option. You can see initially that it is selected but but so is Use Simple Texture. But only Simple Lighting shows checked. Then if I click one in the top set it enables and the slider becomes disabled. But it really shouldn't be disabled because that should only be controlled by the bottom set of options. Does that make sense ?

OK, but that is because they should be in different groups, right?

i dont think them acting "as one group" is a bug... but you mentioned an error though

i added

group="other"

to the last two optionboxes

Yeah I tried group but thought that would require a callback which i wanted to avoid. I'm guessing now it doesn't

fyi, another thing you can do is:

xml
                <group layoutName="vertical">
                    <optionbox text="Simple lighting" selected="true" />
                    <optionbox text="Phong (3-component) Light" />
                </group>

this will just assign a

group

for you...

its basically there if you want to a) not come up with group names b) have change events on the whole group

(but its a helper essentially)

> The error was about having visible on vbox. That causes an error in the builder but not in my app compilation to HL will check it out - thanks

Is there a way, at runtime, to spit out an XML representation of the current app component tree? Trying to debug some stuff and it's a little tricky to identify "why doesn't X appear"; it'd be nice to just dump something into the web builder and fiddle with the XML until it looked right

If not (it does seem pretty complex unless it was built-in from the ground up) are there any other approaches to debug the current app state and layout?

there is this: https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/util/ComponentUtil.hx, but it not might be what you mean, its also especially useless when things are changing all the time. That said, i have a little tool that i use that pops up a window with a tree that shows an inspector for the current components... its actually really useful and ill defo add it as a debug lib at some point

(although it will only work, currently, for composites)

that class is handy

not exactly what I needed but close enough to help, thanks

yeah, its not ideal, and less and less useful when things get "big"

ill see if i can wrap up my "tree inspector" in the coming weeks, its certainly much more useful... and you can screw with properties... ish...

still miles better than stepping through the locals at a breakpoint

yeah, that can get boring real fast... the "tree inspector" is nice as its, essentially, a poor mans "chrome inspector"

it works, but has some quirks (which ill sort before release)