I don't have time to try this, but what if there were double quotes around the single charater string?
case ':A': // no problems
case 'A': // major system error
case "'A'": // syntax error
case cCONSTANT_VAR: // major system error
case "cCONSTANT_VAR": // syntax error
Since cases can't be variables (not even constants), it makes sense that the compiler balks when it sees a ".
Yeah, this probably means that you can't have something like $0D,$0A (CRLF) as a case; but I'm willing to accept this as a limitation of a switch/case.
a stack_var integer array will initialise full of junk.
Thanks for the heads up, this is good to know.
I believe you can amend your find to say that any STACK_VAR array[] will initialize with junk. At least it did when I tested a CHAR array[] and LONG array[]. I assume all intrinsic data types will act the same way.
Apparently, it doesn't matter where the single characters are, they can't be in the same switch/case with multicharacter strings. This code produces the Major System Error:
Why does this work?
else
{
stack_var char cErrorMsg [100] ;
switch (itoa(nFDirReturn))
{
case '-12': {cErrorMsg = 'directory not loaded'} ;
case '-10': {cErrorMsg = 'buffer too small'} ;
case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
case '-5' : {cErrorMsg = 'Disk I/O error'} ;
case '-4' : {cErrorMsg = 'invalid directory path'} ;
case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ;
}
nFnumFilesInDir = 0 ;
sFFList[1].FileFolder = cErrorMsg ;
sFFList[1].FFicon = 'file' ;
fnClearDispFileList('ERROR','FDirError') ;
Originally I had the case with the single char string '0' at the beginning of the Switch which didn't work for the reasons cited in previous posts but after NMarkRoberts informed me of the single char string at the begining of the Switch problem I subsequently placed the case '0' at the end and had no problems.
Have you tried placing the CASE 'A', CASE 'B', CASE 'C' at the end of the Switch?
I'm not sure. One of the differences between your code and mine is that I have a default. I don't have time right now to check it out, but what happens if you add a default case to that code?
else
{
stack_var char cErrorMsg [100] ;
switch (itoa(nFDirReturn))
{
case '-12': {cErrorMsg = 'directory not loaded'} ;
case '-10': {cErrorMsg = 'buffer too small'} ;
case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
case '-5' : {cErrorMsg = 'Disk I/O error'} ;
case '-4' : {cErrorMsg = 'invalid directory path'} ;
case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ;
default: {cErrorMsg = 'no known error number matches'} ;
}
nFnumFilesInDir = 0 ;
sFFList[1].FileFolder = cErrorMsg ;
sFFList[1].FFicon = 'file' ;
This does not. Added case '1': in the middle of the switch. "Major systems error....."
else
{
stack_var char cErrorMsg [100] ;
switch (itoa(nFDirReturn))
{
case '-12': {cErrorMsg = 'directory not loaded'} ;
case '-10': {cErrorMsg = 'buffer too small'} ;
case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ;
case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
case '-5' : {cErrorMsg = 'Disk I/O error'} ;
case '-4' : {cErrorMsg = 'invalid directory path'} ;
case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ;
default: {cErrorMsg = 'no known error number matches'} ;
}
nFnumFilesInDir = 0 ;
sFFList[1].FileFolder = cErrorMsg ;
sFFList[1].FFicon = 'file' ;
Moving the case '1' : to the bottom compiles fine.
else
{
stack_var char cErrorMsg [100] ;
switch (itoa(nFDirReturn))
{
case '-12': {cErrorMsg = 'directory not loaded'} ;
case '-10': {cErrorMsg = 'buffer too small'} ;
case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
case '-5' : {cErrorMsg = 'Disk I/O error'} ;
case '-4' : {cErrorMsg = 'invalid directory path'} ;
case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ;
case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ;
default: {cErrorMsg = 'no known error number matches'} ;
}
nFnumFilesInDir = 0 ;
sFFList[1].FileFolder = cErrorMsg ;
sFFList[1].FFicon = 'file' ;
This also works:
else
{
stack_var char cErrorMsg [100] ;
switch (itoa(nFDirReturn))
{
case '-12': {cErrorMsg = 'directory not loaded'} ;
case '-10': {cErrorMsg = 'buffer too small'} ;
case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ;
case '-5' : {cErrorMsg = 'Disk I/O error'} ;
case '-4' : {cErrorMsg = 'invalid directory path'} ;
case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ;
case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ;
case 'A' : {cErrorMsg = 'TestA'} ;
case 'B' : {cErrorMsg = 'TestB'} ;
default: {cErrorMsg = 'no known error number matches'} ;
}
nFnumFilesInDir = 0 ;
sFFList[1].FileFolder = cErrorMsg ;
It appears single char string CASES can't be placed before multiple char string CASES. I remember the post NMarkRoberts wrote when I had my similar problem and I beleive he said it a single char string CASE couldn't be the first CASE and of course I just went straight to the end. Maybe they just can't be before any multiple string CASES. I can't imagine why other that a compiler bug.
we did accidentally two COMBINE_DEVICES(vdvtp,dvtp1,dvtp2) on two connected controllers. we combined the same devices two times. the result was, that both controllers hung, with their "Input" LED permanently on istead of flashing
I don't follow what you're saying below! What is "(* Has to be there *)"? Are you saying that CASE 'cc': has to be after CASE 'a': for the code to work? I'm not talking compiling!
NMarkRoberts wrote:
[Repeating what I said a week ago:
switch(s)
{
//case 'a': (* Causes major system error *)
case 'cc': (* Has to be there *)
{
}
Are you sure you weren't trying to reference this line?
NMarkRoberts wrote ealier in this thread:
So you just have to put the single character cases at the end of the list, or use something other than switch/case.
If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.
It seems that you may use the device in many other ways, just not a send_string.
If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.
It seems that you may use the device in many other ways, just not a send_string.
No, the problem is you are trying to do arithmetic on a system constant that hasn't been resolved yet. FIRST_LOCAL_PORT has no value at the time of variable declaration (I'm not sure if it's zero or NULL though), and the compiler's problem is with trying to add to a value that doesn't exist. If you didn't have the +1 on there, it would work because you are just declaring the memory space, and it gets filled in later. It would also work if you just declared empty device variables, and then used FIRST_LOCAL_PORT + 1, etc., in DEFINE_START to populate them.
This compiles smoothly but IMHO does not make any sense. I would be pleased if the AMX guys could introduce a truckload of Compiler Warning Messages (that make sense). Other compilers even allow to set the verbosity of the compiler.
Just to quote your message from a few lines up, as I'm too lazy to swap back and forth....
[php]
program_name = 'fred'
define_device
dTelnetServer = 0:first_local_port + 1:0
define_start
send_string dTelnetServer,'fred'
[/php]
If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.
Apart from sending a string to an ip connection you haven't opened /=) (I know I know) It seems to me that this is another time when using firstlocalport has a few caveats attached, such as:
[php]
DEFINE EVENT
//For some reason using the explicate DPS doesn't work....
//Gives you a major system error
DATA_EVENT[dTelnetServer]
{
STRING:
{
// This doesn't work properly
}
}
//But directly referencing the port does.....
DATA_EVENT[dTelnetServer.port]
{
STRING:
{
// This works properly
}
}
[/php]
The first one gives you the same character in a military sitcom as Marks send_string to just dTelnetServer. This only appears to be of note when useing
dTelnetServer = 0:FIRST_LOCAL_PORT+1:0
Any incrementation on your ports causes this, just using FIRST_LOCAL_PORT (which defeats the whole purpose of being able to dynamically allocate ports in this way) works.
So as tested, this will work in the send_string case :
[php]
DEFINE_START
//This works.....
SEND_STRING dTelnetServer.PORT,"'I LIKE BEER!!'"
[/php]
Interesting behaviour, probably along the lines of the affor mentioned undefined constant, but then why does the .PORT work..... oh well, it does.
**EDIT** I use the php formating as I like the colours.... perhaps they can just edit the template so it reads AMX instead ^_^
Comments
Matt:
Interesting that evaluating a literal string containing two more characters does not produce an error.
I don't have time to try this, but what if there were double quotes around the single charater string?
CASE 'on' :
CASE 'off':
but it's been a while since, and maybe I even mixed lower- and uppercase letters
case ':A': // no problems
case 'A': // major system error
case "'A'": // syntax error
case cCONSTANT_VAR: // major system error
case "cCONSTANT_VAR": // syntax error
Since cases can't be variables (not even constants), it makes sense that the compiler balks when it sees a ".
Yeah, this probably means that you can't have something like $0D,$0A (CRLF) as a case; but I'm willing to accept this as a limitation of a switch/case.
I've never had a problem using constants in a Case. This works fine for me:
Char strPowerQueryCmd[] = 'CR0' Switch (strLastCmd) { Case strPowerQueryCmd: {} }--D
You can rely upon a stack_var integer to be initialised with the value zero, but a stack_var integer array will initialise full of junk.
A local_var integer array or define_variable integer array appear to initialise full of zeros.
Thanks for the heads up, this is good to know.
I believe you can amend your find to say that any STACK_VAR array[] will initialize with junk. At least it did when I tested a CHAR array[] and LONG array[]. I assume all intrinsic data types will act the same way.
Why does this work?
else { stack_var char cErrorMsg [100] ; switch (itoa(nFDirReturn)) { case '-12': {cErrorMsg = 'directory not loaded'} ; case '-10': {cErrorMsg = 'buffer too small'} ; case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ; case '-5' : {cErrorMsg = 'Disk I/O error'} ; case '-4' : {cErrorMsg = 'invalid directory path'} ; case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ; } nFnumFilesInDir = 0 ; sFFList[1].FileFolder = cErrorMsg ; sFFList[1].FFicon = 'file' ; fnClearDispFileList('ERROR','FDirError') ;Originally I had the case with the single char string '0' at the beginning of the Switch which didn't work for the reasons cited in previous posts but after NMarkRoberts informed me of the single char string at the begining of the Switch problem I subsequently placed the case '0' at the end and had no problems.
Have you tried placing the CASE 'A', CASE 'B', CASE 'C' at the end of the Switch?
else { stack_var char cErrorMsg [100] ; switch (itoa(nFDirReturn)) { case '-12': {cErrorMsg = 'directory not loaded'} ; case '-10': {cErrorMsg = 'buffer too small'} ; case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ; case '-5' : {cErrorMsg = 'Disk I/O error'} ; case '-4' : {cErrorMsg = 'invalid directory path'} ; case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ; default: {cErrorMsg = 'no known error number matches'} ; } nFnumFilesInDir = 0 ; sFFList[1].FileFolder = cErrorMsg ; sFFList[1].FFicon = 'file' ;This does not. Added case '1': in the middle of the switch. "Major systems error....."
else { stack_var char cErrorMsg [100] ; switch (itoa(nFDirReturn)) { case '-12': {cErrorMsg = 'directory not loaded'} ; case '-10': {cErrorMsg = 'buffer too small'} ; case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ; case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ; case '-5' : {cErrorMsg = 'Disk I/O error'} ; case '-4' : {cErrorMsg = 'invalid directory path'} ; case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ; default: {cErrorMsg = 'no known error number matches'} ; } nFnumFilesInDir = 0 ; sFFList[1].FileFolder = cErrorMsg ; sFFList[1].FFicon = 'file' ;Moving the case '1' : to the bottom compiles fine.
else { stack_var char cErrorMsg [100] ; switch (itoa(nFDirReturn)) { case '-12': {cErrorMsg = 'directory not loaded'} ; case '-10': {cErrorMsg = 'buffer too small'} ; case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ; case '-5' : {cErrorMsg = 'Disk I/O error'} ; case '-4' : {cErrorMsg = 'invalid directory path'} ; case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ; case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ; default: {cErrorMsg = 'no known error number matches'} ; } nFnumFilesInDir = 0 ; sFFList[1].FileFolder = cErrorMsg ; sFFList[1].FFicon = 'file' ;This also works:
else { stack_var char cErrorMsg [100] ; switch (itoa(nFDirReturn)) { case '-12': {cErrorMsg = 'directory not loaded'} ; case '-10': {cErrorMsg = 'buffer too small'} ; case '-6' : {cErrorMsg = 'invalid parameter (i.e. Entry points beyond the end of the directory)'} ; case '-5' : {cErrorMsg = 'Disk I/O error'} ; case '-4' : {cErrorMsg = 'invalid directory path'} ; case '0' : {cErrorMsg = 'directory empty or unkown directory error'} ; case '1' : {cErrorMsg = 'directory empty or unkown directory error'} ; case 'A' : {cErrorMsg = 'TestA'} ; case 'B' : {cErrorMsg = 'TestB'} ; default: {cErrorMsg = 'no known error number matches'} ; } nFnumFilesInDir = 0 ; sFFList[1].FileFolder = cErrorMsg ;It appears single char string CASES can't be placed before multiple char string CASES. I remember the post NMarkRoberts wrote when I had my similar problem and I beleive he said it a single char string CASE couldn't be the first CASE and of course I just went straight to the end. Maybe they just can't be before any multiple string CASES. I can't imagine why other that a compiler bug.
switch(s)
{
//case 'a': (* Causes major system error *)
case 'cc': (* Has to be there *)
{
}
}
we did accidentally two COMBINE_DEVICES(vdvtp,dvtp1,dvtp2) on two connected controllers. we combined the same devices two times. the result was, that both controllers hung, with their "Input" LED permanently on istead of flashing
NMarkRoberts wrote:
Are you sure you weren't trying to reference this line?
NMarkRoberts wrote ealier in this thread:
A single character case causes a major system error, but only if there is a multiple character case after it in the list.
If you place and ampersand in a G4 panels webcontrol name, the webserver in the master with 3.21.343 firmware will fall over.
Tested on NI 3000 running 3.21.343 (previous f/w NOT tested)
MVP 8400 running 2.70.8
There are other characters that cause this problem, but I have not confirmed them all.
I will try to post a more exhaustive list later.
This code illustrates a compiler problem.
If you try to compile it you get a "Major System Error" which goes away either if you remove the send_string or if you declare the device in some other way, that is, without using "first_local_port + 1" in the declaration, eg dTelnetServer = 0:3:0.
It seems that you may use the device in many other ways, just not a send_string.
No, the problem is you are trying to do arithmetic on a system constant that hasn't been resolved yet. FIRST_LOCAL_PORT has no value at the time of variable declaration (I'm not sure if it's zero or NULL though), and the compiler's problem is with trying to add to a value that doesn't exist. If you didn't have the +1 on there, it would work because you are just declaring the memory space, and it gets filled in later. It would also work if you just declared empty device variables, and then used FIRST_LOCAL_PORT + 1, etc., in DEFINE_START to populate them.
The problem is that the compiler doesn't say that, it says "Major System Error".
VOLATILE INTEGER nTest; VOLATILE INTEGER nTest2[20]; IF(nTest==nTest2) { // do nothing }This compiles smoothly but IMHO does not make any sense. I would be pleased if the AMX guys could introduce a truckload of Compiler Warning Messages (that make sense). Other compilers even allow to set the verbosity of the compiler.Apart from sending a string to an ip connection you haven't opened /=) (I know I know) It seems to me that this is another time when using firstlocalport has a few caveats attached, such as:
[php]
DEFINE EVENT
//For some reason using the explicate DPS doesn't work....
//Gives you a major system error
DATA_EVENT[dTelnetServer]
{
STRING:
{
// This doesn't work properly
}
}
//But directly referencing the port does.....
DATA_EVENT[dTelnetServer.port]
{
STRING:
{
// This works properly
}
}
[/php]
The first one gives you the same character in a military sitcom as Marks send_string to just dTelnetServer. This only appears to be of note when useing
dTelnetServer = 0:FIRST_LOCAL_PORT+1:0
Any incrementation on your ports causes this, just using FIRST_LOCAL_PORT (which defeats the whole purpose of being able to dynamically allocate ports in this way) works.
So as tested, this will work in the send_string case :
[php]
DEFINE_START
//This works.....
SEND_STRING dTelnetServer.PORT,"'I LIKE BEER!!'"
[/php]
Interesting behaviour, probably along the lines of the affor mentioned undefined constant, but then why does the .PORT work..... oh well, it does.
**EDIT** I use the php formating as I like the colours.... perhaps they can just edit the template so it reads AMX instead ^_^