american@pnet51.cts.com (Jeff Iverson) (05/09/89)
I think I've spotted a problem with the cantModify property. While creating a
multiuser-multistack-distributed database in HyperCard I found a need to
determine if more than one person was accessing the same stack at the same
time (since only one may write and all the rest may read). It occurred to me
to get cantModify and if it was true, then there was obviously someone in the
stack with write access. However, much to my chagrin, I discovered that while
one may set cantModify, they may not get cantModify. Why is this? It seems
to me to be obviously desireable, and not an appreciable hardship for
HyperCard to perform the task. The workaround, for now, is to set a flag if
one has write access, and test for that flag on every entry to the stack.
While this doesn't add much overhead, it would be nice to use structures that
are built in to HyperCard than adding devices to my stacks to do HyperCard's
job.
Yours in HyperCard,
Jeff Iverson
UUCP: {amdahl!bungia, uunet!rosevax, chinet, killer}!orbit!pnet51!american
ARPA: crash!orbit!pnet51!american@nosc.mil
INET: american@pnet51.cts.comblob@apple.com (Brian Bechtel) (05/10/89)
In article <1114@orbit.UUCP> american@pnet51.cts.com (Jeff Iverson) writes: > However, much to my chagrin, I discovered that while > one may set cantModify, they may not get cantModify. Sure you can. Try "put the cantModify of this stack". You'll get back the current setting. Another example (that I use frequently) is set the cantmodify of this stack to not the cantmodify of this stack --Brian Bechtel blob@apple.com "My opinion, not Apple's"