Namiong a wait with a variable
a_riot42
Posts: 1,624
Is there a way to name a wait with something other than a literal string? If I have 10 TPs that need independent waits, I have to write code to support all 10 rather than using one event that uses a different name depending on which TP is triggered. The wait is started by a user pressing a button on a TP so obviously there can be 10 different independent waits. I can use a timeline but that gets tricky as well.
Instead of this:
wait 20 'Theater Timeout'
{
}
wait 20 'Living Timeout'
{
}
wait 20 'Kitchen Timeout'
{
}
I need to be able to do this:
wait 20 namedWaits[ui]
{
}
Paul
Instead of this:
wait 20 'Theater Timeout'
{
}
wait 20 'Living Timeout'
{
}
wait 20 'Kitchen Timeout'
{
}
I need to be able to do this:
wait 20 namedWaits[ui]
{
}
Paul
0
Comments
DEFINE_VARIBLE
VOLATILE INTEGER NAMED_WAITS []=
{
20,30,40,50
}
THEN
Do Something
Wait NAMED_WAIT[1]
Do Something Else
Thanks but that is not what I asked. I realize I can change the time of the wait at runtime, but I need to change the name of the wait at runtime.
Paul
In your case, I would create an integer array the size of the number of TPs you need, and have a 'wait 1' running in DEFINE_PROGRAM that loops through the array, subtracting 1 from all the cells that have a value > 0, and performing an action if 1 is reached. Then to invoke a wait for a room you'd do something like
nTP_Timeout[ROOM_THEATER] = 20;
instead of
wait 20 'Theater Timeout' {
Paul,
Take a look at using timelines for your code solution. The object TIMELINE.ID can be used to populate an array index to determine which panel to associate with. You can also kill a timeline by index (ID) which is similar to canceling a named wait.
If you have ACE forum access, check out this post and code block.
http://www.amxforums.com/showthread.php?t=1492
If not, send me a PM and I will forward.
Thanks, that sounds interesting. I thought about doing timelines, but that would require making all my variables global which I wanted to avoid, and complicates things unnecessarily. But there may not be any other way. I don't have access to the ACE forum.
Thanks,
Paul
What about using one timeline with a 1 second repeat. Then using an array of countdown times. There would be one countdown time per TP.
timeline[onesecondTL]
{
for (TPcount =1, TPcount<=number of TPs,TPcount++)
{
if (TPwait[TPcount]) TPwait[TPcount]--
if (TPwait[TPcount] = 1) {} //fire some event for that TP
}
}
This way you could adjust the wait for anytime you want in 1 second increments with 1 timeline. just changing the value in the array will start the countdown. Just a thought.
It is a matter of taste I suppose, but I don't care for the fact that timelines require code to be added in so many places: 1) declare the array of LONGs for each step of the timeline, 2) declare a LONG constant for each timeline in your program, 3) create the timeline, and finally 4) have a timeline_event block that represents what actually happens in the timeline.
Waits are more elegant, they just have some... strange limitations.
Please reference the thread http://www.amxforums.com/showthread.php?t=1473 for some history.
This code block should allow you to control volume from multiple panels with a single set of volume buttons.
I hope you find it useful and don't hesitate to comment.
Brian
Thanks Brian. I don't think that will work for my situation though. I am not trying to use get_last in a hold or anything like that. I am trying to track 10 named waits triggered by button presses, with one block of code. The waits aren't in a button event, but rather a function. Rather than having 10 functions that are exactly the same except for the name of the wait, I would like to be able to collapse the functions into one generic function and the named wait is the only thing tripping me up.
It is looking like using 10 timelines is the only way to deal with it that I can see since a wait needs to be named with a literal string at compile time.
Paul
Don't know if this will help but I often make functions to handle various waits and use a switch/case on an incoming parameter to route it to the correct wait. If your trying to do something more dynamic you could create an integer array to keep track of the waits being used and then determine the next wait to issue.
Might be a little easier than timelines.
DEFINE_FUNCTION fnAxis_FollowUpQuery(INTEGER iQuery,INTEGER iWaitTime) { SWITCH(iWaitTime) { CASE AXIS_SHORT_POSQUERY_WAIT: { LOCAL_VAR INTEGER nQuery ; nQuery = iQuery ; CANCEL_WAIT 'QUERY_WHEN_DONE_SHORT' ; WAIT iWaitTime 'QUERY_WHEN_DONE_SHORT' { fnAxis_QueueCmd("'PTZ-query=',AXIS_QUERY_VALUE_ARRY[nQuery]") ; } } CASE AXIS_MEDIUM_POSQUERY_WAIT: { LOCAL_VAR INTEGER nQuery ; nQuery = iQuery ; CANCEL_WAIT 'QUERY_WHEN_DONE_MEDIUM' ; WAIT iWaitTime 'QUERY_WHEN_DONE_MEDIUM' { fnAxis_QueueCmd("'PTZ-query=',AXIS_QUERY_VALUE_ARRY[nQuery]") ; } } CASE AXIS_LONG_POSQUERY_WAIT: { LOCAL_VAR INTEGER nQuery ; nQuery = iQuery ; CANCEL_WAIT 'QUERY_WHEN_DONE_LONG' ; WAIT iWaitTime 'QUERY_WHEN_DONE_LONG' { fnAxis_QueueCmd("'PTZ-query=',AXIS_QUERY_VALUE_ARRY[nQuery]") ; } } } RETURN ; }That would seem to be a reasonable alternative. I could have one function that had a switch/case in it or called a function with the switch/case that would do the appropriate thing depending on what TP triggered the wait. I still want to think about it, as it seems there should be an elegant way to do this, but I see no reason why that wouldn't work.
Thanks,
Paul
I did not think you needed to control volume...just illustrating the stacked timeline concept with the TIMELINE.ID object to determine what touch panel to reference. I used to code discrete named waits with Select/Active, but changed my technique once timelines became available in NetLinx. It is the closest thing to having variable named waits. Timelines are essentially named waits, only much more accurate and flexible.
Good luck with your project.
I don't disagree. The only thing I don't like about them is that it requires all variables involved to be global, But I will try what you suggest and see if it will work for my purposes.
Paul