gotta be a typo somewhere...

vegastech · February 2010

I am using variables to change the state of my shades, proj lift, and screen buttons. Unfortunately, however, the state is not changing when the variable changes. I have another button, call it status, that does change states:
code]
DEFINE_PROGRAM
[dvCV7Tp,100] = (nShadeOpen == 1)
[dvCV7Tp,101] = (nShadeOpen == 0)
[dvCV7Tp,102] = (nLiftOpen == 1)
[dvCV7Tp,103] = (nLiftOpen == 0)
[dvCV7Tp,104] = (nScreenOpen == 1)
[dvCV7Tp,105] = (nScreenOpen == 0)
[dvCV7Tp,106] = (nShadeOpen == 1 && nScreenOpen == 1 && nLiftOpen == 1) //This is status
[/code]
Can someone point me in the right direction?

felixmoldovan · February 2010

You didn't put the '[" on your opening code tag?

Joking... A common mistake I have done a couple of times. In TP Design, make sure the feedback is set on channel.

ericmedley · February 2010

vegastech wrote: »

I am using variables to change the state of my shades, proj lift, and screen buttons. Unfortunately, however, the state is not changing when the variable changes. I have another button, call it status, that does change states:
code]
DEFINE_PROGRAM
[dvCV7Tp,100] = (nShadeOpen == 1)
[dvCV7Tp,101] = (nShadeOpen == 0)
[dvCV7Tp,102] = (nLiftOpen == 1)
[dvCV7Tp,103] = (nLiftOpen == 0)
[dvCV7Tp,104] = (nScreenOpen == 1)
[dvCV7Tp,105] = (nScreenOpen == 0)
[dvCV7Tp,106] = (nShadeOpen == 1 && nScreenOpen == 1 && nLiftOpen == 1) //This is status
[/code]
Can someone point me in the right direction?

Making the following assumption: Your variables only go zero or one. (no two or whatever.)

you don't need the parens.

[dvCV7Tp,100] = nShadeOpen
[dvCV7Tp,101] = !nShadeOpen // !=NOT
[dvCV7Tp,102] = nLiftOpen
[dvCV7Tp,103] = !nLiftOpen // !=NOT

additionally, I'd probably put these inside a wait so they're not evaluated every DEFINE_PROGRAM pass.

WAIT 8
{
[dvCV7Tp,100] = nShadeOpen
[dvCV7Tp,101] = !nShadeOpen // !=NOT
[dvCV7Tp,102] = nLiftOpen
[dvCV7Tp,103] = !nLiftOpen // !=NOT
} // END WAIT 8

It's not that big a deal, however

Spire_Jeff · February 2010

ericmedley wrote: »

Making the following assumption: Your variables only go zero or one. (no two or whatever.)

I don't think it matters in NetLinx. I believe that 0 = false and any non-0 = true. If I get a chance, I will verify this, but I am pretty sure that I have some if() statements that evaluate based on that thought and I would be getting some occasional odd errors if that wasn't true... which means I need to verify this to make sure I don't have the potential for odd errors

Jeff

vining · February 2010

Spire_Jeff wrote:

I believe that 0 = false and any non-0 = true.

Actually true is equal to 1 in the Netlinx.axi. So a non zero that isn't 1 won't equal true. This was discussed several months ago somewhere else in the forum.

DEFINE_CONSTANT
(*-- NetLinx.axi version -------------------------------------------------------------------------*)
(*------------------------------------------------------------------------------------------------*)
(* Added v1.18 *)
(*------------------------------------------------------------------------------------------------*)
CHAR TRUE = 1
CHAR FALSE = 0

Spire_Jeff · February 2010

Sorry, I meant evaluated as true

I will do a little test in the morning to verify and post the results.

Jeff

ericmedley · February 2010

Spire_Jeff wrote: »

I don't think it matters in NetLinx. I believe that 0 = false and any non-0 = true. If I get a chance, I will verify this, but I am pretty sure that I have some if() statements that evaluate based on that thought and I would be getting some occasional odd errors if that wasn't true... which means I need to verify this to make sure I don't have the potential for odd errors

Jeff

What you say is true. However, I guess what I was referring to was some people (myself included) use state variables for more than just binary on and off. I often use 2,3,etc.. for devices. So, I just put that in to make sure this was not the case for the OP. If he was doing this, my advice would have been wrong.

But, my advice always come with the disclaimer of possible wrongness anyway. You get what you pay for.

Spire_Jeff · February 2010

