There may be a way to shell the permissions, but it would require sudo on a Mac 
and UAC on Windows. There is a locked flag in both OS I believe... but you 
would then have to script saves. An alternative way to semaphore this process 
is to have a text file that you increment a number for anytime changes are 
saved, then check to see if the prior number matches the current number and act 
accordingly. 

But all this really lends itself to the adoption of Trevor's Levure Framework, 
doesn't it? If the only changes being made are script changes, then set the 
permission of the UI stack so that only one person or a group of persons can 
open it for editing, and leave the script only behaviors editable by all. 

Someone can still overwrite someone elses changes though. I was at a SoCal 
users group some time back, and one of the attendees showed off a very nice 
commercial app, and they created their own system where files were checked out, 
including UI files. Otherwise GIT can be used to control access and versioning. 

Bob S


> On Oct 25, 2017, at 11:03 , Ralph DiMola via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> True, The stack is not open after it's read into memory. I can see why/why
> not this is done from a LC point of view. If the stack is being read in from
> a web server it's not possible to lock it. If the file is local/network then
> the stack could remain open and locked for write. Other processes could then
> open/read it but not save it. This looks like it's been around for a long
> time. Could locking stack(s) break existing projects? I vote to lock for
> write any open stacks.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net


_______________________________________________
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

Reply via email to