soapdog at mac.com
Wed Oct 18 18:43:59 CDT 2006
One useful thing is to include the error report tool in your standalone. You can check it by going to the "bugs" pane in the standalone builder settings, its the last pane. If you allow it to work thru email, then, if there's an error during runtime, this thing will trap it and put in a nice email for you.
This was the only way available for me to debug some stacks I had, for example, it was thru this feature that I learned that some externals, although present in the bundle, were not linked in runtime.
On Wednesday, October 18, 2006, at 11:04AM, kee nethery <kee at kagi.com> wrote:
>I'm using Chip's altSplash system for the apps I build (thanks Chip!)
>and today I ran into something that stumped me for quite some time.
>Maybe it's always been this way but ... when you build a standalone,
>you can have various code sets (XML, Video, etc) either added
>automatically into the standalone based upon the scripts in the
>standalone, or you can specify which code sets you want included into
>your standalone. The default on my development environment switched
>to automatic (it decides based upon the scripts in the standalone)
>and that caused problems.
>My standalone is altSplash and it has very little of the technology
>used in the actual stack that does the real work. So my app worked
>fine on my machine but not at all on other machines. I had to
>recompile the altSplash for that app and tell it to include all the
>technology needed by my actual stack, so that my actual stack would
>have access to that stuff.
>Now it works fine but it was difficult to troubleshoot because when I
>was running from altSplash, I didn't have access to the debugger to
>step through things. And when I did have the debugger, it worked
>fine. Live and learn.
>use-revolution mailing list
>use-revolution at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode