Path: utzoo!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!cornell!llenroc!batcomputer!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!billw
From: billw@hpcvra.cv.hp.com. (William C Wickes)
Newsgroups: comp.sys.handhelds
Subject: Re: IFERR Problem.
Message-ID: <25590124@hpcvra.cv.hp.com.>
Date: 14 Mar 91 00:57:05 GMT
References: <27dd8a16:2405comp.sys.handhelds@hpcvbbs.UUCP>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 22

Kevin Vashi writes:

> If you have created programs that have the IFERR..THEN..END structure
> after the IFERR library is attached then, after unattaching or purging
> the IFERR library leads to the replacement of IFERR structure by 
> XLIB 1793 0 object.

This is not a defect, it's the correct behavior.  When you remove a library,
the 48 can no longer display by name, or execute, any commands from that 
library.  The best it can do is display the library number and the command
number as XLIB n m.

The confusion here might arise from the use of "IFERR" for the name of the
new structure word, which might suggest that the library somehow modifies
the behavior of the built-in IFERR.  Actually, when you enter a program
containing IFERR, if the library is present it compiles as a (XLIB) reference
to the new version.  External libraries are searched before the internal ones,
so a library can always supersede a built-in command or structure word with
a new one of the same name.

Bill Wickes
HP Corvallis