lock screen gotcha revisited

[Bob Sneidar]

The general consensus is that it doesn't. I think there was something else going on where my screen was not updating even after 5 successive screen unlocks, and I never figured out why, but I went through my app and every place there was a lock screen, I added an unlock screen to the end of the handler, EVEN IF it was the last line of code to execute. I also made sure that the first script to update the screen at all was the ONLY place I locked the screen, so that I did not have any nested locks. Now all works as advertised. 

My point was that a simple updateScreen command for a one time screen refresh whilst maintaining the lockScreen status and counter would be all that was needed to work around this oddity. That way there could be handlers that were sometimes called by handlers that had already locked the screen and some that hadn't, and it wouldn't matter because any time I needed to refresh the screen I could just force the issue. 

Not to be too long winded here, but imagine a handler that updated a datagrid and set the selection. Another handler that populated some fields based on that selection. There might be times when I only want to populate the fields because only the contents of the record changed. Other times I need to update the datagrid only, or the selection too. I ought to be able to put a lock screen in both handlers, and then no matter how many nested locks there were, have a command in my setStatusMsg that was able to refresh the screen to display the status message. 

It's not critical though. It just looks messy when 20 fields progressively update. The visual effect is a bit ugly. 

Bob S

 
> On Aug 21, 2017, at 15:47 , prothero--- via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I didn't realize that the lockscreen command only applied to the handler that sets it.