New Button control, with built in Indicator

[Steve Horn]

I was looking for a way to combine a button control and a separate indicator control. The button would do normal button things (not necessarily multi-state property change) and the indicator would NOT be tied to the button's function but would rather link to a device's property value. What I ended up doing was overlaying the button with an indicator control. It does what its supposed to do. But I can't get the transparency to work. So in my case, the button's unlit image appears black on top of a gray button. I could make the indicator's 'off' image the same color as the button. But that would require changes for each different button color used. Is there away to do this that I've overlooked? Or is an opportunity for a new button control type?

[Richard Naninck]

That's funny, I am exactly doing the same thing. For some buttons I created an off state which is a cut and paste from the exact position of the button where the indicator is placed so the off state doesn't show. This is nice for source buttons from a receiver or something like it. I have 10 source buttons, and all 10 have indicators with three states. State 1 is button background and means that the source is not selected. State 2 is gray meaning the source is selected, but the receiver is off and state 3 is green meaning the source is selected and the receiver is on.

This works because my receiver always replies with a status so the indicator gets refreshed after the button blanks it out. The blanking part is due to the layer control in HB. Dynamic images have layers and don't suffer from this behaviour, but indicators do. This has been discussed a while ago. (Could be in the beta test section).

Other buttons with indicators where a device doesn't give status by itself, a refresh is forced by a script. This forces the indicator to redraw and display correctly without blanking in the button. I created transparant holes in the buttons where the indicators are put, but because of the lack of layer control, indicators won't show even in the transparant part of the button when the button is pressed while the indicator doesn't refresh.

So the only way to work this is to refresh the indicator after a button press. Works very nice. I guess something like this has been feature requested once because this is way more flexible than having multistate buttons in many occasions.

[Richard Naninck]

yesterday a friend of mine came up with another idea to get this done. It is very hard to describe how it is done, but here goes.

Instead of a normal button, use a multistate button. Multistate buttons can have different texts per state, but they can also handle different images per state. For each button a null device property has to be created. Link the button to the property and set the states. Example: State 1 = On and if the button is pressed it should become Off (State 2). If Off is selected and the button is pressed, than On is selected again. Simple toggle between On and Off. Now, both states can have a separate image. That image can be a button image woth a down and an up state. For On you could use a button with a built in indicator showing when the property is On and for Off you can have a different button (up and down state) without the indicator or a different color or whatever. Pressing this button would swap the button images, but changing the null device property from on to off and vise versa would also change the button image. And that is the trick. A script can change the state of the property and the button will follow. So if you want for example to with an X10 light you could do the following: Create a button with an incorporated On indicator (or maybe even an image of an illuminated lamp) and set state 1 to On. State 2 would be the x10 command Off. Pressing the button would switch off the lamp. A script should catch this command and set the property to Off. Now the other button image appears with a not illuminated lamp that has a State 1 set to Off and a state 2 set to the X10 On command. Pressing this button will switch on the light and the script should catch this change and set the On label in the property. If the lamp was switched using the X10 FM Remote, the script would catch the command and set the property and the button will change along with it.

This is hard to describe and maybe even hard to understand, but for those who do get it and like the idea it should open up lots of graphical opportunities. Each button requires its own property and a script handling some stuff should go along with it.

[Steve Horn]

Richard, I'll admit that I've only read your idea once so far...
Will try again later. But it reads like the images presented by the button are tied to the action of the button press. What I was proposing initially, and sort of solved by overlaying a bodged image control on top of a button control - was an image/indicator that acted (and could be controlled) independently of the button press. But I'll read your proposal again...

[Richard Naninck]

I know what you propsed. I have that working here as well, but this new idea can do the same with a little more work, but is in many ways better than the old idea. You cannot press the button where an indicator is overlaying it because you will be pressing the indicator on that position on the screen. With the multistate button, that is not an issue. Multistate buttons can hold more than two states etc. I must admit that I am not going to incorporate this new idea very soon since it requires a lot of work, but for graphical enhancements, this is a nice way to go.

[Steve Horn]

Good point - I had not encountered the 'cannot push the button where the indicator is' problem, since my indicator is so small compared to the size of the button.

[ScottBot]

There's a lot in this thread dealing with how you are using the existing setup, so I'm not following 100%. Are you asking to have the entire button image defined by a completely separate (and configurable) device property? So it would be a dynamic button image in the same way dynamic images work?

[Steve Horn]

Its been awhile since this started. What you're suggesting could work I suppose, provided the image(s) are not tied to the state of the button control (like the existing Multi State button control) but rather to a property on another device, in this case a 'new mail' property on the email NULL device.

[ScottBot]

Would you rather:

1. The image be controlled in very much the same way as the indicator control with the control defining 'states' that will cause predefined images to display/change?
2. Just an association to some arbitrary Device.Property that holds the name of the image, which when changed will update the button image. More like a dynamic image control
3. Or something else

If your vote is for #1, would it be better to have all of the states/images in the same image file (like the indicator control works now), or having separate image files for each state?

[Richard Naninck]

Scott,

I would rather see the indicator option where different states are in stored in the same image. In any case, the button control should be disconnected from the button looks. You can even create a visible flag to a button. Depending on context, some buttons should be visible for one device, but should not be visible for another device which is using the same theme panel through context. For example two different brands TV's where one TV has different options than the other.

[Steve Horn]

(I had this eloquent reply scripted, then couldn't submit it because the HB forum server went South.. ) Anyway, I think option 1 provides the most consistency with the existing image control's operation. Regarding the image file(s) (1 or multiple), either way is acceptable. One file could be made to work in most applications I suspect. Maybe the HB Wizards will see benefits to option 2 or multiple image files; I'm just a HB neophyte.