Button Status for Conditionals

BenDerzGreat

Hey Everyone,

Excuse me if this question is very obvious, but I couldn't find any previous info on here about it and was wondering before implementing it in my code. Is it possible to use a button status in a conditional statement for an event to determine what to do, for example if rooms should be combined. Would I use devchan pairs? could i use on/off or do i need a variable to track it?



for example:

if([dvTP,1] = ON)
{
// do something
}
else
{
// do something else
}

[Deleted User]

Button feedback is typically following the status of something else - a variable or data structure element. The better approach, in my opinion, would be to tie your feedback to that source data point and not the panel channel. If your button is a visual representation of a room combine status tracking variable, evaluate the variable and not the button. In a multi-panel scenario, what happens if the one you are evaluating against were to fall offline?

BenDerzGreat

Chris,

I agree that tracking it against a variable would be more effective and less error prone. But how would I update the status of the variable based on the status of the button?

richardherman

You do it the other way around, for instance:

BUTTON_EVENT[dvTP,1]
{ [INDENT]PUSH:
{[/INDENT]
  [INDENT=2]bRoomCombined = !bRoomCombined //toggle the variable
IF (bRoomCombined)
{
// do something
}
else
{
// do something else
}[/INDENT]
  [INDENT]}[/INDENT]
 }

//in your feedback loop:

[dvTP,1] = bRoomCombined

zack.boyd

Meh - I do it all the time - it's super helpful for stacking button events... here's a typical...

BUTTON_EVENT[dvPanels[],1]
BUTTON_EVENT[dvPanels[],2]
BUTTON_EVENT[dvPanels[],3]{
    PUSH:{
        [BUTTON.INPUT] = 1 - [BUTTON.INPUT]
        if([BUTTON.INPUT]){
            //do stuff
         }
    }
}

a_riot42

I use the status of panel buttons for certain things. I'd write it this way:

if([dvTP, 1])  // if channel 1 is on
  // do something
else
  //do something else

HARMAN_icraigie

Hey look - NetLinx has a native boolean data type... who knew

ericmedley

There is no situation where I would use the button state of a UI as essentially the storage place for a status/value. It's really the tail wagging the do - so to speak.

But, as an intellectual exercise:

You could also use a channel event.

channe_event[TP,1]{
on:{
My_Button_State=1;
// do something
}// on
off:{
My_Button_State=0;
// do something else
}// off
}// chennel event

In fact, I've long though AMX broke it's own rule with Faders.

I've always thought there should be Level_Events and Fader_Events. The Fader_Event should be for user interaction only and the Level_Event is for feedback only. (Similar to a Button_Event and a Channel_Event on a UI. Never mind that we still kind of break that rule by using Chanels for both actions and feedback on devices. Oh well...

HARMAN_icraigie

ericmedley wrote: »

There is no situation where I would use the button state of a UI as essentially the storage place for a status/value. It's really the tail wagging the do - so to speak.

But, as an intellectual exercise:

You could also use a channel event.

channe_event[TP,1]{
on:{
My_Button_State=1;
// do something
}// on
off:{
My_Button_State=0;
// do something else
}// off
}// chennel event

In fact, I've long though AMX broke it's own rule with Faders.

I've always thought there should be Level_Events and Fader_Events. The Fader_Event should be for user interaction only and the Level_Event is for feedback only. (Similar to a Button_Event and a Channel_Event on a UI. Never mind that we still kind of break that rule by using Chanels for both actions and feedback on devices. Oh well...

You are only to get that channel event from a touch panel if you first set the feedback in code - speaking of dog wagging tails...

richardherman

icraigie wrote: »

Hey look - NetLinx has a native boolean data type... who knew

Yeah, that's the power of Hungarian notatition... :-) But as long as you use that, there can be an advantage to immediately see that the variabele is meant to only hold two states.

ericmedley

icraigie wrote: »

