ADC Home > Reference Library > Technical Notes > Legacy Documents > Mac OS 9 & Earlier >

Legacy Documentclose button

Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.

Current information on this Reference Library topic can be found here:

Loading Components Bug

CONTENTS

The Component Manager may change the current resource file in the resource search path. This is a bug and will be fixed as soon as possible.

[Dec 01 1992]






What, Me Worry?

In general, the bug documented here will not be a problem for most applications (Don't worry, be happy), because most of the time the component will already be in memory or doesn't have to be loaded, and most applications leave the resource search path set to the topmost file. Here are a couple of questions to help you understand if this bug pertains to you:

  • Do you use the Component Manager?
  • Do you keep more than one resource file open and change the current resource path (that is, CurResFile)?
  • Do you open components at a time when you depend on the current resource path being set to something other than the topmost file?

If you've said yes to all of the above questions, write a check payable to Jim Reekes for 33 percent of the amount of taxable income declared on your Federal Income Tax statement. Then continue reading this Technote to find out if this bug will byte you. Otherwise, take a vacation, you've been working too hard.

Back to top

Que pasa?

When the call _OpenComponent is made, the Component Manager may need to load the component's code. To load the Component, the component's resource file must be opened and closed. A side effect of this may be to change the top of the Resource Manager's search path. To open the component's resource file, the Component Manager calls _OpenComponentResFile. It then loads the component's code, and calls _CloseComponentResFile. The Resource Manager will set the current resource search path to the top most file, which will be the map that was at the top of the path prior to opening the component.

Figure 1

Figure 1. Resource Search Paths

Back to top

Whatsamatta U?

Figure 1 shows how the resource search path is configured during the course of opening a component. The "before" path shows how the resource search path would look for an application that has opened a resource file and then set the top of the resource search path to be itself. Remember the way the Resource Manager works? The top of the search path is searched first when calling _GetResource, and then, if the resource is not found, the search is continued at the next file down in the search path. If an application is opening resource files, it may wish to avoid inadvertently getting resources from that newly opened file. For example, let's say you have opened a resource file that contains sound resources but your application also has sound resources and you don't want to get the wrong one at the wrong time. So you may wish to protect yourself by setting the search path to begin at the application level to exclude the open resource file above it by using _CurResFile. This way whenever you call _GetResource you'll be sure to only get sound resources from your application.

When a new resource file is opened, by default the resource search path is set to start at this file. This is a good thing. Then when that file is closed, the Resource Manager will set the top of the search path to the next file. This may be a bad thing if you don't want resources to be loaded from this file. This is exactly what is happening when a component is loaded by the Component Manager. The Component Manager may need to load the code resource from the component's resource file. This is the "during" path shown in the Figure 1. Once the code resource has been loaded, the Component Manager will close the resource file. This is the situation shown in the "after" path of the figure.

The lesson to learn is that opening a component may change the current resource search path. You can open a component by calling any component's method. Now you don't need to save and restore the resource path around every component call, but when you use _OpenComponent you should protect yourself. Additionally when you use the Component Manager's trap _OpenComponentResFile it will change the resource search path just like _OpenResFile. So you may wish to preserve the resource search path yourself around this call too. Below is an example of the code you may wish to use:

 oldResFile = CurResFile();
    c = OpenComponent(aComponent)
    UseResFile(oldResFile);

One potential side-effect of this is when you use a component and don't know it. QuickTime, for example, is based on components. QuickTime installs graphic procedures to support _DrawPicture. If a picture contains a compressed image (JPEG, for example), it may cause the image decompression component to be loaded and possibly change the resource search path. If you know you are supporting QuickTime image compressed images using _DrawPicture, you may need to save and restore the resource search path around it.

Back to top

References

Inside Macintosh, Component Manager

Inside Macintosh, Resource Manager

Back to top

Downloadables

Acrobat gif

Acrobat version of this Note (76K).

Download



Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.