How to programmatically fight with WPS:WPObjData and "Hammer and ..." icons
Just curious. Back when I applied FP1 to Warp 4, my e.exe lost its pretty icon due to the ea glitch. I got the icon back from one of my previous files & everything was fine. Now we have FP3. Things have seemed to be golden since the service. Now I notice many of my *.txt files that would normally be associated with e.exe (and still open with it) have a new icon consisting of a rather drab looking screwdriver and hammer. Is my system secretly trying to make me feel more like a man or is this something to worry about? TIA.
These files have been sucked up by the WPObjData class which is an adjunct to the Feature Installer (WPInstall). Apparently, the people who are writing these WPS classes don't know how the WPS works. The files WPObjData creates are supposed to be of type "Plain Text". However, the way they wrote it, *any* Plain Text file becomes an instance of WPObjData if it isn't already classified as a WPDataFile. Your best bet is to deregister WPObjData using this REXX script, then restart the WPS.
Put this in Boilerspace template:
call ReportRC(SysDeregisterObjectClass("WPObjData"))
Finally fixed!
You'll be pleased to know that IBM *has* finally addressed the problem: the version of WPObjData that comes with WSeB no longer exhibits this obnoxious behavior. Let's see... I first posted the script Tim cites on Sept 20, 1997 and the fixed version of objdata.dll is dated April 5, 1999. So, it only took 19+ months to correct - pretty good for "them" <g>.
FYI... You may want to read my article in os2ezine, _Using That Hammer and Screwdriver_ (http://www.os2ezine.com/v3n07/hammer.htm), for a way to both tame WPObjData and to put it to work doing something useful.
WPInstall not registered
My guess is that the WPInstall class isn't registered. You should be able to restore it by installing the latest Feature Installer, or by using the following script (I assume you have an INSTALL.DLL in C:\OS2\DLL). Put this in Boilerspace template:
/* REXX script to reregister the WPInstall class*/
rc = SysDeregisterObjectClass("WPInstall")
call ReportRC(SysRegisterObjectClass("WPInstall","C:\OS2\DLL\INSTALL.DLL"))
Data File:1 and NODELETE
gobbled up a template and then everything froze. CAD brought me back and the template had been deleted and the entry had been removed from the ini (not by me).
This needn't be so difficult. You either have, or can have, an object that will make other objects deletable. If you're running Warp 3 or 4.0 and have installed Feature Installer, you probably have a template labeled "Data File:1" whose icon shows a hammer & screwdriver. If running MCP or eCS, you have the required DLL but the WPS class it contains (WPObjData) is not yet registered. Once this is set up, you'll be able to drop most any object on your ObjData icon to restore the Delete option to its menu. And, your system will not freeze up (well, it certainly shouldn't...).
If you don't have the "hammer & screwdriver" template, register the class using the script below. Doing so will create a new template. While you could create a normal object from the template, you'll probably have little other use for it, so edit the template itself. Drag the template to your editor's icon, press Shift to make it droppable, then drop. The object is actually an empty datafile to which you will add this one line:
NODELETE=NO
Save the file, then try out its template object. Drop something that's undeleteable on it, then pop up the dropped object's menu. There should now be a usable "Delete" entry on it. I've found that some classes will restore their NODELETE flag if you manipulate them or drag them to the shredder, so delete the object ASAP after using your ObjData icon.
FYI... you could use a REXX script to do this for files and directories, but REXX can't operate on abstract objects like Program Objects unless they have an object ID. A WPObjData object will work with any type of object (if a file has its "read-only" or "system" attributes set, you may have to turn these off first).
Put this in Boilerspace template:
/* OBJDATA.DLL _should_ be in your os2\dll directory and */
/* accessible via your LIBPATH statement. If it isn't, */
/* it may be in your FISETUP directory; in this case you */
/* must supply the dll's full path & filename, e.g. */
/* SysRegisterObjectClass('WPObjData','E:\FI\FISETUP\objdata.dll') */
/* Be sure to use a file dated June 7, 1999 or later - earlier */
/* versions had a major bug and were a real PITA */
call ReportRC(SysRegisterObjectClass('WPObjData','OBJDATA'))
