User Extensions/Externals

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com