Thierry, Paul,
Thierry said:
Concerning your recipie from the previous email, it works only in your context.
Pass your stack and your external to someone, and you're stuck again !
Yes, I warned about that and mentioned that a relative file path would
be necessary for portability. My example was very simple, just to show
that the external did work and to get Graham started in the simplest way.
Both of you have brought up the issue of testing externals, and that's
one of the times that you really do need the temp stack method. Loading
on demand repeatedly is required for that. (You're right that Mark
Waddingham made it popular in his newsletter articles, though someone
else first thought of it I think; Ken Ray maybe? I've forgotten.)
Paul said:
I posted a feature suggestion in the forum that you be allowed to leave the
extension off, and have the run-time library automatically add the extension
appropriate to the platform when it loads the extension, so that this would
all be unnecessary.
Originally, way back in the MC days, you could place both file paths
(either relative or absolute) into the externals property and the engine
would load the appropriate one for the current OS. At some point that
stopped working in later MC versions, but that's what I'd really like to
see restored. I used to be able to set the stack externals to this:
foo.dll
foo.bundle
And then I could forget about it. When the stack opened on Mac, the
bundle loaded; on Windows, the dll. In fact, you could put a whole list
of mixed-OS externals in there and the engine would pick out the right
ones and ignore the rest. I haven't tested this in years, maybe it does
work that way again. If not, I wish it would.
Thierry said:
From my little point of view, if the external property was relative to the path
of
the stack instead of the engine. it would be less troublesome....
Yes, that would be ideal. My method for dealing with externals is pretty
simple really. Since I don't write them and I only need to use them, I
can get away with this:
For development work, I load the external into the IDE so it's
available. In the mainstack, I add this short handler and forget about it:
on startup
if the platform = "macos" then
set the externals of this stack to "foo.bundle" -- or any relative path
else
set the externals of this stack to "foo.dll"
end if
end startup
Startup is the only time you can set the externals of a stack and have
it work. The handler will never trigger during development because the
IDE gets the startup message. But when running as a standalone, the
mainstack will get a startup message and the externals get set
correctly. Then I just need to remember to put the external files in the
correct relative location in the standalone folder before shipping.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
