Stacking CASES?

vining · July 2007

I saw this style used in a module some where and of course it first confused me. Yeah, I know it's not complicated but it was different and new to me. Once I understood it I began to like the method, the simplicity and have been using it quite alot ever since and I don't believe with any ill affects. But I also never thought putting a HOLD in a buttn_event of a DEV Array was bad either.

Does any one else do this? Is this method of stacking cases so that when there's a match it falls through to the first brace with a statement to execute a good thing or a bad thing. Are there any issues like putting HOLDS in dvArray button_events that may creep up and bite me in the .... that I'm not aware of.

                            CASE 10:	//
			      {
			      fnRefreshTP_Image(cCurUS_Sat_View,US_SAT_LG_VT) ;
			      break ;
			      }
			 CASE 11:	//SAT REQION SELECTIONS 'ABQ',   //1 
			 CASE 12:	//SAT REQION SELECTIONS 'AK',    //2 
			 CASE 13:	//SAT REQION SELECTIONS 'ALB',   //3 
			 CASE 14:	//SAT REQION SELECTIONS 'AUS',   //4 
			 CASE 15:	//SAT REQION SELECTIONS 'BWI',   //5 
			 CASE 16:	//SAT REQION SELECTIONS 'CARIB', //6 
			 CASE 17:	//SAT REQION SELECTIONS 'CLT',   //7
			 CASE 18:	//SAT REQION SELECTIONS 'COD',   //8
			 CASE 19:	//SAT REQION SELECTIONS 'DEN',   //9
			 CASE 20:	//SAT REQION SELECTIONS 'DTW',   //10
			 CASE 21:	//SAT REQION SELECTIONS 'EVV',   //11
			 CASE 22:	//SAT REQION SELECTIONS 'GULF',  //12
			 CASE 23:	//SAT REQION SELECTIONS 'HI',    //13
			 CASE 24:	//SAT REQION SELECTIONS 'ICT',   //14
			 CASE 25:	//SAT REQION SELECTIONS 'LAS',   //15
			 CASE 26:	//SAT REQION SELECTIONS 'LIT',   //16
			 CASE 27:	//SAT REQION SELECTIONS 'LWS',   //17
			 CASE 28:	//SAT REQION SELECTIONS 'MGM',   //18
			 CASE 29:	//SAT REQION SELECTIONS 'MSP',   //19
			 CASE 30:	//SAT REQION SELECTIONS 'PIR',   //20
			 CASE 31:	//SAT REQION SELECTIONS 'TPA',   //21
			 CASE 32:	//SAT REQION SELECTIONS 'WMC'    //22
			      {
			      cGetRegion = Sat_RegionArry[nBTN - 10] ;
			      break ;
			      }
			 CASE 33:	//SAT IMAGE TYPE 'vis',   //1
			 CASE 34:	//SAT IMAGE TYPE 'ir',    //2
			 CASE 35:	//SAT IMAGE TYPE 'wv',    //3
			      {
			      cGetImageType = Sat_ViewArry[nBTN - 32] ;
			      break ;
			      }
			 CASE 36:       //SAT IMAGE TYPE 'vis',   //US_Sat_VLarge
			 CASE 37:	//SAT IMAGE TYPE 'ir',    //US_Sat_VLarge_IR
			 CASE 38:	//SAT IMAGE TYPE 'wv',    //US_Sat_VLarge_WV
			      {
			      stack_var char cTempResource[16] ;
			      
			      SWITCH(nBTN)
				   {
				   CASE 36:{cCurUS_Sat_View = 'US_Sat_VLarge' ;}
				   CASE 37:{cCurUS_Sat_View = 'US_Sat_VLarge_IR' ;}
				   CASE 38:{cCurUS_Sat_View = 'US_Sat_VLarge_WV' ;}
				   }
			      cTempResource = cCurUS_Sat_View ;  //put in temp buffer cuz function deletes/removes the value
			      fnRefreshTP_Image(cTempResource,US_SAT_LG_VT) ;
			      break ;
			      }
			 }
		    }
	       ACTIVE (nBTN > 49 && nBTN < 86):
		    {

ericmedley · July 2007

This from the help file

"BREAK also jumps to the end of a SWITCH statement."

I've never done this myself. I always felt like a case is going to fall through anyway. I don't hang around in them long enough for the variable to change mid-stream.

If you're referring to the stacked Cases with nothing in them, I suppose they complile the same as.

Case 11:
{
cGetRegion = Sat_RegionArry[nBTN - 10] ;
break ;
}
Case 12:
{
cGetRegion = Sat_RegionArry[nBTN - 10] ;
break ;
}
Case 13:
{
cGetRegion = Sat_RegionArry[nBTN - 10] ;
break ;
}

etc...

interesting...

I would wonder why they wouldn't have chosen to use a select<>Active or even a simple If(bla bla bal) It'd be less typing. Perhaps it's just leftover warm-fuzzies from programming in BASIC back in da day but I still use IF() statements a lot. Switch/Case also. Select/Active not so much...

vining · July 2007

In the code example below any case from case 11: to case 32: w/o braces will execute the statement under case 32:. So if button 12 is pushed (CASE 12) it will fall through to the statement under case 32 where you can put a single line of code that handles all the cases above it. Basically you can group button_event buttons sort of like a select active when it makes sense to minimize code but with in a switch case.

adys · July 2007

I do it all the time.
I even didn't stop to think, I use to do that for year in C++.

Am I wrong or in netlinx you don't need break command for switchs?

And what is the HOLD issue?

vining · July 2007

Adys wrote:

Am I wrong or in netlinx you don't need break command for switchs?

Nope! I'm anal w/ OCD!

The HOLD!
http://www.amxforums.com/showthread.php?t=2590

NMarkRoberts · July 2007

The breaks do not appear to be required.

I would be inclined to code this:

CASE 36:       //SAT IMAGE TYPE 'vis',   //US_Sat_VLarge
CASE 37:	//SAT IMAGE TYPE 'ir',    //US_Sat_VLarge_IR
CASE 38:	//SAT IMAGE TYPE 'wv',    //US_Sat_VLarge_WV
     {
     stack_var char cTempResource[16] ;
     
     SWITCH(nBTN)
   {
   CASE 36:{cCurUS_Sat_View = 'US_Sat_VLarge' ;}
   CASE 37:{cCurUS_Sat_View = 'US_Sat_VLarge_IR' ;}
   CASE 38:{cCurUS_Sat_View = 'US_Sat_VLarge_WV' ;}
   }
     cTempResource = cCurUS_Sat_View ;  //put in temp buffer cuz function 
     fnRefreshTP_Image(cTempResource,US_SAT_LG_VT) ;
     break ;
     }

like this:

case 36:
  {
  NewFunctionCall('US_Sat_VLarge')
  }

case 37:
  {
  NewFunctionCall('US_Sat_VLarge_IR')
  }

case 38:
  {
  NewFunctionCall('US_Sat_VLarge_WV')
  }

define_function NewFunctionCall(
  char sArgSomething[])
{
stack_var char cTempResource[100]
     
cTempResource = sArgSomething  (* put in temp buffer cuz etc *)
fnRefreshTP_Image(cTempResource,US_SAT_LG_VT)
}

I would also change fnRefreshTP_Image because mangling the arguments sent to you is very bad practice. This would make NewFunctionCall redundant.

Stacking CASES?

Comments