ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (10/17/90)
I've been writing some HyperCard externals (XCMDs and XFCNs) which need to have associated message strings and dialogs and things. I want these bits of data to be "localizable" via ResEdit or whatever, which tends to rule out embedding them in the code. Obviously, we need a scheme for associating these string, dialog and other resources with the code they belong to. The Resource Manager provides two ways of identifying resources: by name, and by ID number. There is a current scheme for associating owned resources with certain kinds of code resources, based on using reserved ranges of ID numbers. This scheme is extremely limited in a) the kinds of code it applies to, and b) the number of owned resources you're allowed to have. 16-bit ID numbers simply don't give you enough room to expand this scheme in any sensible fashion. The only thing left to do is adopt some convention using resource names. These names can be up to 255 characters long, which should be enough if you set them up carefully... My proposal is to use a "qualification" scheme, where you use the name of the code resource, followed by a name private to that particular piece of code, for identifying the owned resources. You'll need some kind of delimiter for separating the parts of the name: I propose using the colon, as there is already a precedent for the special treatment of this character, in pathnames in the file system. Example: I have a HyperCard 2.0 XCMD which puts up a modeless dialog in its own window. While the window is up, you can get and set several of its properties with the appropriate HyperTalk commands. To make it easier for my XCMD to be adapted for non-English speakers, I would like to keep the list of property names in a 'STR#' resource, and of course define the dialog in a DLOG and DITL resource. Supposing the XCMD is called "Fred" (this is only an example, remember). Then, the STR# resource could be named "Fred:Properties", and the DLOG and DITL could both be called "Fred:Dialog". Additional notes: When copying the external to a different stack, the copying utility would note the name of the external, and then it would have to scan *all* the resources in the source stack, looking for ones with names beginning with (in this case) "Fred:". Potentially slow, I know. The resources are liable to be renumbered to avoid clashes with existing resources in the destination resource file. The copying utility would probably do what Font/DA Mover does now, and check for certain standard resource types which contain embedded references to other resource IDs, and update them accordingly. It may be possible for the code resource to be renamed, so long as the prefix part of the names of its owned resources is updated to match: if I change the name of the XCMD to "Mork", then its owned resources would become "Mork:Properties" and "Mork:Dialog". The part after the colon must *not* be changed. When the code is trying to access its owned resources, it must first find out its own name (in many contexts, code resources can just do a RecoverHandle on themselves followed by a GetResInfo, while HyperCard 2.0 provides a GetXResInfo callback which will do the trick), and use that as a prefix for forming the names of its owned resources. For instance, my XCMD example would take its name, and append a colon and the word "Properties" (this string would be embedded in the code), and then it could do a GetNamedResource to find its property names. If the code has any custom resource types which reference other owned resources, they must do so by name. The name would be just the part after the colon, and the code resource would have to build this into a full name using a similar technique to the one described in the previous paragraph. What do other people think? Do these ideas make sense? Are there any better approaches? Is there anybody else in the world who thinks this is a problem? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 Y-axis fanatics look down on negative numbers.
leonardr@svc.portal.com (Leonard Rosenthol) (10/18/90)
In article <2001.271ca261@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > I've been writing some HyperCard externals (XCMDs and XFCNs) which > need to have associated message strings and dialogs and things. I > want these bits of data to be "localizable" via ResEdit or whatever, > which tends to rule out embedding them in the code. > > Obviously, we need a scheme for associating these string, dialog > and other resources with the code they belong to. > I, for one, have been trying to get Apple to adopt a generic form of 'owned resources' for a long time. XCMD's really brought the issue to light as the need for users to be able to move associated pieces around, as well as dealing with ID clashes is a REAL PROBLEM. > My proposal is to use a "qualification" scheme, where you use > the name of the code resource, followed by a name private to > that particular piece of code, for identifying the owned resources. > You'll need some kind of delimiter for separating the parts of > the name: I propose using the colon, as there is already a precedent > for the special treatment of this character, in pathnames in > the file system. > > [stuff removed to save space] > > Supposing the XCMD is called "Fred" (this is only an example, > remember). Then, the STR# resource could be named "Fred:Properties", > and the DLOG and DITL could both be called "Fred:Dialog". > Not a bad solution, within the current limitations of the Resource Manager. As a 'stop gap' solution it might work - except for the problems as outlined below. > Additional notes: > > [more removed here] > > When the code is trying to access its owned resources, it must > first find out its own name (in many contexts, code resources can > just do a RecoverHandle on themselves followed by a GetResInfo, > while HyperCard 2.0 provides a GetXResInfo callback which will > do the trick), and use that as a prefix for forming the names of > its owned resources. For instance, my XCMD example would take > its name, and append a colon and the word "Properties" (this > string would be embedded in the code), and then it could do > a GetNamedResource to find its property names. > Herein lies the problem. For many of the standard externals, the calling application loads the resource, detaches it from the resource map (either a simple DetachResource, or even HandToHand) and then executes it. Hypercard 1.x, MicroPhone II 3.0 and other XCMD 1.x supporting apps do this, and other types of externals as treated the same (White Knight, 4D, etc.) So if the called piece of code is no longer in the resource map, how does it get it's information to find the others?!? HC 2.0 solves this problem by NOT Detaching it - both for resource management and debugging reasons, and other apps will follow (I hope), but your method requires such a solution and for many apps this may not be an acceptable one. What we really need is Apple to fix the resource manager to provide for some REAL form of owned resources - some form of Resource BNDL if you will. This BNDL can be used by Resource Movers, the calling application and the external itself to find its owned resources. We have been experimenting with such a scheme in house for some work we are doing, and as long as you can get your resource Info, then you can find the BNDL and all seems to work quite nicely. The advantage, or course, of the resource BNDL (needs a new type though) is that there is no reliance on names or numbers, perse, just a reference into the BNDL table. -- Leonard Rosenthol Software Ventures Corp. MicroPhone II Development Team
denbeste@bgsuvax.UUCP (William C. DenBesten) (10/19/90)
In article <2001.271ca261@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > I've been writing some HyperCard externals (XCMDs and XFCNs) which > need to have associated message strings and dialogs and things. I > want these bits of data to be "localizable" via ResEdit or whatever, > which tends to rule out embedding them in the code. > > Obviously, we need a scheme for associating these string, dialog > and other resources with the code they belong to. From article <1990Oct17.173002.13966@svc.portal.com>, by leonardr@svc.portal.com (Leonard Rosenthol): > What we really need is Apple to fix the resource manager to provide > for some REAL form of owned resources - some form of Resource BNDL if you > will. This BNDL can be used by Resource Movers, the calling application > and the external itself to find its owned resources. Currently the 'key' when looking up a resource is ResType + ID. The cleanest suggestion I can come up with would be to change the key to be ResType + ID + Creator. Current calls could default to the creator for the application. A new suite of calls could allow you to specify the creator to use. (for example GetCResource('DLOG',-4000,'MACA')). Only using creators assigned by Apple DTS would eliminate conflicts. This would be significantly less complicated than a BNDL scheme, and would not look like a kludge. Unfortunately, I don't know that this could be made compatable with current resource formats. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet
francis@daisy.uchicago.edu (Francis Stracke) (10/19/90)
In article <6449@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >Currently the 'key' when looking up a resource is ResType + ID. The >cleanest suggestion I can come up with would be to change the key to >be ResType + ID + Creator. Current calls could default to the creator > >This would be significantly less complicated than a BNDL scheme, and >would not look like a kludge. Unfortunately, I don't know that this >could be made compatable with current resource formats. You probably could, by sticking the info into the resource map. This is something that would take Apple's agreement; it would be a system-software change. They would probably be loath to go along with it, since it would be hard to keep it from breaking on old systems that don't understand what the creator ID is doing there. Then again, maybe the resource map is more flexible than I think, & the old systems would just ignore the extra data, being told that the entry was of a particular size. Something to think about: would there be a call to lie about your creator ID? (So that you could stick a resource into a file where another entity could find it as its own) | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | A mathematician is a professional | | francis@zaphod.uchicago.edu | schizophrenic.--Me. |
denbeste@bgsuvax.UUCP (William C. DenBesten) (10/20/90)
In article <6449@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >Currently the 'key' when looking up a resource is ResType + ID. The >cleanest suggestion I can come up with would be to change the key to >be ResType + ID + Creator. Current calls could default to the creator >being the same as the creator for the application. From article <1990Oct19.042621.16644@midway.uchicago.edu>, by francis@daisy.uchicago.edu (Francis Stracke): > You probably could, by sticking the info into the resource map. > This is something that would take Apple's agreement; it would > be a system-software change. They would probably be loath to > go along with it, since it would be hard to keep it from breaking > on old systems that don't understand what the creator ID is doing > there. I wasn't clear, but I do think that Apple should be solving this problem on a 'global' level, rather than individuals on an adhoc basis. I just looked at Inside Macintosh, and it appears that there are 4 bytes in each resource map entry that are reserved for a handle to the resource when it is in memory. This space could probably be converted to hold creator information, and the file would probably look substantially similar, so old systems may have a chance of working. (There may be a problem with the system assuming that there should be zeroes there.) > Something to think about: would there be a call to lie about your > creator ID? (So that you could stick a resource into a file where > another entity could find it as its own) That is precisely what I would expect to be done with it. Desk accessories, xcmds, etc. would look up the information using their 'creator', rather than the application's creator. In this case, the current application would not be the proper creator to use. > > > | Francis Stracke | My opinions are my own. I don't steal them.| > | Department of Mathematics |=============================================| > | University of Chicago | A mathematician is a professional | > | francis@zaphod.uchicago.edu | schizophrenic.--Me. |