Item Widget and Focusable Condition?

[jaminben]

Hello,

I have an item widget which is being used as a dummy spacer until a certain user action occurs......it needs to be in place to keep the form of the options panel from moving up and down (just looks odd if I were to disable and enable the option).

Anyway, how can I prevent this item widget from gaining focus? I've tried the "Focusable Condition" thingy but can't seem to make it work.... can I use this to prevent focus or is that meant for something else?

The only other option I have would be to send the focus to its proper place when the dummy item gains focus but that seems a bit long winded for something that should be pretty easy.

Any ideas?

Cheers

Ben

[jaminben]

Gah..... as soon as I posted I realised it was being affected by a theme, I removed it from the theme and now I can use the "Focusable Condition" as it was intended...... oh how I wish I could delete this thread.



Cheers

Ben

[Fuzzy]

Originally Posted by jaminben

Gah..... as soon as I posted I realised it was being affected by a theme, I removed it from the theme and now I can use the "Focusable Condition" as it was intended...... oh how I wish I could delete this thread.



Cheers

Ben

If you were to delete it, how would people lavish you with ridicule?

[Tiki]

Yeah, that's one of my gripes with Studio - the themes are powerful and useful, but it is not immediately obvious when a property that you try to set will be overridden by a theme. It would be nice if there was some visual indicator (perhaps Studio could detect when a theme's properties are going to be used and grey-out the properties unless you have a checkmark in the override theme properties box).

[Opus4]

Originally Posted by Tiki

It would be nice if there was some visual indicator (perhaps Studio could detect when a theme's properties are going to be used and grey-out the properties unless you have a checkmark in the override theme properties box).

Since widgets can be referenced from multiple places & those places could be affected by different themes, it would be next to impossible to say that a specific widget is affected by a theme.

But, you can use the Debug -> UI Components menu item to see the current UI components & that has an option to highlight the theme affecting a widget when you right click on a widget.

You can also tell if the widget whose properties you are editing is affected by a theme by simply dragging the sizing, transparency, or some other property controllers. If the UI element controlled by that widget doesn't change, then it is probably controlled by a theme.

- Andy

[GKusnick]

Actually I've always felt it should be the other way round: themes should "underride" rather than override widget properties, so that any property not explicitly specified by a widget would default to the theme's value, but the widget could still override individual theme properties just by specifying them explictly. Then it would be clear at a glance which properties are theme-controlled, namely, the ones left blank in the widget's own property dialog. (But as Andy notes, this still wouldn't tell you which theme is in control, since that depends on the runtime execution path.)

With that kind of inheritance rule, it would then be possible to create chains of themes in a superclass-subclass type of relationship, with each theme inheriting from a more generic theme above it and overriding the few properties it wants to change.

Unfortunately I don't think either of these features is likely to be implemented, since they would be massively incompatible with existing STV code.

[Fuzzy]

Originally Posted by GKusnick

Actually I've always felt it should be the other way round: themes should "underride" rather than override widget properties, so that any property not explicitly specified by a widget would default to the theme's value, but the widget could still override individual theme properties just by specifying them explictly. Then it would be clear at a glance which properties are theme-controlled, namely, the ones left blank in the widget's own property dialog. (But as Andy notes, this still wouldn't tell you which theme is in control, since that depends on the runtime execution path.)

With that kind of inheritance rule, it would then be possible to create chains of themes in a superclass-subclass type of relationship, with each theme inheriting from a more generic theme above it and overriding the few properties it wants to change.

Unfortunately I don't think either of these features is likely to be implemented, since they would be massively incompatible with existing STV code.

I agree that this is how I would have intuitively thought it would work.

[PLUCKYHD]

Originally Posted by Fuzzy

I agree that this is how I would have intuitively thought it would work.

+2 but also agree it would probably break a heck of allot changing it this far in the game.