Button Status for Conditionals

BenDerzGreatBenDerzGreat Junior MemberPosts: 18
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
}

Comments

  • HARMAN_ChrisHARMAN_Chris Harman Professional University Posts: 273
    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?
  • BenDerzGreatBenDerzGreat Junior Member Posts: 18
    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?
  • richardhermanrichardherman not-so-junior member Posts: 163
    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.boydzack.boyd Smacks Keyboard Repeatedly Posts: 92
    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_riot42a_riot42 AMX Wizard Posts: 1,619
    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_icraigieHARMAN_icraigie Technical Trainer II, Harman Professional University Posts: 432
    Hey look - NetLinx has a native boolean data type... who knew :D
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,126
    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_icraigieHARMAN_icraigie Technical Trainer II, Harman Professional University Posts: 432
    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...
  • richardhermanrichardherman not-so-junior member Posts: 163
    icraigie wrote: »
    Hey look - NetLinx has a native boolean data type... who knew :D

    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.
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,126
    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_riot42a_riot42 AMX Wizard Posts: 1,619
    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_icraigieHARMAN_icraigie Technical Trainer II, Harman Professional University Posts: 432
    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_riot42a_riot42 AMX Wizard Posts: 1,619
    Makes sense. I never use devchans, so I am not familiar with that style. It seems less clear to me.
    Paul
  • zack.boydzack.boyd Smacks Keyboard Repeatedly Posts: 92
    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_icraigieHARMAN_icraigie Technical Trainer II, Harman Professional University Posts: 432
    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 :D)
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    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
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,126
    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.
Sign In or Register to comment.