Save a stationary file
To set the "Stationery" attribute, you can call FN SETCATINFO. This function sets a bunch of stuff besides just the "Stationery" flag, so to make sure you're not messing up other attributes while setting "Stationery", you need to call FN GETCATINFO first. Here's an (untested!) function that should work.
(You'll probably have to wait until the file is closed before you call this.)
LOCAL FN SetStationery(filename$, wdRefNum%) 'Turns on the "Stationery" flag in the indicated file DIM pb.ioHFQElSiz pb.ioNamePtr& = @filename$ pb.ioVRefNum% = wdRefNum% pb.ioDirID& = 0 pb.ioFDirIndex% = 0 OSErr = FN GETCATINFO(@pb) LONG IF OSErr '[handle the error] XELSE 'Turn on the "Stationery" bit: pb.ioFlUsrWds.fdFlags% = pb.ioFlUsrWds.fdFlags% OR BIT(11) 'Write the whole block back to the catalog: pb.ioDirID& = 0 'Always reset this after calling GETCATINFO OSErr = FN SETCATINFO(@pb) LONG IF OSErr '[handle the error] END IF END IF END FNThe "stationery" bit is meant to be used as a flag telling the application that it should _not_ open the "stationery" file itself, but should instead make a copy of the file and then open the copy instead. That is probably what Clarisworks is doing: If 14 Clarisworks users try simultaneously to "open" a stationery file, none of them is actually opening it for editing, but instead each Clarisworks session makes its own private copy of the file and opens _that_. They're not actually "sharing" the same file. On the other hand, if 14 Clarisworks users try simultaneously to open a NON-stationery file, then each will try to access the same physical file, presumably for both read-and-write access. A given file can have multiple readers but not (except under special circumstances) multiple writers; so you get the "file in use" message.
Stationery is a good idea if users need to read some "template" file, and then make modifications and save their own private modified copies of the "template."
But the "stationery" flag just tells your application the "recommended" way to handle the file. It doesn't technically permit or forbid sharing. Sharing depends on what kinds of permissions are requested when an app tries to open the file, and whether or not those permissions conflict with permissions requested by another app that already has the file open.
I _think_ the OPEN statement requests the following permissions for its various methods, though I can't tell for sure because it tends to handle permission violations by crashing (!):
"I" - I may read; Others may read; no one may write.
"O" - I may write; no others may read nor write.
"A","R" - I may read and write; no others may read nor write.
"N" - I may read and write; others may read, but not write.