How to programmatically fight with WPS:.CLASSINFO, 90 sec delay, DEFAULTVIEW
After deleting the CLASSINFO EA did you reboot, or at least restart the WPS?
The WPS only looks at this EA when it "awakens" an object (typically, when you open the folder containing the object); thereafter, it uses its in-memory copy of this info. Restarting the WPS clears this.
OTOH, If you close the folder in question, and you don't have anything open in tree-view which includes this folder, the WPS will put the objects to sleep after about 90 seconds (i.e. it will remove them from memory). With the CLASSINFO gone and no memory of the objects' previous settings, the WPS should use the association currently in force.
If you're in a hurry <g>, use this (see Open View IDs for 4096) in Boilerspace template:
call ReportRC(SysSetObjectData(object,"DEFAULTVIEW=4096;"))
Sample script to set .TYPE and .CLASSINFO
I want to change all files with an extension of jar files to TSZipMgr so that jar files can be opened by the OD Zip Manager. [snip] I'll come up with a REXX script that will perform at least part of the work.
Paste or drag the following into a file named jarz.cmd, then drop objects on it or use it from a command line. Your jar files should change class when you restart the WPS. It may happen sooner if the folder containing the objects is closed for about 2 minutes. YMMV.
/*****************************************************************/
/* JARZ.CMD */
/* (C) Copyright R L Walsh 1999 - All Rights Reserved */
/* */
/* JARZ resets .JAR .ZIP, and optionally .EXE files' */
/* filetype to "ZIP File" and deletes their WPS class data. */
/* */
/* Each file should become an instance of whatever WPS class */
/* handles ZIP Files (a reboot may be needed). It may also */
/* become associated with programs that handle this file type. */
/* */
/*****************************************************************/
/* DATA */
/*****************************************************************/
/* the list of acceptable extensions; ext.0 sets the "last" */
/* item in the list (e.g. '2' excludes EXEs, '3' includes them */
ext.0 = 2
ext.1 = '.jar'
ext.2 = '.zip'
ext.3 = '.exe'
/* The Curr one 8 data EA */
/* EA: MVMT CP item ACSI chars value */
typeval = 'DFFF 0000 0100 FDFF 0800'X || 'ZIP File'
/*****************************************************************/
/* CODE */
/*****************************************************************/
parse upper arg junk
junk = strip(junk)
if (junk = | junk = '?' | junk = '/?' | junk = '/HELP') then
do
say
say ' JARZ resets .JAR .ZIP, and (optionally) .EXE files' || "'"
say ' filetype to "ZIP File" and deletes their WPS class data.'
say
say ' JARZ filespec [filespec [...]]'
say
say ' filespec = file name (wildcards OK), or'
say ' = directory name (no wildcards)'
say
say ' See the comments in jarz.cmd for additional info.'
exit
end
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs
/* the big loop that's executed for each file spec */
do while junk \=
/* deal with quoted names, then clean up string */
if left(junk, 1) = '"' then
parse var junk '"' filespec '" ' junk
else
parse var junk filespec junk
filespec = strip(filespec)
filespec = strip(filespec,,'"')
if filespec = then
iterate
/* rustle up some files */
/* note: SaySFTErr performs an exit so it never returns */
rc = SysFileTree(filespec,'file','FO')
if rc \= 0 then
call SaySFTErr
/* if that didn't work, see if the filespec is a directory */
if file.0 = 0 then
do
rc = SysFileTree(filespec,'file','DO')
if rc \= 0 then
call SaySFTErr
/* if we didn't get exactly one dir back, make this a no-op */
/* else get a list of all files in this dir */
if file.0 \= 1 then
file.0 = 0
else
do
filespec = file.1 || '\*.*'
rc = SysFileTree(filespec,'file','FO')
if rc \= 0 then
call SaySFTErr
end
end
/* for each file, see if it's extension is on the list */
/* if so, have DueDamage change its EAs */
ctr = 0
do i=1 to file.0
do j=1 to ext.0
if right(file.i,4) = ext.j then
do
call DueDamage
ctr = ctr + 1
leave
end
end
end
say ctr 'files processed for <' || filespec || '>'
end
/* bottom of the big loop */
say 'Exiting'
exit
/*****************************************************************/
DueDamage:
/* write a null value for .CLASSINFO */
rc = SysPutEA(file.i,'.CLASSINFO',)
if rc \= 0 then
err = 'removing .CLASSINFO'
else
/* write new value for .TYPE */
do
rc = SysPutEA(file.i,'.TYPE',typeval)
if rc \= 0 then
err = 'resetting .TYPE'
end
/* display either the filename or an error message */
if rc = 0 then
say Filespec('name',file.i)
else
say 'Error #' rc err 'for file' Filespec('name',file.i)
return
/*****************************************************************/
SaySFTErr:
say 'Error #' rc 'in SYSFILETREE for <' || filespec ||'>'
say 'Exiting'
exit
/*****************************************************************/
Effects of lost EA
You're right, the problem is the EAs - but why they aren't copied onto a floppy is beyond me. Bad news: you've lost 2 EAs. Good news: you can recover the one that counts and gain some functionality.
.CLASSINFO this identifies the file as a WebEx_Url to WPS. Unlike most file-based classes, WebEx_Url doesn't reconstruct this, so when it's gone, it's gone. No big loss: you've lost the icon and special notebook.
.TYPE this is set on the first page of a standard datafile's notebook and is what the WebEx app uses to identify URLs. Set your copied files to type 'WebExplorer_Url' and they'll become acceptable to WebEx. Open WebEx's notebook and associate it with objects of this type. They'll get WebEx's icon and open WebEx when you double-click on them.
The EAs for *most* files are completely superfluous. The exceptions are those files which need their EAs to be recognized as belonging to a specialized WPS class or to be given special handling by an app. This usually applies to files without a distinguishing file extension. In these cases, the WPS relies on their .TYPE or .CLASSINFO EAs.
A good example is a URL object: see URL objects. (Effectively, different programs use .TYPE or .CLASSINFO EA to distinguish the URLs objects from data files.)
FYI... The WPS uses a file's extension or filetype to assign it to a class only if it lacks a .CLASSINFO EA. Once it has acquired this (typically by opening the object's Properties notebook), the extension or type no longer matters and can be changed or deleted without affecting the file's class assignment.
For folders, the only EA that really matters is .CLASSINFO, and then, primarily for folders in your Desktop tree. Folders such as Desktop, Templates, and Nowhere only possess special properties because their CLASSINFO EA identifies them as belonging to a specialized class. Loss of their .CLASSINFO will cause serious system disruption.
Some of your Desktop folders may be generic WPFolder objects, but their .CLASSINFO contains their Object ID which the system may rely upon. Since the Object IDs are also stored in os2.ini, loss of these EAs isn't that critical. Checkini will identify the problem and fix it. For all other folders, all you'll lose is your customizations such as sort order, icon positioning, etc.
Miscellanea: If you have files or folders with longnames on a FAT drive, you'll lose the name when the .LONGNAME EA is stripped. On any file system, titles that include illegal file characters like linefeeds or backslashes will be lost. When restored, the titles will match the file or folder's real name and have exclamation points where the illegal characters were.
A very few exe's will lose their icons when their .ICON EA is removed. In most cases, the WPS can look in the file to get the icon, but in some cases this fails. Other than this, you can safely strip the EAs from your application files and never notice the difference.
In those cases where the EAs _are_ critical, use EAUTIL to strip them before backup and to restore them when you return the files and directories to use. Better yet, use backup and restore products that were designed for OS/2. If all else fails, use Info-zip, then backup the zips.
Menu items
So you're saying there's no way to do what I want to do? Those menu items have to be stored SOMEWHERE. Even if I can't use a standard API, there's got to be a way to add these menu items. Are they part of the EA's for the Desktop folder?
Yes they are. They are stored in the .CLASSINFO ea.
As I recall well, there has been a beta toolkit for Warp 3 that even included the syntax for adding menus to objects of WPFileSystem or derived classes. Unfortunately, this vanished again in the non-beta version. It didn't work anyway....
Theoretically, you could alter the .CLASSINFO EA, but I am not sure you will be able to keep the changes since the WPS tends to overwrite this EA on shutdown.
I can tell you where exactly it is stored. Should you want this, please first download my 'icontool' from my homepage since this will help you is understanding what I mean.
Still I wouldn't advise you to do this...
Henk Kelder