Sending On/Off from TPdesign

adys

Hi all

I am trying to send an ^ANI command from the TPDesign CommandOutput field.

If the button is declared as a multi state button, its working. If its as a general button, its not, even that I use states 1 and 2 only.

how can I send on/off commands from this field to a general button?

I don't want to change my buttons just for this, and I don't want to do it in code.


Thanks

Adys.

yuri

why can't you keep them multi state? it's working that way right?

vining

adys wrote:
I am trying to send an ^ANI command from the TPDesign CommandOutput field.

What are you attempting to achieve by sending the command from the button instead of through code. It's seems to me to be a convoluted way of doing anything.

Other than the obvious method through code I don't see any other way of changing the button state from the TP other than using a send_level. If you don't want to switch from general to mulit state to use the "ANI" command I doubt you'll want to change to a multistate bar graph and try a send_level command. If it even works from there.

yuri

vining wrote:

What are you attempting to achieve by sending the command from the button instead of through code. It's seems to me to be a convoluted way of doing anything.

Other than the obvious method through code I don't see any other way of changing the button state from the TP other than using a send_level. If you don't want to switch from general to mulit state to use the "ANI" command I doubt you'll want to change to a multistate bar graph and try a send_level command. If it even works from there.

maybe he wants to have a touchpanel that has nice looks, but still works offline? AMX uses this for all their demo panels too. You can program the loopback port to use all the commands you can use from code

ericmedley

Hmm...

I never want a touch panel to work when the master is offline. I've never thought about that. I would think that would make troubleshooting a bit more difficult.

Interseting...

DHawthorne

ericmedley wrote:

Hmm...

I never want a touch panel to work when the master is offline. I've never thought about that. I would think that would make troubleshooting a bit more difficult.

Interseting...

Demo units for the sales people to cart around and show off to potential customers.

adys

Thanks


So there is no way for doing it?


Tp me it looks bad to open popup in one place and handle the button state in another, and I don't want to open the popups in code...

If I can send simple buttons states commands from the TP - why not?

Think about the folowing example:

I have a button that open a small speakers mapping popup and becoming red. When another button pressed on this screen he close the speakers screen and the button becomes white again. (On/Off)

Its so simple to do it from the TPDesign, why do I need to write a BUTTON_EVENT code, handle full of states and scenarios from all the places that need to close this screen (a lot) instead of doing it in TPDesign + I can see it in preview and debug all scenrios in preview time?




Just all the buttons are general now and I wanted to know if there is anyway to change a state of a button from the TP...

BTW - how can I ask for a buttons state from my code?


thank again guys


Adys

Spire_Jeff

I can think of one very big reason to not handle button state changes from the touchpanel. If the touchpanel can appear to work without having to talk to the processor, then there exists a possibility that the processor will not receive the information and nothing will happen when the button is pushed. The fact that the touchpanel appears to work and nothing is happening will confuse and iritate the client and make it difficult for you to diagnose a communication problem over the phone. It also means that the touchpanel could be reporting different button states than the processor sees.
Another reason would be that button feedback is not always driven by the user pushing a button on the touchpanel. If you are reporting when a light is turned on, what happens if someone turns off the light from a different touchpanel or from the switch itself? If your feedback is driven from the touchpanel, there is not an easy way to update the touchpanel and it will often display the wrong states.
I even handle my popup control from the program so that it becomes very apparent when pushing a button on the touchpanel will do nothing. This is a matter of personal preference and opinion of course.

I just reread your post and as for viewing button states in your program, it is easy. [DEVICE,CHANNEL_NUMBER] is a true/false indication of the channel state. For example,

SELECT
   {
     ACTIVE([dvTP1,SPKR1]):
       control speaker one volume
     ACTIVE([dvTP1,SPKR2]):
       control speaker two volume
     ACTIVE([dvTP1,SPKR3]):
       control speaker three volume
     ACTIVE([dvTP1,SPKR4]):
       control speaker four volume
     ACTIVE([dvTP1,SPKR5]):
       control speaker five volume

   }

Another reason to handle things in code is that it is generally easier to make changes in code than in the touchpanel files, especially if you start using mulitple touchpanel files and multiple touchpanel screen formats.

Jeff

GregoryArndt

I would agree that handling button events can get rather tedious in code when you have multiple touch panels and thousands of buttons. Not to mention handling the page flips and popups in code as well. I think it should be a balance between the two. I like to have enough functionality in the touch panel itself to demonstrate to the client stand-alone, but handle the more complicated events in code.

I would have to back up Jeff on the button feedback, though. I recently had a project with 12 touch panels, all crossing over each other controlling the same devices. If one TP user does not know what another user is doing or has done, it can lead to very irritating phone calls.

DHawthorne

GregoryArndt wrote:

I would agree that handling button events can get rather tedious in code when you have multiple touch panels and thousands of buttons. Not to mention handling the page flips and popups in code as well. I think it should be a balance between the two. I like to have enough functionality in the touch panel itself to demonstrate to the client stand-alone, but handle the more complicated events in code.

I would have to back up Jeff on the button feedback, though. I recently had a project with 12 touch panels, all crossing over each other controlling the same devices. If one TP user does not know what another user is doing or has done, it can lead to very irritating phone calls.

Yeah, the entire point of feedback is to tell you the state of the equipment - not what button you pushed.