Ok, it works as I hoped. Here is the code:

button_event[dvTP,1]{
	push:{
		stack_var integer x;
		x=1;
		while(x){
			if(x == 10000)
				send_string 0,"'While at 10000'";
			if(x == 20000)
				send_string 0,"'While at 20000'";
			if(x == 30000)
				send_string 0,"'While at 30000'";
			x++;	
		}
		send_string 0,"'While ended with x at: ',itoa(x)";
		
		for(x=1;x;x++){
			if(x){
				if(x == 10000)
					send_string 0,"'For at 10000'";
				if(x == 20000)
					send_string 0,"'For at 20000'";
				if(x == 30000)
					send_string 0,"'For at 30000'";
			}else{
				send_string 0,"'For failed to evaluate true: ',itoa(x)";
			}
		}
		send_string 0,"'For ended with x at: ',itoa(x)";


		x=1;
		while(x == TRUE){
			if(x == 10000)
				send_string 0,"'While at 10000'";
			if(x == 20000)
				send_string 0,"'While at 20000'";
			if(x == 30000)
				send_string 0,"'While at 30000'";
			x++;	
		}
		send_string 0,"'While == TRUE ended with x at: ',itoa(x)";
	}
}

here are the results:

System Output wrote:

Line 1 (09:01:13.906):: While at 10000
Line 2 (09:01:14.187):: While at 20000
Line 3 (09:01:14.468):: While at 30000
Line 4 (09:01:15.453):: While ended with x at: 0
Line 5 (09:01:15.765):: For at 10000
Line 6 (09:01:16.062):: For at 20000
Line 7 (09:01:16.375):: For at 30000
Line 8 (09:01:17.453):: For ended with x at: 0
Line 9 (09:01:17.453):: While == TRUE ended with x at: 2

As is illustrated by the last example, the keyword TRUE does not encapsulate all values that will evaluate to true

Jeff

P.S.
I understand what you are saying now Eric.

ericmedley · February 2010

Spire_Jeff wrote: »

P.S.
I understand what you are saying now Eric.

I don't think my bosses have said that EVER! you just made my day. Thanks!

Spire_Jeff · February 2010

ericmedley wrote: »

I don't think my bosses have said that EVER! you just made my day. Thanks!

Boy do I know that feeling. Glad I could help

Jeff

DHawthorne · February 2010

I use parentheses all the time when they aren't needed, just to make it easier to read the association in code when scanning it. I also tend not to completely trust the precedence rules to be followed perfectly, and figure it can't hurt to force the issue.

I've also had some very inexplicable cases where an implicit comparison didn't work, but an explicit one did. For example, something like IF(!bRandomVar) didn't do what I expected, but, IF(bRandomVar == FALSE) did. I tend to use the implicit form most all the time, but when I get one of those oddball cases, I just add the == to it and move on. I never troubled to figure out why it happens.

jjames · February 2010

DHawthorne wrote: »

I use parentheses all the time when they aren't needed, just to make it easier to read the association in code when scanning it. I also tend not to completely trust the precedence rules to be followed perfectly, and figure it can't hurt to force the issue.

I've also had some very inexplicable cases where an implicit comparison didn't work, but an explicit one did. For example, something like IF(!bRandomVar) didn't do what I expected, but, IF(bRandomVar == FALSE) did. I tend to use the implicit form most all the time, but when I get one of those oddball cases, I just add the == to it and move on. I never troubled to figure out why it happens.

Same here. I almost always now use actual comparisons. I also no longer use the "<>" nor the words AND, OR, etc. It does to me make it easier. Parenthesis I know aren't needed, but it's never bad to be too safe, is it? (I also use the colon to end my lines as well now. Perhaps it's just cuz I've been dabling with other languages, and it feels right to do it in NetLinx.)

mpullin · February 2010

Was the original poster's question answered?

ericmedley · February 2010

mpullin wrote: »

Was the original poster's question answered?

When has this every stopped us from rumbling on for miles? We are the 'coal train' of forums. It takes us a tremendouly long time to stop.

mpullin · February 2010

ericmedley wrote: »

When has this every stopped us from rumbling on for miles? We are the 'coal train' of forums. It takes us a tremendouly long time to stop.

Oh, I was just curious to see if the coal train was pointed in the right direction. The premise was interesting: the button that is populated by the complex comparison yields the correct state but the simple ones do not. Is that correct? Assuming the TP is set up correctly, which it may not be, we have quite a conundrum.

gotta be a typo somewhere...

Comments