You are only to get that channel event from a touch panel if you first set the feedback in code - speaking of dog wagging tails...

Exactly. My point exactly.

a_riot42

zack.boyd wrote: »

Meh - I do it all the time - it's super helpful for stacking button events... here's a typical...

BUTTON_EVENT[dvPanels[],1]
BUTTON_EVENT[dvPanels[],2]
BUTTON_EVENT[dvPanels[],3]{
PUSH:{
[BUTTON.INPUT] = 1 - [BUTTON.INPUT]
if([BUTTON.INPUT]){
//do stuff
}
}
}

BUTTON.INPUT is a devchan though isn't it? What does 1 - [BUTTON.INPUT] resolve to? Never seen that notation before.
Paul

HARMAN_icraigie

a_riot42 wrote: »

BUTTON.INPUT is a devchan though isn't it? What does 1 - [BUTTON.INPUT] resolve to? Never seen that notation before.
Paul

Its a devchan, just like you said
In the case shown it will resolve to a toggle - on or off depending on the feedback state (on = 1 and off = 0) of the button.

button_event[dvTP, 0]
{
  push:
  {
    // Most common thing done with button.input
    to[button.input];   // This is how you do momentary button feedback of the button that was pushed


    // Something else you can do with button.input
    [button.input] = ![button.input];  // This is how you toggle the button that was just pushed
    if([button.input])
    {
       // Do this if the button feedback is now on...
    }
  }
}

a_riot42

Makes sense. I never use devchans, so I am not familiar with that style. It seems less clear to me.
Paul

zack.boyd

It really just ends up being an 8-bit value... so it can evaluate out just like anything else. I usually think of it in its decimal value for evaluation. Especially useful for multi-state buttons.

Any time I can use math to my advantage I will - Here's a chunk of code that sends lighting to either full or off depending on what the user is expecting based on button feedback...

BUTTON_EVENT[dvPanelsLighting,11]{    //Gallery Lighting
    PUSH:{
        INTEGER state

        state = 0

        [BUTTON.INPUT] = 1 - [BUTTON.INPUT]
        state = [BUTTON.INPUT]        

        toDev(dvLighting,"'P1L',ITOA(100 * state),'T',ITOA(LX_FADE_TIME)")
        toDev(dvLighting,"'P2L',ITOA(100 * state),'T',ITOA(LX_FADE_TIME)")
        toDev(dvLighting,"'P3L',ITOA(100 * state),'T',ITOA(LX_FADE_TIME)")
    }
    RELEASE:{

    }
}

Here I prefer to just reference the button toggle state, because it makes the lights follow the behavior of the button the user expects. The button is a toggle for zone lighting on and off, but the feedback changes when the lights hit their preset values. If they're ramping from one to another, it doesn't change until it hits its final. So here, the feedback changes locally on button press(other panels in the room do not change until preset value is reached), but if they hit the button by mistake, a second button press will evaluate to turn them back on before the ramp is completed...

HARMAN_icraigie

a_riot42 wrote: »

Makes sense. I never use devchans, so I am not familiar with that style. It seems less clear to me.
Paul

In some respects the devchan datatype can be considered at the native boolean data type in NetLinx (and all the way back to AXcess when I first started using it in that context... setting channels on serial devices to track true false values was always my favorite )

a_riot42

Well maybe one day I will find a use for devchans. Every time I've used one, I always end up taking it out and replacing it with more standard code. I wish instead of, or in addition to, devchans, Netlinx had hashes. That's the data structure this type of programming could really use.
Paul

ericmedley

a_riot42 wrote: »

Well maybe one day I will find a use for devchans. Every time I've used one, I always end up taking it out and replacing it with more standard code. I wish instead of, or in addition to, devchans, Netlinx had hashes. That's the data structure this type of programming could really use.
Paul

I don?t use DevChans either. I use Dev Arrays and integer arrays in my events. On occasion I have been known to use ,0] as well. I know how to use DevChans. I just prefer other methods.