Defining arrays in event handlers and functions

PsyenceFact

New AMX programmer with first post here, so I hope I'm not asking about something that's widely known.

I'm trying to define a char array inside a channel event handler that is then used as a parameter in a function call. However, the compiler throws a syntax error at the assignment statement (C10201: Syntax error; Illegal or Invalid syntax in code).

A simplified version of the event handler is:

CHANNEL_EVENT[dvTP, BTN_ALLOFF]
{
    on:
    {
        stack_var char cLabels[2][10];
        cLabels[1] = 'OK';
        cLabels[2] = 'Cancel';
        fnShowDialog(cLabels);
    }
}

If the variable is defined (but not initialised) at the module level in DEFINE_VARIABLE, the assignment in the event handler is fine. The same thing seems to happen inside functions as well.

Can anyone cast any light on this?

Thanks,

Andy

vining

I believe that's just a bug that has bitten me a few times too. Something about multi-dimensional array being intialized first thing after the var is declared.

A work around would be:

          stack_var char cLabels[2][10];

	  if(1)
	       {
	       cLabels[1] = 'OK';
	       cLabels[2] = 'Cancel';
	       fnShowDialog(cLabels);
	       }
or

          STACK_VAR CHAR cSingleDimension[10];
	  stack_var char cLabels[2][10];

	  cSingleDimension = 'Damn Bugs';
	  cLabels[1] = 'OK';
	  cLabels[2] = 'Cancel';
	  fnShowDialog(cLabels);

Basically just do anything first. You can search and find more info about this but basically it's a bug that you just have to deal with.

PsyenceFact

Thanks for the response Vining. It's a relief to know that I'm not alone in this.

However...

I've come back to my code this morning to try your workaround and the compiler error no longer occurs! I've added and deleted a couple of send_strings as I've been trying things out, but I've now reverted to my code exactly as it was before and no error!

At least I'll know it's something to look out for in the future. Thanks again.

Andy

vining

Just had a repeat of this issue myself and I had to look at another section of the code where I basically did the same thing along time ago to find that I did the same type of work around. When I had the compiler error today I didn't even make the connection to the bug I just descibed until I found the old work around and then realized it was the same issue just a different flavor on a different day.

if(sLevel[nLevel].nEditPlylist == 3)
	  {
	  STACK_VAR _sLevel sClearLevel;
	  STACK_VAR _sLevelList sClearLevelList;
	  STACK_VAR INTEGER nAllowCompile;//only purpose is to allow this code to complile, otherwise throws an error
	  
	  nAllowCompile = 1;//only purpose is to allow this code to complile, otherwise throws an error
	  sLevel[nLevel] = sClearLevel;
	  sLevelList[nLevel] = sClearLevelList;
	  sSBS.sBrowseState.nLevel--;
	  }