Hi Alex, This is fairly long but there is no code in the explanation. I ran into this problem last year. I have a stack that monitors 3 security systems. You can switch between the system with the one stack or you can use 3 separate stacks to monitor the different systems.
Here was my problem. There are 172 buttons and 171 fields on the main card which shows the status of each security alarm. The stack is 992 x 902 pixels in size. When you first connect to a security system the stack sends a message to get the security systems state. The system sends back the complete state for all the buttons and fields on the card via an xml file. Without locking and keeping the card locked until the update is complete, it took a minimum of one minute and 45 seconds to perform the update. By locking the card until the update is complete it takes less than a second. Obviously, it was because of the time that it took to set each button and each field and in between setting one of them it draws the whole card. I also found that even with the card locked it took about 15 milliseconds to set the state of a button or field even though most of the time it was what the state already was. So I simply check the state before I set it and if is the same as what I was going to set it too, I don't bother to set it. This check takes less than a millisecond. I have a routine that gets called when I want to get the entire state of the card. All it does is set a global to true and asks for the state. Every routine that is used to update the card buttons or fields checks the global and then checks the state of the lock screen. If they are the same it continues on. If they are different it sets the lock screen state to that of the global and goes on. Since I don't know when the update will be complete, I check when I enter the main routine that handles all the input from the security system, to see if there is a pending update for the card. If there is not, then I put false into the global and continue on since that means all the updates have been handled. This update would happen any time you connected to one of the security systems. This happens when you launched the stack or turn it on, if it was turned off or you switched from one security system to another or loaded a new xml file to set up the security system. All of those actions would force a status update from the security system. So I don't know if it does anyone else any good. But for my stack it was at least 145 times faster to update the main card. Best Regards, Ron > On Dec 31, 2018, at 3:27 PM, Alex Tweedly via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Yeah, that seems like it might work - but it doesn't. > >> on mouseUp >> put 1 && the lockscreen &CR after msg >> set the lockscreen to true >> put 2 && the lockscreen &CR after msg >> wait 0 seconds with messages >> put 3 && the lockscreen &CR after msg >> end mouseup >> > gives > >> 1 false >> >> 2 true >> >> 3 true >> > I guess being in an 'active' wait doesn't count as idle... > > Need to do the brute force loop as Craig suggested. > > Alex. > > >> On 31/12/2018 17:21, Bob Sneidar via use-livecode wrote: >> There IS a method for unlocking all. wait 0 seconds with messages. All >> screen locks are cleared when the idle message is sent. >> >> Bob S >> >> > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
