WARNING: -------- This section details some internal implementation details of iffparse.library which may help you to understand it better. Use of the following information to do "clever" things in an application is forbidden and unsupportable. Don't even think about it. It turns out that StoredProperties, CollectionItems, and entry and exit handlers are all implemented using LCIs. For example, when you call FindProp(), you are actually calling a front-end to FindLocalItem(). The mysterious identification value (which has heretofore never been discussed) is a value which permits you to differentiate between LCIs having the same type and ID. For instance, suppose you called PropChunk(), asking it to store an ILBM BMHD. PropChunk() will install an entry handler in the form of an LCI, having type equal to `ILBM', ID equal to `BMHD', and an identification value of IFFLCI_ENTRYHANDLER. When an ILBM BMHD is encountered, the entry handler is called, and it creates and stores another LCI having type equal to `ILBM', ID equal to `BMHD' and an identification value of IFFLCI_PROP. Thus, when you call FindProp(), it merely calls FindLocalItem() with your type and ID, and supplies IFFLCI_PROP for the identification value. Therefore, handlers, StoredProperties, CollectionItems and your own custom LCIs can never be confused with each other, since they all have unique identification values. Since they are all handled (and searched for) in the same way, they all "override" each other in a consistent way. Just as StoredProperties higher in the context stack will be found and returned before identical ones in lower contexts, so will chunk handlers be found and invoked before ones lower on the context stack (recall FindLocalItem()'s search procedure). This means you can temporarily override a chunk handler by installing an identical handler in a higher context. The handler will persist until the context in which it is stored expires, after which, the original one regains scope.