Re: [[eSellerateObject alloc] init] causes SIGTRAP
Re: [[eSellerateObject alloc] init] causes SIGTRAP
- Subject: Re: [[eSellerateObject alloc] init] causes SIGTRAP
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 22 May 2005 07:18:55 -0400
on 2005-05-21 4:42 PM, Graham Jones at email@hidden wrote:
> I am scratching my head on this one, but I have found the solution. For
> some reason, even though the "eSellerateEngine_DataFork.rsrc" file was
> showing up in Xcode in the "Resources" group where it should be, it was
> getting renamed in the actual app bundle to myApp.rsrc.
>
> When I copied the "eSellerateEngine_DataFork.rsrc" file directly into the
> package, voila, problem solved.
>
> Can anyone explain to me why Xcode would rename this file? How can I get it
> NOT to rename this file?
It strikes me that you may be mis-diagnosing the problem. If an
eSellerateEngine_DataFork.rsrc file does not appear in your application
bundle, it is most likely because you did not check its Target Membership
checkbox in your Xcode project. Checking that checkbox would cause the file
to be copied automatically, as is, into your application bundle as a
free-standing resource file of the same name. This is the normal way to set
up an eSellerate-enabled application.
The "<MyApp>.rsrc" file you see in your application bundle might hold
various kinds of resources that your Studio application uses, unrelated to
eSellerate, and you therefore presumably would not want to remove it from
your application bundle in any event.
Here is where the "<MyApp>.rsrc" file in your application bundle comes from:
Various kinds of resource source files are normally compiled into a single
"<MyApp>.rsrc" file in an Xcode Build ResourceManager Resources build phase.
That build phase will build a single *.rsrc file from any and all
appropriate source files and install it in your application bundle.
Normally, for example, you would drag one or more AppleScript 'aete' *.r
source files, if your application uses any, to the Build ResourceManager
Resources build phase of your Xcode target (where they would become children
of that build phase), and that build phase would compile all of them into a
single "<MyApp>.rsrc" file in your application bundle.
If you accidentally dragged the eSellerateEngine_DataFork.rsrc file to that
build phase, I imagine that the resources it contains would simply be
incorporated into the "<MyApp>.rsrc" file, as is (since they were already
compiled by eSellerate). There shouldn't be any problem with this. As far as
I know, the resources in the eSellerateEngine_DataFork.rsrc file should work
equally well in a freestanding *.rsrc file in your application bundle or
incorporated into a *.rsrc file having some other name. However, it is
possible that eSellerate hard-coded that file name into its code (which
could explain your nil path error), so in my Cocoa apps I leave it as a
separate *.rsrc file alongside the "<MyApp>.rsrc" file that I generate for
an 'aete' resource.
Nevertheless, this probably isn't what's happening in your application.
Since the original eSellerateEngine_DataFork.rsrc file does not appear in
your application bundle, it has to be because you did not check its Target
Membership checkbox. For that reason, it wasn't copied into your application
bundle, and your application therefore failed at runtime because required
resources were missing or because a required file of that name was missing.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden