switch...case problem

yan_benyamin

Hello, again. Look at this code below. With this code, I can do Treble Up, not down. If I put treble down before treble up, it can't do treble up. Any idea why? btw, I get the 'Treble Down' and 'Treble Up' string on telnet.

	if ([activezone,nSetTreble])
	{
	    switch(button.input.channel)
	    {
		case nTrebDn:
		{
		    send_string 0,'Treble Down'
		    if (activetreble > 1 )
		    {
			activetreble = activetreble - 1
		    }
		    else
		    {
			activetreble = 1
		    }
		}
		case nTrebUp:
		{
		    send_string 0,'Treble Up'
		    if (activetreble < 20 )
		    {
			activetreble = activetreble + 1
		    }
		    else
		    {
			activetreble = 20
		    }
		}
	    	send_string dvDAS,"'MSTR',itoa(get_last(ndvkp)),',',itoa(activetreble),10"
		send_level ndvkp[get_last(ndvkp)],1,(activetreble*255)/20
	    }
	}

Colzie

Need to move your "action" out of the switch/case

	if ([activezone,nSetTreble])
	{
	    switch(button.input.channel)
	    {
		case nTrebDn:
		{
		    send_string 0,'Treble Down'
		    if (activetreble > 1 )
		    {
			activetreble = activetreble - 1
		    }
		    else
		    {
			activetreble = 1
		    }
		}
		case nTrebUp:
		{
		    send_string 0,'Treble Up'
		    if (activetreble < 20 )
		    {
			activetreble = activetreble + 1
		    }
		    else
		    {
			activetreble = 20
		    }
		}
	    }

    	    send_string dvDAS,"'MSTR',itoa(get_last(ndvkp)),',',itoa(activetreble),10"
	    send_level ndvkp[get_last(ndvkp)],1,(activetreble*255)/20
	}

jjames

Like Chad pointed out, the "action" is within the Switch..case which shouldn't even allow it to compile.

kbeattyAMX

I'm making the assumption that this section of code is in the hold section of a button_event. Button.input.channel does not provide a value in the HOLD section of a button event. Store the value for Button.input.channel in the PUSH section then use that VAR in the HOLD section and it should work fine.

kbeattyAMX

jjames wrote: »

Like Chad pointed out, the "action" is within the Switch..case which shouldn't even allow it to compile.

I'm not sure what you meant by taking the action out of the Switch_Case. When the order of execution reaches any point in a program you should be able to do any code that you want. The only gotcha is using stack vars in a WAIT that are initialized outside of a WAIT (then expected to retain value inside of a WAIT). I don't see a problem here.

Colzie

yan_benyamin had the equivalent of

switch (i)
{
    case 1:
    {
        //do something
    }

    case 2:
    {
        //do something else
    }

    send_string 0, 'Oops, no statements should be here relative to the curly braces!'
}

jjames

kbeattyAMX wrote: »

I'm not sure what you meant by taking the action out of the Switch_Case. When the order of execution reaches any point in a program you should be able to do any code that you want. The only gotcha is using stack vars in a WAIT that are initialized outside of a WAIT (then expected to retain value inside of a WAIT). I don't see a problem here.

Ken . . . the compiler is looking for another CASE, not a SEND_STRING or SEND_LEVEL. Those two things are in the SWITCH.

ericmedley

Yeah, I was thinking the same thing too. I put 'Actions' in switch cases all the time.


My question on the example code is what is the value of nTrebDn and nTrebUp? are these constants? are they variables being set somewhere? If the values at the time of the execution of the S/C are the same then the one on the top of the heap will execute alwasys and then the S/C terminates.

kbeattyAMX

oops! Didn't see that! I copied the second code block. Didn't realize it was corrected. In any case, I could not get this code to work in the HOLD Section which I assumed where it would be located if ramping was to occur. I guess he just wants to tap the button.

vining

ericmedley wrote:

I put 'Actions' in switch cases all the time.

action in a switch inside a case = ok
action in a switch not in a case = bad

kbeattyAMX

There must be something wrong with the compiler. You don't need braces at all.

if (1)
		{
			switch(curr_button)
			{
				case nTrebUp:
					send_string 0,'Treble Down'
					if (activetreble > 1 ) activetreble = activetreble - 1
					else activetreble = 1
					send_string 0,'see if this works1'
				case nTrebDn:
					send_string 0,'Treble Up'
					if (activetreble < 20 ) activetreble = activetreble + 1
					else activetreble = 20
					send_string 0,'see if this works2'
			}
			//send_string dvDAS,"'MSTR',itoa(get_last(ndvkp)),',',itoa(activetreble),10"
			//send_level ndvkp[get_last(ndvkp)],1,(activetreble*255)/20
		}

This compiles and works! Look mom no braces!

kbeattyAMX

I'm running 2.5.1.10.

vining

I think I remember in code 3 that braces aren't required for cases?

kbeattyAMX

Weird! Pascal/C You are only allowed one statement after a conditional or event. If you need more statements you need to make a compound statement with {Braces}.

yan_benyamin

Thanks for the replies. Yes, this code is in a HOLD section. I used the MET-6's wheel to ramp up volume, bass and treble. Now the code runs, but I don't think my code is good enough. I wonder if using the duet module will make it easier for me to code.

This one is out of the topic. What should I use the MET-6 buttons for, if I'm using it to control Matrix Audio? The 6 buttons I assume are for source selections. What's the center button for? Is it logical to use it for muting?

Joe Hebert

kbeattyAMX wrote:

There must be something wrong with the compiler. You don't need braces at all.

vining wrote:

I think I remember in code 3 that braces aren't required for cases?

Correct, they are only required if you need to declare variables inside the CASE.

Colzie

yan_benyamin wrote: »

What's the center button for? Is it logical to use it for muting?

I use the center button as a mute, turning on the LED when mute is active.

the8thst

Joe Hebert wrote: »

Correct, they are only required if you need to declare variables inside the CASE.

That seems creepy to me. It just looks wrong.

Chip Moody

Ditto. Big time ditto.

the8thst wrote: »

That seems creepy to me. It just looks wrong.