Menu
▾
▴
Re: Issues with plug-in loading within Quesa.
|
From: James W. W. <ja...@wr...> - 2004-10-28 18:39:56
|
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Issues with plug-in loading within
Quesa.</title></head><body>
<div>Peter Michelsen <Pet...@mi...>
wrote:</div>
<div><br></div>
<div>Yes you are right the function call is...
ResolveAliasFile(&theFSSpec, true, &targetIsFolder,
&wasAliased); I had copied the wrong call.</div>
<div><br></div>
<div>But, what exactly goes wrong with this call? Does it show
an alert requesting that a volume be mounted, or what?</div>
<div><br></div>
<div>But luckily this did force me to look in developer.apple.com for
this function. They have list the call as<font face="Lucida Grande">
</font><i>Not
recommended</i></div>
<div><br></div>
<div>I think that's just because it uses an FSSpec. I would not
be opposed to switching to FSRefs, but I don't think we've made an
official decision to drop support for Mac OS 8.</div>
<div><br></div>
<div>I also noticed that there is a call the
FSResolveAliasFilewithMountFlags.</div>
<div><br></div>
<div>If what you need to do is avoid UI, there is an FSSpec-compatible
function ResolveAliasFileWithMountFlags.</div>
<div><br></div>
<div>As I look at this code, I think I see another problem: If
the file was an alias, we should get the file type and creator of the
actual file, not the alias. The type and creator are probably
correct for a normal alias, but not for a symbolic link.</div>
<div><br></div>
<div>As long as we're discussing plugin loading, does anyone know
whether the current system works when Quesa is built as a Mach-o
framework, or do we need to add some sort of Mach-O-CFM glue?</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div> James W. Walker, ScriptPerfection Enterprises, Inc.<br>
<http://www.write-brain.com/></div>
</body>
</html>
|
