[comp.sys.mac.programmer] SFPGetFile

wieser@cs-sun-fsa.cpsc.ucalgary.ca (Bernhard Wieser) (11/03/90)

Hi net-people!

I think I've discovered a neat hack.  Of course, hacking is bad, so
I'd like people's comments on how safe this is.

What I did, is add a button to the standard get file dialog which would
exit out of SFPGetFile and return the active list item (if any).  Why?
I want to be able to select a folder without opening it.  I didn't
want to write tons of code to manage the stuff if theoretically its
already lying around.

pascal int dlgHook(item, theDialog)
int item;
DialogPtr theDialog;
{
	SFReply *reply;

	if(item == myButton) {
		asm{
			MOVE.L	A4,reply ; assume A4 holds the reply record
			}
		reply->good = TRUE;
		item = getCancel;
		}
	return(item);
}

This seems to work perfectly, BUT, can I always rely on A4 pointing to
SFReply?

Please send me replies vie e-mail if you have comments/grumbles.
Bernie Wieser, Student at U of C, Developer of Computer Things

wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) (11/04/90)

Maybe I should also mention, that reply->fType contains the directory
ID if it is a folder, and not the file type.  What I ended up doing,
was doing a call to PBGetCatInfo with this ID, hence getting the
name and volume which I set before returning to SFGetFile.  If it
was a file, I just returned getOkay instead of getCancel.  Seems to
work charmingly.

wiechman@athos.rutgers.edu (NightMeower) (11/04/90)

Your hack is probably only good for the very short term and perhaps
not even that long.  If you run under different systems you error will
probably occur.  Apple regularly updates its compilers that are used
to build the system.  It is highly possible that a certain registers
will be used differently in a different version of the compiler.

Look at dts sample code #18 which does exactly what you are
requesting.  The back door that is shown uses the fact that the
sfreply.osype field is set to be the directory id of the hilited
folder.  You'll need a couple of global variables but following the
example, you should be able to get something working on almost the
first try in an hour or so.  Plus, you will be more compatible in the
long run.

Sample code from the dts may be gotten by anonymously ftping to
apple.com:pub/dts/mac/sc/sc-018-stdfile.hqx.

Kevin
-- 
===========================================================================
Kevin S. Wiechmann			arpa:  wiechman@rutgers.rutgers.edu

	 This is only a test... for the next sixty seconds...

wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) (11/04/90)

Um, I am using reply.fType to get the directory ID from the dialog hook.
The thing is, I don't want to have a global lying around to contain
reply.  I use SFSaveDisk (the system global which is the negative
of the current SF volume) to figure out which volume I'm on; this
helps heaps since cmd-shift eject and other commands are processed
first so this value seems always current.  I then use PBCatInfo
to get folder names and stats.

One thing which worries me; fType holds the dir id or the type when
looked at in the dialog hook.  I check the first byte to see if it
is < 20, if so I think its a dir id but I have a feeling this isn't
safe.

gurgle@well.sf.ca.us (Pete Gontier) (11/08/90)

In article <Nov.3.16.31.42.1990.22161@athos.rutgers.edu> wiechman@athos.rutgers.edu (NightMeower) writes:
>requesting.  The back door that is shown uses the fact that the
>sfreply.osype field is set to be the directory id of the hilited
>folder.

Yes and no. My experience has been that the field is not filled
in until the user actually uses the mouse to click on the list
item. If a new list appears because the user hit the Drive button
or the directory popup menu, the first item in the list i
highlighted, but if it is a directory, its dirID is not in
SFReply.OSType.

Anybody have any ideas?
-- 
 Pete Gontier, gurgle@well.sf.ca.us
 Software Imagineer, Kiwi Software, Inc.

yossie@fnal.fnal.gov (Yossie Silverman) (02/26/91)

I think I have found a bug in SFPGetfile.  Maybe not.  Anyway, it seems 
that the FileFilter function-loop is being called BEFORE the -1 DlogHook 
call.  What this means is that if the DlogHook wants to initialize some 
flags to be used by the FileFilter function, it can't.  Reading through 
the TechNote on the subject (47?) it would seem that this should work, but 
it doesn't.  Either that, or I am doing something very wrong, but I don't 
think so.  This is under System 6.0.7 by the way.  Comments?  - Yossie



---

yossie@fnal.fnal.gov; yossie@fnccf.bitnet
What did the Caspian Sea? - Saki