On June 11, 2022 at 16:33, randman said...
The timings of how long the processor and projector take to start don't change (unless I buy new equipment), so instead of re-polling their power status after initially querying their status and starting them, I've already accounted for how long they take to start, and have coded the script with appropriate "please wait" times. Also, depending upon the device, just because its RS232 says it has already "powered on", doesn't necessarily mean it's ready to accept new commands (such as switching inputs). Hence, an additional delay after the device says it has powered on state may still be needed.
As Lyndel suggested, don't use any blocking delays.
With a task queue you push any needed commands into the queue with a "due time" ... and you probably don't need to worry about them again as the queue works through the list. If your task queue is clever enough, you can find and/or cancel commands or verify that a command has executed. If a critical, scheduled command has not yet executed and the user must wait, then you can start up a PW, but only for the remaining critical time. Make sure that your PW is not blocking the task queue. All sorts of clever, attention diverting activities can be devised to ease the pain of that projector start.
For example, if you must wait for the projector and the receiver starts quickly, you can allow the user to go to the receiver control page and work with selecting surround modes or similar. Then, if you have a multi-disc player, you can go to its control page and select a disc to play -- after searching through a library of titles if you have these stored on the Pronto. If the disc player is slow starting up, queue its commands too.
An interesting little "glitch" can occur if you use blocking delays. Suppose that the receiver starts up, playing loudly, and the user is trapped in a blocking PW with no option to lower the Volume. This can create tense situations in the household. With a task queue the Volume control can always be active.
