I don't know if this will make a difference, but you could try changing the path to:
./myExternal.bundle
It really shouldn't make a difference, but that's what I've used before. You can also bury it in a relative folder such as:
./externals/myExternal.bundle
Help me with this. The external that isn't working consistently is "revXML.bundle". The path to my standalone is:
/HD/Folder/myApp.app
The path to the actual engine in the app is:
/HD/Folder/myApp.app/Contents/MacOS/
Which of these folders does "./revXML.bundle" point to? Right now the external is placed in the first path (to the app bundle.) It works okay that way for me, it doesn't work for the client.
The source of my confusion: when we get "the filename of this stack" in an OS X standalone, what is returned is the second path, the one that points to the MacOS folder. Apparently externals account automatically for the OS X bundle structure, assuming a relative path to the app bundle, whereas "the filename" does not. Is that correct?
Finally, one last technique. Create an external "library" stack, set the externals property of that stack, and "start using" the library stack. This gives you finer control of when the external is actually loaded. It's also nice because you can still make changes to the library stack without rebuilding the standalone, including wrappers to external calls, etc.
Thanks, that's a neat idea. It isn't practical for this project, but I'll keep it in mind.
When the external isn't working, what do you find when you query the "externalFunctions" property? Do you get "Valentina" in the list?
With the stack version, I get nothing; the result is empty. The externalCommands also returns empty. Checking the externals property returns "revXML.bundle". I'll need to create a debugging version of the standalone and send it off to the client to see what he gets there.
Also, is there any way you could be changing the current directory before the external is loaded (which I think is impossible unless you use "start using", but alas...)? Reason I ask is because the external property is a relative path. You might try outputting the current directory when the external is not working, and see if it is something other than the path to the application.
Good idea, I'll put this into my test standalone too. But this does explain the variability I'm getting in my stack copy. I was changing the directory sometimes before opening the stack itself. So that part of the mystery is partially solved, but there are still two questions:
1. When running the stack: I thought that externals always loaded from a path relative to the engine, not a path relative to the stack. However, there is a copy of revXML.bundle stuck in the same folder with the engine and it doesn't load if I've changed the directory, so that must not be right. On the other hand, if I specifically set the directory to that of my stack, and in that directory there also exists a copy of "revXML.bundle", and then I open the stack, the external still does not load. So it must involve more than just a relative path to the stack. It seems that it will only work if the directory is set to the same folder as the engine, and the externals path is relative to that. Does that sound right?
2. When running the standalone application: if I understand it right, the directory can not be changed, because the external will load immediately when the application (and therefore the mainstack) opens. My standalone puts no other stacks in use and has no scripts that change the directory until after the standalone is open (it does change the directory in an opencard handler, but the external should have loaded by then, right?) Also, the standalone works fine on my machine, but not on the client's machine, where it is installed into an identical folder structure (which is pretty much what has me stumped.) So, when exactly does the external load? On openstack? Preopenstack? After all pending handlers are done?
Also, do you know of any third-party stuff or background processes that might interfere with having the external load? That's the only thing I can think of that might be different between my machine and the client's.
Hope something there helps!
Well, I think we're getting closer, at any rate. I appreciate your response.
-- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
