fitz@cive.ri.cmu.edu (Kerien Fitzpatrick) (10/12/87)
I was looking through the HyperCard manuals for information about whether or not stacks can be viewed by more than one user at a time. I am interested in setting up an appointment book, address book, and phone dialer stack that more than one person could access at the same time. It seems this has been overlooked or the procedure required is undocumented. If it is not possible I would view this as an incredible oversight by Apple. Does anyone have any information that might allow me to sort out how to accomplish multi-user stacks? Any info would be greatly appreciated. Kerien Fitzpatrick Carnegie Mellon University The Robotics Institute Pittsburgh, PA 15213 (412)268-6564 Arpanet: fitz@cive.ri.cmu.edu
anson@elrond.CalComp.COM (Ed Anson) (10/12/87)
In article <1051@cive.ri.cmu.edu> fitz@cive.ri.cmu.edu (Kerien Fitzpatrick) writes: >I was looking through the HyperCard manuals for information about whether or >not stacks can be viewed by more than one user at a time. Tough luck. It looks to me like HyperCard opens every stack read-write, which means exclusive access. This leads to several other anomalies, which annoy me to no end: It's not possible to browse a stack which is locked or is on a write protected diskette. Browsing any stack causes my backup utility to back it up again. Apparently, this is because of the automatic save feature. Apple, why not go ahead and open for browsing, and just warn the user that updates can't be saved, if the file isn't available for writing? And why not provide a HyperTalk command to open read-only (as in Browse)? -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
steele@unc.cs.unc.edu (Oliver Steele) (10/14/87)
russell@acf3.NYU.EDU (Bill Russell) writes: > >Yes, indeed. The stack backup problem kills me -- it makes a brilliant >utility like DiskFit into a painful-to-use chore. Even though we all know >why the problem occurs -- it should be considered a BUG. It is a great pitty >that Atkinson thinks that saving is something the lowbrow user can NEVER be >taught to do. So we all have to suffer. Sometimes scripts in cards need to alter the state of the stack. For instance, info buttons often change the state of a field to visible. Since a user may alter the states of several cards, even at the browse level, or he may leave the stack and then come back to it, this state information has to be stored in the stack file unless you introduce some rather complex linked files which personalize a stack for each user. I agree that HC modifies to often. It will usually time-stamp stacks for which there is no changed state information, although sometimes it will leave the dates alone. Remove all the scripts from the Slide Show and it still time-stamps when you visit; look at the index to the recently posted Periodic Table and it doesn't. Can anybody figure out why? ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "If God had meant for man to Walk, he would have given us Feet."
mce@tc.fluke.COM (Brian McElhinney) (10/14/87)
The auto-save feature appears to have been a "neat hack" with little thought given to its actual use. Now auto-save in itself is an excellent feature, but it should NEVER alter the original file without the explicit consent of the user. I would be very interested in hearing how this was justified. One thing is for sure: auto-save will be "fixed" in some manner. Otherwise Hypercard will never be able to open the much-hyped CD-ROM stacks! Brian McElhinney mce@tc.fluke.com
chuq%plaid@Sun.COM (Chuq Von Rospach) (10/15/87)
>The auto-save feature appears to have been a "neat hack" with little >thought given to its actual use. Now auto-save in itself is an excellent >feature, but it should NEVER alter the original file without the explicit >consent of the user. I would be very interested in hearing how this was >justified. A couple of reasons of the top of my head: o Technical: Trying to save and batch changes would take an amazing amount of memory and the overhead woul slow things down significantly. To do what Hypercard does at the speed it does, they had to do it this way. o Design: A good claim can be made that every time you push a button (or type in a field, etc...) that you've made an impllicit agreement to save with the application, so an explicit save isn't necessary. Many applications work this way on the mac (one example: filemaker plus). it might be nice to have a hypercard option to make a backup of a stack on StackOPen (in fact, you can probably write it into the stack script) but it should be optional. >One thing is for sure: auto-save will be "fixed" in some manner. Otherwise >Hypercard will never be able to open the much-hyped CD-ROM stacks! I don't see this at all. Set the user level to 'browse' only, and you're all set for CD-ROM. Since you can't change it, just let the user sniff around. chuq Chuq Von Rospach chuq@sun.COM Editor, OtherRealms Delphi: CHUQ
steele@unc.cs.unc.edu (Oliver Steele) (10/15/87)
chuq@sun.UUCP (Chuq Von Rospach) writes: >>One thing is for sure: auto-save will be "fixed" in some manner. Otherwise >>Hypercard will never be able to open the much-hyped CD-ROM stacks! > >I don't see this at all. Set the user level to 'browse' only, and you're all >set for CD-ROM. Since you can't change it, just let the user sniff around. Have you tried this? HyperCard 1.0.1 gives me an error if I try to browse a locked stack or a stack on a locked volume. My guess is that this is because the scripts in some stacks may change state information, such as whether an info field is visible or what buttons are showing, and HC can't know in advance whether any stack is such a stack. ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "'As it were' means 'I think that I sound very erudite.' 'Per se' is Latin for 'as it were.' As it were."
robertj@yale-zoo-suned..arpa (Rob Jellinghaus) (10/15/87)
Distribution: In article <30928@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>One thing is for sure: auto-save will be "fixed" in some manner. Otherwise >>Hypercard will never be able to open the much-hyped CD-ROM stacks! > >I don't see this at all. Set the user level to 'browse' only, and you're all >set for CD-ROM. Since you can't change it, just let the user sniff around. > >chuq >Chuq Von Rospach chuq@sun.COM >Editor, OtherRealms Delphi: CHUQ Actually, there may be a problem with this. In Browse mode, the cursor never becomes the I-beam. Which means you can't select text within fields. Which means you can't copy text out of a stack when you're in browse level... This could be quiiite a handicap if you can't copy any interesting text (or pictures, actually) out of a CD-ROM stack!! It looks like there will *have* to be some extensions to allow you to use the selecting tools (I-beam, lasso, rectangle) on a card without having to auto- save the stack. Browse mode only won't cut it... The latest issue of MacUser had a rumor that Atkinson is already working on another program. Say it ain't so, Bill! Hypercard ain't finished yet! Robert Jellinghaus | "Check out Mr. Businessman, uh-oh... jellinghaus@yale.edu.UUCP | He got some Wild Wild Life" ROBERTJ@{yalecs,yalevm}.BITNET | !..!ihnp4!hsi!yale!jellinghaus | -- T Heads
beloin@batcomputer.tn.cornell.edu (Ron Beloin) (10/15/87)
In article <30928@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>One thing is for sure: auto-save will be "fixed" in some manner. Otherwise >>Hypercard will never be able to open the much-hyped CD-ROM stacks! > >I don't see this at all. Set the user level to 'browse' only, and you're all >set for CD-ROM. Since you can't change it, just let the user sniff around. I was also annoyed at the time-stamping of stacks that I had't touched (but opened), so I tried on openStack set userlevel to browse end openStack Well, it doesn't work. Even in browse only, HC still changes the mod date. I think they'll probably fix this eventually. ron.
bc@mit-amt.MEDIA.MIT.EDU (bill coderre) (10/16/87)
At this time, Hypercard always has to have write access to any stack it opens. Be aware that this is well known by the Hyperfolx, and that they are going to change it. As for the business about writing changes immediately: think carefully for a while and see if it makes sense not to. But hey, I don't work for Apple at this time.......................bc
chuq%plaid@Sun.COM (Chuq Von Rospach) (10/16/87)
>The latest issue of MacUser had a rumor that Atkinson is already working on >another program. Say it ain't so, Bill! Hypercard ain't finished yet! MacUser has also consistently talked about the upcoming developer revolt against Hypercard. With the exception of Guide, I haven't heard a word of this anywhere else, here or in any of the press. They seem to hyping up a rebellion that don't exist. There rumor mill has NEVER been very reliable (to put it mildly)(. Chuq Von Rospach chuq@sun.COM Editor, OtherRealms Delphi: CHUQ
steele@unc.cs.unc.edu (Oliver Steele) (10/16/87)
robertj@yale.UUCP writes: > >[....]In Browse mode, the cursor never >becomes the I-beam. Which means you can't select text within fields. Which >means you can't copy text out of a stack when you're in browse level... This >could be quiiite a handicap if you can't copy any interesting text (or >pictures, actually) out of a CD-ROM stack!! You can still command-click and command-drag on text in fields, unlocked or not. Pictures you can catch with shift-command-3 or one of several DAs. You're right about multi-line text, though, and there should be some more intuitive way of doing this. ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "'As it were' means 'I think that I sound very erudite.' 'Per se' is Latin for 'as it were.' As it were."
paulm@nikhefk.UUCP (Paul Molenaar) (10/17/87)
In article <17670@yale-celray.yale.UUCP> robertj@yale.UUCP writes: >In article <30928@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>>One thing is for sure: auto-save will be "fixed" in some manner. Otherwise >>>Hypercard will never be able to open the much-hyped CD-ROM stacks! >> >>I don't see this at all. Set the user level to 'browse' only, and you're all >>set for CD-ROM. Since you can't change it, just let the user sniff around. >> >>chuq >>Chuq Von Rospach chuq@sun.COM >>Editor, OtherRealms Delphi: CHUQ > >It looks like there will *have* to be some extensions to allow you to use the >selecting tools (I-beam, lasso, rectangle) on a card without having to auto- >save the stack. Browse mode only won't cut it... > During a meeting in Amsterdam (you know, in Holland) Bill Atkinson said something about using HyperCard in combination with a CD-Rom device. In short: HyperCard saves the _changes_ you make to a CD-Rom on disk (harddisk most likely) and when read again, reads the 'image' from CD-Rom and applies the changes made to it (reading them from disk, naturally). I agree the AutoSave 'feature' is annoying, but it seems no problem when used in combination with CD-Rom. . . . waste of space . . Paul Molenaar "Just checking the walls" - Basil Fawlty - -- Paul Molenaar "Just checking the walls" - Basil Fawlty -
mce@tc.fluke.COM (Brian McElhinney) (10/20/87)
>o Technical: Trying to save and batch changes would take an amazing amount > of memory and the overhead woul slow things down significantly. > To do what Hypercard does at the speed it does, they had to do it > this way. How about making a copy of the file you are opening? Hardly a revolutionary idea: replace the old file with the new one when doing a save; if there isn't enough disk space throw up a dialog saying that changes will be permanent. Sure that hurts perfomance, but only when opening and closing files. >o Design: A good claim can be made that every time you push a button (or > type in a field, etc...) that you've made an impllicit agreement to > save with the application, so an explicit save isn't necessary. Many > applications work this way on the mac (one example: filemaker plus). Perhaps this is a "religious" matter, but this is the only defense I have heard of Hypercards auto save (even the Apple reps I have talked to agreed it is a Bad Thing). It gives people a warm fuzzy feeling to know they can screw up and easily recover by simply not saving changes. Hypercard is an amazing piece of software, but what ever happened to the wonders of a standard user interface? No, it should not grow cobwebs, but change for the sake of change is to be avoided. Brian McElhinney mce@tc.fluke.com
anson@elrond.CalComp.COM (Ed Anson) (10/22/87)
In article <261@nikhefk.UUCP> paulm@nikhefk.UUCP (Paul Molenaar) writes: >In short: HyperCard saves the _changes_ you make to a CD-Rom on disk (harddisk >most likely) and when read again, reads the 'image' from CD-Rom and >applies the changes made to it (reading them from disk, naturally). This is a good solution to the problem. Now, why can't we get HC to do the same thing for any locked file? Now why would I want to do that? Well, for one thing, I could then always get back to the original, unadulterated, distributed version of the stack. And even better, I would probably have a much smaller file to backup at the end of the day. Just a thought. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM