From: Jim I. <ji...@ap...> - 2001-10-22 23:00:52
|
Marc-Antoine, 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... > Interesting! > 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? Not really. > 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... Jim > > Marc-Antoine > >> 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 >> like: >> >> 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 -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer >> > > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |