Why does TO not work on this code?

vegastech

DEFINE_DEVICE
dvTPMB_TV		= 10001:7:0  //MBed TP Plasma Vol functions
TV_MBED			= 5001:14:0  //Physical IR port for the plasma
BUTTON_EVENT[dvTPMB_TV,0]  //Typically Volume Controls
{
    PUSH:
    {
	TO[TV_MBED,BUTTON.INPUT.CHANNEL]
    }
	
    
}

When this code executes, the IR is pulsed instead of continuously sent while I hold down the button.

If I change the code to a stacked button event:

BUTTON_EVENT[dvTPMB_TV,24]  //vol up
BUTTON_EVENT[dvTPMB_TV,25]  //vol dn
{
    PUSH:
    {
	TO[TV_MBED,BUTTON.INPUT.CHANNEL]
    }
}

It works fine. Is it something to do with the wildcard?

DHawthorne

I would guess it's the wildcard. It must be handled runtime, or else the event tables would be enormous. So, on account of that, BUTTON.INPUT.CHANNEL probably has no meaning in a whildcard context.

vining

DHawthorne wrote: »

I would guess it's the wildcard. It must be handled runtime, or else the event tables would be enormous. So, on account of that, BUTTON.INPUT.CHANNEL probably has no meaning in a whildcard context.

I use BIC w/ the "0" catch all when ever I use the "0" so I can say with certainty that BIC isn't the culprit. There used to be issues with "0" and holds that seems to have been resolved so I'm thinking it must be how the "TO" is handled by the system that makes a difference when using "0".

In TPD4 is the panel button set up as momemtary? If so that could be the problem.

You might just do the "TO" yourself in code by issuing an ON[TP,BIC] in the push and OFF[TP,BIC] in the release. Basically this is all a "TO" is, turning some type of channel on until it's released.

Joe Hebert

Using the 0 wildcard with a TO and BUTTON.INPUT.CHANNEL worked fine for me when I tested it.

vining

Joe Hebert wrote: »

Using the 0 wildcard with a TO and BUTTON.INPUT.CHANNEL worked fine for me when I tested it.

I thought it should work, I just haven't used it with "0" and generally don't use "TO" at all anymore anywhwere. Since it does work I would suspect the button is set to momemtary not channel for feedback. The panel will issue a push on a press & automatically issue a release regardless of the button still being held thereby negating the "TO".

Colzie

I'm in the habit of doing a

push:
{
    if (button.input.channel)
    {
        //  handle the button press
    }
}

when I use the [dv_TP,0] button press. I can't remember exactly why I started doing it, but obviously I must have gotten inadvertent button presses with b.i.c=0.

vining

Colzie wrote: »

I'm in the habit of doing a

push:
{
    if (button.input.channel)
    {
        //  handle the button press
    }
}

when I use the [dv_TP,0] button press. I can't remember exactly why I started doing it, but obviously I must have gotten inadvertent button presses with b.i.c=0.

I know that used to cause the HOLD handler to run constantly cuz it would think button 0 was being held when nothing else was being pushed or held so it stands to reason that it would first issue a push. I don't beleive that's an issue anymore but I still prefer to run a select active or switch case on my BIC just to make sure the channel falls into a particular range.

the8thst

I usually do something like this:

//
	define_constant
	integer nIRchannelLimit	= 170
	integer nIRpresetLimit	= 210
	
	define_function integer isValid (integer startPoint, integer value, integer endPoint)
	{
		if ((value >= startPoint) && (value <= endPoint))
			return 1
		else
			return 0
	}
	
	define_event
	button_event[dvIR_TParray,0]
	{
		push: {
			// TP and source tracking omitted here
			select {
				active (isValid(1,button.input.channel,nIRchannelLimit)): {
					// do source IR commands here
				}
				active (isValid(nIRchannelLimit,button.input.channel,nIRpresetLimit)): {
					// do source Preset commands here
				}
				active (1): {
					fnMainDebug('sourceControl',__line__,"'invalid IR channel: tp[',dpstoa(button.input.device),'] chan[',itoa(button.input.channel),']'")
				}
			}
		}
	}