On Monday, October 22, 2001, at 03:14 PM, Parent, Marc-Antoine wrote:
> Thanks a lot for the info, Jim.
> Now, we all know better where we stand.
> Let me make sure I got it straight:
> What you are saying is that, even if I invoke the executable directly
> from the CLI while it lives within the .app package, it will inherit
> the .app attributes properly. But invoking a CLI executable from
> without a .app, it will not exist in the Window manager's eye...
I didn't expect that, but it seems to be the case...
> Does this have anything to do with the code for finding the resources
> that makes up most of tkMacOSXAppInit.c?
> In particular, suppose I was forced to keep the executable out of a
> .app, could I use this code to tell the application programmatically
> about another location to look for the necessary resources?
> (Or are they resource bits in the file's meta-data, not in the resource
> fork or .app equivalent?)
The bit that is in main won't work, since it is referring to the main
bundle, which if you ain't an app, you ain't got one of. But the
Tk_MacOSXOpenBundleResources will still work.
> (Going the PEF route appeals to me less, for some reason...)
You can have resources in a Mach-O binary, the object file format, and
the presence of a resource fork are orthogonal. But still, the app
package is a better way to go: it is more flexible, since if you want to
stuff random resources into the app package, you don't have to invent a
resource type for them, and resources are, while still supported, not
looked on as kindly as they once were...
>> Ah, I see. If you run this from the console, you will notice
>> that you
>> get an error when you click to bring it to the foreground,
>> which looks
>> SetFrontProcess failed,-600
>> -600 is supposed to mean "unrecognized drag recipient" but really
>> probably just means that we aren't registered as a real app with the
>> Window Server. You can do this either by having the
>> appropriate MacOS
>> resource bits (kind, etc) or by being in an App package. I
>> bet you can
>> even poke these bits in directly, but I don't know how.
>> So... if you were building as a classic Mac Application with
>> a resource
>> fork, you can continue to build that way, and it will work
>> (there are a
>> bunch of Carbon PEF applications, like NewsWatcher and
>> GliderPro that do
>> it this way). Or you can be an app package. But if you don't make
>> yourself known somehow to the Window System, then it won't recognize
>> your existance. The app will still draw & update itself, it
>> just can't
>> be foregrounded. Or at least that is what happened to Wish
>> Shell if I
>> just drag it out of the App package and try to run it somewhere else.
Jim Ingham jingham@...
Developer Tools - gdb
> Tcl-mac mailing list