[comp.sys.mac.programmer] Resource Weirdness

trebor@biar.UUCP (Robert J Woodhead) (06/21/89)

I'm trying to do some pretty standard resource operations and getting the
strangest results.  Basically, what I am trying to do is save a document's
data in two parts, normal ``text'' that any other app can read, and a
resource that gives my app extra information.  I already know of the problems
the Poor Man's Search Path creates with OpenResFile, but my results are
bizzare.

Here is what I am doing :

	standard SF dialog to get filename and WDRefnum
	GetVol to get current volume or working directory
	SetVol to the WDRefnum

	Delete to trash any existing version of the file
	Create
	Open
	Write the text
	Close

	CreateResFile to create the resource fork
	OpenRFPerm to get it open (with StripAddress too!)
	UseResFile because I'm paranoid
	AddResource
	CloseResFile

	SetVol back to original volume
	UseResFile back to my app's resource file.

Now get a load of what is happening:

	The file gets created in the right folder.
	The data fork gets written correctly.
	The resource fork gets _created_.
	The new resource goes in my app's resource fork, and
	is of semi-random length.  I've had ResEdit tell me
	the resource is several megabytes long!

This may be a no-brainer (gawd, I hope it _is_!), but I would greatly
appreciate help on this one.

-- 
(^;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;^)
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | trebor@biar.UUCP
  ``I can read your mind - right now, you're thinking I'm full of it...''

trebor@biar.UUCP (Robert J Woodhead) (06/21/89)

In article <664@biar.UUCP> trebor@biar.UUCP (Myself, confused) writes:
>	The file gets created in the right folder.
>	The data fork gets written correctly.
>	The resource fork gets _created_.
>	The new resource goes in my app's resource fork, and
>	is of semi-random length.  I've had ResEdit tell me
>	the resource is several megabytes long!

	Ok, in the tradition of ``5 minutes after you post a message
	for help, things become clear'' I've found part of the
	problem:  The reason the resource was of random length
	was because I didn't HandToHand the original handle and
	subsequently released it.

	HOWEVER, I still have the problem that the damn thing is
	getting stored in the wrong resource fork.

If anyone has some sample code for ``getting user's file choice and
stuffing data and resources into that file,'' I would greatly appreciate
seeing it.

-- 
(^;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-;^)
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | trebor@biar.UUCP
  ``I can read your mind - right now, you're thinking I'm full of it...''

svc@well.UUCP (Leonard Rosenthol) (06/22/89)

In article <664@biar.UUCP>, trebor@biar.UUCP (Robert J Woodhead) writes:
Here are some comments about your scheme that may or may not be causing the
problems you are seeing. 

>Here is what I am doing :
>
>        standard SF dialog to get filename and WDRefnum
>        GetVol to get current volume or working directory
>        SetVol to the WDRefnum
>
	So far so good.

>        Delete to trash any existing version of the file
>        Create
>        Open
>        Write the text
>        Close
>
	I have a personal beef against anyone who does this.  Above you say that
the reason you are writing both TEXT and resources is so that other programs can
get at the data in the data fork - well if you are going to DELETE the file each
time YOU modify it then all of the additional data that other apps put in ther
will be lost.  Example, MPW (and other editors) store resources that keep info
like window positions, default font/size, etc. and your scheme will destroy that
info and your users will not be happy.  If other 'editors' did this to your
files your uers would lose thier data from your file.
	A better method is to do an open on the file, it is succeeds then  do
a SetEOF to the beginning of the file (ie. 0) and then do your write.  If it
fails (like file does not exist) then create it, and write.  This works just
fine and won't destroy any other apps data.  

>        CreateResFile to create the resource fork
>        OpenRFPerm to get it open (with StripAddress too!)
>        UseResFile because I'm paranoid
>        AddResource
>        CloseResFile
>
	Again, since you not going to destroy the file first, you need to check
for the resource fork first and only if it does not have one then create it.
Just out of curiousity, you might try using an OpenResFile instead of the 
OpenRFPerm to open up the file.  You shouls also try a WriteResource after
the Add to make sure that it gets written as well as an UpdateResFile before
the close to also double check the writing.

>        SetVol back to original volume
>        UseResFile back to my app's resource file.
>
	You didn't mention it, but I assume that you got the resfile originally
so that you could restore it here.

	Hope these comments help...

-- 
+--------------------------------------------------+
Leonard Rosenthol        |  GEnie : MACgician
Lazerware, inc.          |  MacNet: MACgician
UUCP: svc@well.UUCP      |  ALink : D0025