home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: WPS_PM
/
WPS_PM.zip
/
howtowps.zip
/
howtowps.INF
(
.txt
)
< prev
next >
Wrap
OS/2 Help File
|
2001-12-03
|
68KB
|
1,462 lines
ΓòÉΓòÉΓòÉ 1. About ΓòÉΓòÉΓòÉ
Generated on Tue Dec 4 00:43:31 2001, by perl version 5.00553, pod2ipf version
1.32 with arguments "HOWTO-wps-details.pod" in directory J:/HOWTO.
ΓòÉΓòÉΓòÉ 2. HOWTO-wps-details - how to programmatically fight with WPS ΓòÉΓòÉΓòÉ
HOWTO-wps-details - how to programmatically fight with WPS
SYNOPSIS
DESCRIPTION
TOOLS
- DragText
- Open View IDs
- Boilerspace template
- strip() in REXX for spaces in filenames
.CLASSINFO, 90 sec delay, DEFAULTVIEW
- Sample script to set .TYPE and .CLASSINFO
- Effects of lost EA
- Menu items
PMWP entries in POPUPLOG.OS2
- SHELLEXCEPTIONHANDLER
Lost/broken desktop or broken Templates or Startup
- Order of DESKTOP and <WP_DESKTOP>
- Details on lost desktops
- Startup folder and ObjectID
- Hanging template folder
- can't choose properties of Desktop
- Restoring System Setup or Templates
- ini.rc and SysCreateObject
- Script to recreate all or some lost objects
URL objects
- "Go to URL" action
- URL attribute: a guess
- URL objects
WPObjData and "Hammer and ..." icons
- Finally fixed!
- WPInstall not registered
- Data File:1 and NODELETE
WPVault, x:/NOWHERE, NOTVISIBLE, SHOWALLINTREEVIEW
- x:/NOWHERE and NOTVISIBLE
- SHOWALLINTREEVIEW
- SHOWALLINTREEVIEW and old (Warp 3) folders
- NODELETE and Templates
.HLP not shown in view.exe
Drag & Drop of .dev and printers
Start a VIO window with a changed font size
Desktop background
Properties of the root directory
PM_Workplace:Location
PM_Workplace:Templates
AUTHOR
ΓòÉΓòÉΓòÉ 3. SYNOPSIS ΓòÉΓòÉΓòÉ
View this document as (depending on the format)
perldoc HOWTO-wps-details.pod
view HOWTO-wps-details
Convert from POD to INF as
pod2ipf HOWTO-wps-details.pod >HOWTO-wps-details.ipf
ipfc /INF HOWTO-wps-details.ipf
Go Up
ΓòÉΓòÉΓòÉ 4. DESCRIPTION ΓòÉΓòÉΓòÉ
Programmatic access to WPS is complicated due to several reasons:
Most APIs are accessible only from inside the WPS process (the second
copy of PMSHELL.EXE), or via DSOM/CORBA via remote method call.
To call things from inside the WPS process one needs to "inject" a WPS
class into the system; possible bugs in the object will jeopardize the
WPS integrity, thus the usability of the computer. This makes WPS
classes much harder to design than "ordinary" applications.
The current implementation of DSOM lacks run-time
method-dispatch-by-name, thus one needs to use CORBA (DII) to make
arbitrary method calls from scripts. AFAIK, there is no scripting
solution which uses DII for its operation.
Even with this hard-to-reach API, there is no API to fetch the data which
allows reconstruction of the object state (serialization/deserialization,
marshalling etc). Thus one needs to use undocumented ways to fetch the
object state.
There is a small subset of API (Win*Object* (C) and Sys*Object* (REXX)
API) usable from outside of the WPS process. However, the control
provided by this API is very restricted.
However, some stuff can be done even with such low-grade stuff as plain REXX.
Go Up
ΓòÉΓòÉΓòÉ 5. TOOLS ΓòÉΓòÉΓòÉ
Object REXX injects a class into WPS, so provides a direct access to WPS
objects (with limitations w.r.t. marshalling etc).
REXX without extensions provides access (via and Sys*Object* API) to the
Win*Object* (C) subset of API.
icon.exe (GUI for WPTOOLS.DLL) (by Kelder) among others shows many things:
1/2-decyphered contents of .CLASSINFO
Init strings for objects;
Contents of NOWHERE
Get/Set Object ID, location
WPTOOLS.DLL is also accessible from REXX. Beware: there are tools
which require uncompatible versions of this DLL... WPTOOLS.DLL uses
undocumented hacks to get the object data for EA and .INI files.
ObjectSpy Class, class-DLL, ID, location, class ancessors, icon styles
(no-delete etc), methods, interface.
WP Class list Application Class Tree => create an object of the given class,
(un)replace a class.
RWX Class Tree => metaclass/parent, DLL, Cause?, instance/class methods/datasize.
Object Utility/2 D&D => Class, DLL, object-id, location, get/set style flags
(no-delete etc).
Setup strings list
http://www.os2ezine.com/v3n07/wpsetup.txt
a complete listing of setup strings for common object classes,
along with a list of the values used with.
WPObjData
http://www.os2ezine.com/v3n07/hammer.htm
tame WPObjData _and_ to put it to work doing something useful.
WPSTools:
mo create/modify-by-string-id objects
eo modify by handle
fo create shadows in TARGET by the *-pattern in ./
qo report the handle by the string-id
wplist list classes/dll
wpkill delete class
wpmake add class
Perl has access to Win*Object* API (C) (via OS2::WinObject module). The
module SOM gives access to all the SOM objects and the object
repository, but (currently) only a limited access to DSOM objects (due
to the absense of an interface to DII).
Go Up
ΓòÉΓòÉΓòÉ 5.1. DragText ΓòÉΓòÉΓòÉ
Are you saying I can hilite something that shows up in the VIO window that
CHECKINI runs in, and DragText will locate it elsewhere on the "real" desktop?
Yes - if the object actually exists. I just ran checkini looking for an
example and found two. The first is sort of involved, the second is pretty straightforward.
Example 1:
=================================================
PM_Abstract:Objects & PM_Abstract:FldrContents
=================================================
OBJECTID <WP_TEMPS> (from 32DCB - G:\DESKTOP\ALL\OS!2 SYSTEM\TEMPLATES)
POINTS TO ANOTHER OBJECT 32968 - F:\DESKTOP\ALL\OS!2 System\TEMPLATES
Р╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓п
╨╖ Assign a new OBJECTID to G:\DESKTOP\ALL\OS!2 SYSTEM\TEMPLATES? ╨╖
АОООООООООООООООООООООООООООООООО╢ООООООООООООООООООООООООООООООООЇ
╨╖ YES Γäû NO ╨╖
ΓòÿΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓò¬ΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨╝
Honestly, I wasn't quite sure what this was telling me at first (I was up way
too late last night). I have an FP7 system on "F:" and an FP14 system on "G:".
I was running checkini against F:, so why was it identifying a problem on G:?
Then I remembered: I had (foolishly) opened G:'s Templates Folder while
running F: and had seen the system populate it with shadows of F:'s templates.
This produced a record in F:'s os2.ini describing the contents of G:'s
templates folder (in particular, those shadows).
Trying to make sense of it, I highlighted <WP_TEMPS> in the VIO window where
checkini's output appears. Clicking Ctrl+Shift MB2 caused DragText to pop up
its WPS menu. DT adds the object's name to the menu and puts its full path on
a submenu (selecting either will open whichever folder contains the object).
Checking the path on the submenu confirmed that F:'s <WP_TEMPS> did point to
the folder on F:. I then did the same with the two object handles (32DCB &
32968), just to be sure.
Finally, it dawned on me: when an object is assigned an ID, the info is
stored in PM_Workplace:Location *and* in the object's data (in this case, in
the folder's .CLASSINFO EA). Apparently, whenever checkini encounters an
object whose data contains an Object ID, it cross-references this with the
entry in PM_Workplace:Location.
G:\...\TEMPLATES's EA showed its ID to be <WP_TEMPS>, but PM...:Location said
this was assigned to F:\...\TEMPLATES, so checkini wanted to be "helpful" and
change G:'s ID. Since this ID was perfectly valid when booting G:, and since
my setup on G: would be screwed up if I removed it, I answered "No".
Now, without some of this prior knowledge, DT alone wouldn't have enabled me
to figure this out completely. However, being able to confirm that when booted
to F:, <WP_TEMPS> pointed at the right folder on F:, and knowing that there is
another setup on G: _should_ be enough info to cause any *cautious* user to
answer "No" as well.
Example 2:
Folder : F:\DESKTOP\PRONEWS!2
Object 2E027 , Class WPProgram : Purchase ProNews/2
Exename: E:\PN15B4\PURCHASE.EXE<-UNABLE TO ACCESS! Curdir: E:\PN15B4
Р╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓╓п
╨╖ Remove this object which contains errors? ╨╖
АООООООООООООООООООООО╢ОООООООООООООООООООООЇ
╨╖ YES Γäû NO ╨╖
ΓòÿΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓò¬ΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨╝
I didn't doubt that checkini was correct, but I still wanted to see for myself.
I selected the object handle (2E027), clicked Ctrl+Shift MB2 to display this
program object's menu, then selected 'Properties'. As reported, it pointed at
PURCHASE.EXE. Since this file had been included in previous distributions of
ProNews/2, I decided to check the directory. Again, I used DT to pop up the
menu for E:\PN15B4 and selected 'Open'. Scanning the directory, I found a
PURCHASE.APP but no PURCHASE.EXE. Satisfied that the object was unusable, I
told checkini to delete it. (BTW... this is the only bug I've found in PN
v1.51b4 so far.)
FWIW... Example 1, along with my description in the original article of how I
"lost" G:'s Desktop, suggests that it's a *bad* idea to look at one
installation's standard system folders from another setup on the same machine.
Example 1 also suggests that you're not doing yourself any favors by having it
automatically answer "Yes" to every question. User intervention *is* required
for optimal results!
______________________________________________________________
There is no official way to query the OBJECTID of a given object. However, my
WPTOOLS.DLL does have some functions to do it. WPTOOLS.DLL is part of the
WPTOOLxx.ZIP archive. Please look at: http://www.os2ss.com/information/kelder/
Hmmm. You're right, I misread that, I guess :-( How ' bout this rexx instead:
/* OBJECTID.CMD - Display object ids known to Workplace Shell */
call rxfuncadd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
call sysloadfuncs
call SysIni 'USER', 'PM_Workplace:Location', 'All:', 'ids.'
do i=1 to ids.0
Say ids.i
end
PMFJI... but this is a perfect example of where my favorite DragText feature
(WPS links) would be uncommonly helpful.
Once you have a listing of object IDs, you can use DragText to manipulate them
as though you had a folder full of shadows rather than words in a window. You
can select an ID, then drag the object it refers to, or you can pop up its WPS
menu. DT adds the object's name to the top of the menu and gives it a submenu
that shows the full path. This makes it easy to identify what <PDP_SMARTPFA>
refers to (F:\Desktop\OS!2 System\Problem!!Determination Tools\Hard File Monito
r). Selecting this menu item will take you directly to the named object. Of
course , you can use most of the other menu entries too (Open as, Copy, etc).
You can skip the script if you have an ini editor that uses a listbox to
display its info (most do, regedit2 doesn't). Point it at
PM_Workplace:Location in os2.ini, then select an object ID from the list. And,
if you want skip the script but still have a listing, you can use DT to drag
the entire contents of the listbox to somewhere more convenient - your editor,
a file, etc. Go Up
ΓòÉΓòÉΓòÉ 5.2. Open View IDs ΓòÉΓòÉΓòÉ
from http://www.os2ezine.com/v3n07/wpsetup.txt, same as in Setup strings list:
-1 UNKNOWN
0 DEFAULT
1 CONTENTS (icon view)
2 SETTINGS
3 HELP
4 RUNNING (run pgm; for data files, run associated pgm)
101 TREE (tree view)
102 DETAILS (details view)
120 AUTO (WPDisk objects only)
121 PALETTE (color and font palettes, plus the LaunchPad)
4096 the 1st pgm associated with a data file (usually 1st on its Open menu)
4097 the 2nd pgm associated with a data file (usually 2nd on its Open menu)
etc
5000 the 1st pgm added to a data file's Open menu using the Menu page
5001 the 2nd pgm added via the Menu page
etc
25856 USER (proprietary view IDs start here; USER+1 is most common)
42818 TextView (OD v1.0)
46914 TextView (OD v1.5)
Go Up
ΓòÉΓòÉΓòÉ 5.3. Boilerspace template ΓòÉΓòÉΓòÉ
Change SETVIEW.CMD to the name of your script.
Keep in mind that /* should start the script, dependint on how you copy this
script, you may need to unindent the first line. In view.exe, use
Control-Insert to Copy the contents of this window to a clipboard, then Paste
into your favorite editor.
/* SETVIEW.CMD */
/* drop a file on this script's icon, or */
/* invoke it from the command line passing the filename as an argument */
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs
arg object
arg = strip(object,,'"') /* Spaces in argument => quoted arg */
... Put the code at this place!
exit
ReportRC:
parse arg rc
if rc
then
say "Success"
else
say "Failure"
return
Go Up
ΓòÉΓòÉΓòÉ 5.4. strip() in REXX for spaces in filenames ΓòÉΓòÉΓòÉ
FYI #1... because of limitations in REXX, you can only set the attributes for
abstract objects like program objects or shadows if you have the object's
Object ID (e.g. <WP_OS2WIN> for your OS/2 Window program object). For files
and folders, you can supply the fully qualified name instead.
FYI #2... the "strip" command in my REXX Boilerspace template lets you drop
files whose names contain spaces onto your cmd icon. Without it, these names
will be passed to REXX with surrounding quotes that will cause functions to
fail. Go Up
ΓòÉΓòÉΓòÉ 6. .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;"))
Go Up
ΓòÉΓòÉΓòÉ 6.1. 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
/*****************************************************************/
Go Up
ΓòÉΓòÉΓòÉ 6.2. 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 doubleclick 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. Go Up
ΓòÉΓòÉΓòÉ 6.3. 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 menues to objects of WPFileSystem or derived classes.
Unfortunattely, 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 Go Up
ΓòÉΓòÉΓòÉ 7. PMWP entries in POPUPLOG.OS2 ΓòÉΓòÉΓòÉ
I've been looking at this for quite a while, and have come up with a possible
explanation and a cure that's worse than the disease. AFAIK, the WPS uses
"deferred parameter checking" - IOW, it doesn't check parameters for validity,
it just uses them. If they cause a trap, the WPS's exception handler cleans
up, usually by aborting the current operation. As such, PMWP isn't the "cause"
of the problem, just the unsuspecting victim of bad data. Overall, the system
is working as designed. Go Up
ΓòÉΓòÉΓòÉ 7.1. SHELLEXCEPTIONHANDLER ΓòÉΓòÉΓòÉ
If you're really hell-bent on eliminating this, you can try adding this line to
config.sys:
SET SHELLEXCEPTIONHANDLER=OFF
This turns off the WPS's exception handler, guaranteeing any errors will cause
a crash. It's normally used by developers of WPS classes to keep the WPS from
covering up bugs in their code. (That's why I've pursued this problem so
vigorously: with the exception handler off, I couldn't keep the WPS up long
enough to begin my debugging.) Go Up
ΓòÉΓòÉΓòÉ 8. Lost/broken desktop or broken Templates or Startup ΓòÉΓòÉΓòÉ
Where to begin... How about a warning? The best way to "lose" your Desktop
(without suffering any real damage) is to access one installation's Desktop
from another setup on the same machine. E.g. I installed FP14 on my alternate
setup, then later started looking at its Desktop from my FP7 setup. When I
rebooted to the FP14 system, all I got was a command window on an empty Desktop.
First step: edit config.sys and add this line, then reboot.
SET DESKTOP=C:\DESKTOP
(see Order of DESKTOP and <WP_DESKTOP>). If everything comes back as it should
be, run the following code
call ReportRC(SysSetObjectData("C:\DESKTOP","OBJECTID=<WP_DESKTOP>"))
(put this in Boilerspace template); then "rem-out" the line in config.sys until
the next time it's needed. You need to run the REXX script or else many
installers will be unable to create Desktop objects; you'll want to disable the
config.sys entry so you'll know when a problem has occurred. These two steps
will solve most lost Desktop problems.
After rebooting, if your Desktop returns and all of the folders and files are
present but all of the program objects, shadows, and miscellanea are missing,
then os2sys.ini is probably corrupted. If you have pgm objects or shadows that
point at files on other disks, see if they're still good in order to guage the
extent of the damage. Also, pop up the Desktop menu and select 'System Setup'.
Does the folder open?
At this point, you have several options (see also Script to recreate all or
some lost objects). The best would be to restore a *recent* archive of your
Desktop from the Alt-F1 boot screen. If you were able to open System Setup
from the Desktop menu, you may instead want to restore recent backups of
os2.ini & os2sys.ini, such as those made by checkini. You can either reboot to
a command line and copy them over, or you can edit config.sys and (temporarily)
change SET SYSTEM_INI= and SET USER_INI= to point to them, then reboot. If you
choose the latter option, you can copy & rename the files and reedit config.sys
after you're satisfied with the results.
Lacking recent backups, you still have some options. First run checkini in
diagnostic mode (i.e. *without* the "/C" option). If you weren't able to open
System Setup from the Desktop menu, see if it offers to assign the object ID
<WP_CONFIG> to the System Setup folder (and makes similar offers for other
standard folders as well). This will determine whether you'll be forced to run
MAKEINI. Also, see if it finds valid objects assigned to "missing" folders.
If so, you should be able to recover them when you run it again in "fixit" mode.
If opening System Setup wasn't a problem, or if checkini offered to fix it,
you can rerun checkini with "/C" to recover as much as possible. Avoid letting
it delete anything and skip the final filehandles check altogether. After a
reboot, see how things look. You may have to drag a lot of recovered objects
back to their proper folders, and some things may still be screwed up. By not
deleting anything on the first run, you may have invalid program objects but at
least you'll know what you used to have and what needs fixing. When things are
back to normal, then run checkini again and let it do all the cleanup still required.
My repeated mention of opening System Setup from the Desktop menu is simply a
quick way to see if the standard folders have the object IDs they need for a
properly functioning system. If they don't, then you probably have other
problems as well that need fixing. For this you'll want to run a
*non-destructive* MAKEINI with this command line (after making a backup):
MAKEINI OS2.INI INI.RC
Before doing so, you may want to customize INI.RC and eliminate or comment-out
things you don't want (e.g. all those tired URL objects, or, at the end of the
file, the 3 lines that will reset your display to VGA).
When you reboot, the WPS will create a new Desktop with all new folders and
objects, and will rename your current (defective) one as Previous Desktop.
After another reboot (just in case), run checkini and see what it can recover
(in this case, let it remove any duplicate object IDs it finds from the
previous Desktop's objects). Chances are that you'll have to drag a lot of
things from the old desktop to the new.
When this long ordeal is finally over, you can delete the previous or
temporary Desktop folder(s). Because they have the NODELETE style, you'll have
to get rid of this before 'Delete' appears on their menus. One way is to plug
this into the Boilerspace template):
rc = SysSetObjectData( "C:\PREVIOUS DESKTOP","NODELETE=NO")
Except for a few details here and there, AFAIK, that about covers it. Did I
answer your question, Barbara?
BTW... since I haven't plugged DragText yet, I should mention that it can be a
handy adjunct when dealing with these problems, e.g., validating required
object IDs (as found in INI.RC), accessing & examining objects as checkini
finds them (via the numeric object handles it displays for each), etc. See
DragText. Go Up
ΓòÉΓòÉΓòÉ 8.1. Order of DESKTOP and <WP_DESKTOP> ΓòÉΓòÉΓòÉ
If D:\DESKTOP does exist and your config.sys says SET DESKTOP=D:\DESKTOP, the
WPS will attempt to use it. If that directory doesn't exist, of course you're
going to have problems.
If this line is not in config.sys, the WPS will try to locate the Desktop
using os2.ini info. If that info is missing, you'll have your current problem.
Use the following REXX script to restore the info to os2.ini. Just be sure
that it points to your current, *valid* Desktop path (and don't forget to
delete the "set desktop=" line in config.sys). Go Up
ΓòÉΓòÉΓòÉ 8.2. Details on lost desktops ΓòÉΓòÉΓòÉ
[More on Lost/broken desktop or broken Templates or Startup.]
This problem comes in two flavors: "plain vanilla" and "rocky road".
First, restore the backup ini files (even though they didn't work last time).
In config.sys, add "SET DESKTOP=E:\DESKTOP", then reboot. This will point PM
at your original Desktop directory. If all your program objects, shadows, and
other non-filesystem objects reappear, you had the "plain vanilla" problem.
All you need to do now is run the REXX script below.
OTOH, if only files and folders reappear and/or you get unexpected objects in
unexpected places, you've got "rocky road". In this case, consider yourself
lucky if you can recover any of your old setup. If you don't already have it,
get wptool19.zip so you can run checkini.exe. The first time you run it, you
may want to omit the "/C" command line parameter so that it only reports errors
and doesn't try to fix them.
The first time you have it try to fix things, your primary goal is to have it
recover objects that it says are located in non-existent directories. Say 'no'
to most offers to fix other problems. After a reboot, your Desktop will be
filled with folders full of found objects. Retrieve and fix your own objects
but skip system-supplied ones. Things will be so messed up that you'd do well
to run a nondestructive MAKEINI to recreate your System Setup, Startup, etc.
folders and the objects therein (see Startup folder and ObjectID, Hanging
template folder, Restoring System Setup or Templates, ini.rc and
SysCreateObject, Script to recreate all or some lost objects). After that's
done (and you've rebooted yet again), run checkini again to clean up the mess
that remains.
FYI... the "plain vanilla" problem is common and easy to fix: the Desktop
folder's Object ID (i.e. <WP_DESKTOP>) has disappeared, so the WPS can't find
it. The REXX line in Lost/broken desktop or broken Templates or Startup
restores it. The "rocky road" problem is semi-catastrophic: the file handles
table in os2sys.ini got lost/corrupted and the system assigned all new handles
to the files and folders on your E: drive. The WPS uses these handles to
associate abstract (i.e. non- filesystem) objects with particular folders. Now
that the folders' handles have changed, your abstract objects are no longer
associated with any folder, so they're in limbo. Checkini will fix this by
associating these objects with new folders it creates. Go Up
ΓòÉΓòÉΓòÉ 8.3. Startup folder and ObjectID ΓòÉΓòÉΓòÉ
To actually do anything, your Startup folder must be of class WPStartup and
have the object ID "<WP_START>".
For future reference... Chances are that this Startup folder had lost either
its ObjectID ("<WP_START>") or its .CLASSINFO extended attribute. ObjectID is
easy to fix: use SysSetObjectData in a REXX script to restore it. Losing the
EA that tells the WPS that this is a Startup folder renders it useless, so you
have to create a new Startup folder. If you search \os2\ini.rc, you'll find
any entry for this folder that contains all the parameters you'll need to
recreate it using SysCreateObject. Note that the parms are *not* listed in the
order that SysCreateObject requires, so you'll have to do some transposition.
See ini.rc and SysCreateObject, Script to recreate all or some lost objects.
Go Up
ΓòÉΓòÉΓòÉ 8.4. Hanging template folder ΓòÉΓòÉΓòÉ
More than likely, there's some invalid object in there which is causing the
hang - perhaps a template for some object class you've deregistered. Here's a
list of steps you can take to fix things, starting with the most benign:
run checkini.
No comment necessary :-)
delete the Templates Folder's .ICONPOS EA
I've seen invalid entries or references to nonexistent classes in here
cause stuff to disappear
delete "PM_Workplace:Templates" from os2.ini
This provides the list of options on the Create Another submenu; it will
be rebuilt as the WPS rediscovers your templates.
delete the contents of Templates
Obviously not an option here since you can't access them. It's worth
noting that any class that provides a template will recreate it on demand
- only the ones that are customized or "variations on a theme" will be
lost. If you do this, be sure to delete "PM_Workplace:Templates" from
os2.ini afterwards.
delete the Templates Folder, then recreate it
- Before doing so, use your filemanager to move any customized
file templates to another directory. For example, Lotus
WordPro has a subfolder in there filled with specialized
templates that will be lost otherwise. The best place to put
them is a folder deep in your directory tree where neither it
nor it parent is likely to be accessed.
- After saving what you want, delete the remaining files and
directories, then delete the Templates folder itself. I
don't know if you'll be able to do this while the WPS is
running. Regardless, avoid accessing both Templates and
whatever folder it's in during the session you do all this.
- Delete "PM_Workplace:Templates" from os2.ini.
- Kill the WPS or reboot, then run this script to recreate
Templates (the SysCreateObject call should all be on one
line):
/* script to recreate the TEMPLATEs folder */
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs
rc = SysCreateObject( "WPTemplates", "Templates", "<WP_OS2SYS>",
"HELPPANEL=15680;NODELETE=YES;OBJECTID=<WP_TEMPS>", "UPDATE")
(compare with Restoring System Setup or Templates).
- Finally, open your new Templates folder. There should be a
lot of activity as the WPS recreates all of the standard
templates. Return any templates you saved *and* open every
folder you know contains templates (this will repopulate
"PM_Workplace:Templates" and your Create Another menus).
A final note: if you've installed Feature Installer, you probably have a
template labelled Data File:1 that shows a hammer and screwdriver. Then see
Data File:1 and NODELETE.
You can put this to good use if you want to delete undeletable templates.
Open this file in a text editor (you can Shift-drag its icon to your editor's
icon, then Shift-drop it). Add this single line (without quotes), then save
the file:
"NODELETE=NO"
Whenever you need to delete an undeleteable template, just drop it on this
template. The dropped object will now have a Delete entry on its popup menu
and can be deleted in any of the usual ways. Go Up
ΓòÉΓòÉΓòÉ 8.5. can't choose properties of Desktop ΓòÉΓòÉΓòÉ
When I press RMB on the desktop I can't choose properties. Does anyone
know the reason? I used to be able to choose it. I have installed FP1
and FP3 on my Warp 4.
When you say you "can't choose properties", do you mean:
- that entry is missing from the menu?
- the entry is present but disabled (grayed-out)?
- you can select Properties but nothing happens?
I'm sorry... The properties entry is missing from the menu.
OK... Have you recently installed any WPS "enhancements", or more likely, any
WPS security add-ons that are designed to keep users from changing things? If
not, try the following REXX script. Either drop your Desktop folder icon on
it, or run it from the command line supplying the path of your Desktop folder
as an argument (i.e. settings c:\desktop ).
Put this in Boilerspace template:
call ReportRC(SysSetObjectData(object,"NOSETTINGS=NO"))
Go Up
ΓòÉΓòÉΓòÉ 8.6. Restoring System Setup or Templates ΓòÉΓòÉΓòÉ
The desktop pop-up menu which displays the System Setup line to show the
particular folder is still there, but doesn't bring up the folder. System setup
itself is in the OS/2 system folder and is still there.
Can anyone tell me how to "re-activate" the System Setup line in the pop up menu?
I hope I'm not too late and you haven't done a reinstall... Try this (Put
this in Boilerspace template):
call ReportRC(SysSetObjectData("F:\Desktop\OS!2 System\System Setup","OBJECTID=<WP_CONFIG>"))
Similarly for templates:
call ReportRC(SysSetObjectData("F:\Desktop\OS!2 System\Templates","OBJECTID=<WP_TEMPS>"))
Go Up
ΓòÉΓòÉΓòÉ 8.7. ini.rc and SysCreateObject ΓòÉΓòÉΓòÉ
Whenever you damge or destroy a system-supplied object, go to \os2\ini.rc, find
the entry for the object, then reformat the parameters for use with the REXX
SysCreateObject command. In this case, the line from ini.rc is:
"PM_InstallObject" "Drives;WPDrives;<WP_CONNECTIONSFOLDER>;RELOCATE"
"ALWAYSSORT=YES;NODELETE=YES;DEFAULTVIEW=ICON;OBJECTID=<WP_DRIVES>"
Below is a REXX script that uses these parms. Note that neither
"PM_InstallObject" nor "RELOCATE" are applicable in a REXX script. OTOH, the
"REPLACE" parameter included below is REXX-specific; it is documented in your
online REXX ref. (N.B. this is for Warp v4; for v3, change
<WP_CONNECTIONSFOLDER> to <WP_OS2SYS>)
Put this in Boilerspace template, SysCreateObject() call should be all on the
same line:
/* REXX script to recreate the Drives folder*/
call ReportRC(SysCreateObject("WPDrives", "Drives", "<WP_CONNECTIONSFOLDER>",
"ALWAYSSORT=YES;NODELETE=YES;DEFAULTVIEW=ICON;OBJECTID=<WP_DRIVES>",
"REPLACE"))
Go Up
ΓòÉΓòÉΓòÉ 8.8. Script to recreate all or some lost objects ΓòÉΓòÉΓòÉ
/* ReCreate.CMD - restore lost desktop objects */
/* by Greg Czaja - July 29, 1992 */
/* - April 9, 1993 ver.2 */
/* handle 2.1-style INI.RC */
/* the July 1992 REXXUTIL version is required for 2.0 GA */
/* (look for REXX20 in Lib 17 in OS2SUPPORT) */
/* no additional requirements for GA+SP or 2.1 */
Call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
Call SysLoadFuncs;
SysBootDrive=Filespec('Drive',Value('SYSTEM_INI',,'OS2ENVIRONMENT'));
file_name=SysBootDrive||'\OS2\INI.RC';
Say "The program will list all single standard objects from your desktop"
Say "Reply Y(es) if you want recreate the listed object - E(nd) to end the program"
Say "N(o) is the default if you press ENTER:"
Do While Lines(file_name) > 0;
line=Linein(file_name);
If line='' Then Iterate; /* skip blanks */
Parse Var line '"PM_InstallObject"' line;
If line='' Then Iterate; /* skip others */
Parse Var line '"'head'" 'line; /* get header */
Parse Var line '"'setup'"' .; /* get setup string */
Parse Var head title';'object';'location';' . ;
Say title "- Yes/No/End ?";
Pull reply ;
If Left(reply,1) ='E' Then Leave;
If Left(reply,1) <> 'Y' Then Iterate;
If SysCreateObject(object,title,location,setup,'Update') = 0
Then Say 'Error creating:' title;
Else Say title 'created !';
End;
rc=Stream(file_name,'C','Close');
Return 0 /* enjoy your desktop! */
/*
Did you delete your Command Prompts ? Shredded your Shredder ?
This program restores the standard WPS desktop objects on 2.x.
It will preserve any current settings/objects you may have created and this
is its advantage over the Alt-F1 or MAKEINI method.
You will need the latest REXX fixes (REXX20 available in library 17) to make
it run correctly on 2.0 GA system, no fixes required on GA+SP or 2.1.
*/
Go Up
ΓòÉΓòÉΓòÉ 9. URL objects ΓòÉΓòÉΓòÉ
URL objects
"Go to URL" action
URL attribute: a guess
URL objects
Go Up
ΓòÉΓòÉΓòÉ 9.1. "Go to URL" action ΓòÉΓòÉΓòÉ
Can anybody explain me how to permanently set the "Go to URL" action on the
"open" menu of the URL object?
You can't under Warp v3.0. The WebEx class explicitly resets the default view
each time a WebEx object is "awakened" (made visible when the folder it's in is
opened). I know this for a fact because the code outputs this debugging
message:
**WebExplorer:wpObjectReady(): wpSetDefaultView succeeded
Your only option under v3.0 is to use an EA editor to delete the .CLASSINFO
extended attribute. Then the file will no longer be a WebExplorer_Url object
and can be associated with WebEx (or rather, WebEx can be associated with files
of type WebExplorer_Url). The file can still be dropped on WebEx to load the
Url - WebEx looks at the type, not the object class, to determine whether
you're dropping a Url or a file. (Confused? See URL objects.)
Under Warp v4.0 (Merlin), you won't have this problem because the new wpUrl
class doesn't mess with your choice of default open actions. However, AFAIK,
you will have to manually change each old WebEx object to open the browser you
choose. Go Up
ΓòÉΓòÉΓòÉ 9.2. URL attribute: a guess ΓòÉΓòÉΓòÉ
I think that this has to do with how the URL attribute is stored. Rather and an
EA, I think that it is an ini file thing <sigh>. I found that object desktop's
package system will work to transport URLs, or you can use a REXX program to
rewrite 'em as webx URLs.
[Does URL objects refute this?] Go Up
ΓòÉΓòÉΓòÉ 9.3. URL objects ΓòÉΓòÉΓòÉ
The WPS uses its .TYPE EA of "UniformResourceLocator" to assign it to the WPUrl
class while NS/2 uses the EA to identify its special function. Without this
EA, URL objects will revert to plain-text files when copied back into your
system. You will have to reassign them a type to restore their functionality.
Some file objects belong to a particular class solely because their CLASSINFO
EA says so. Warp 3's WebExplorer_Url class is an example. Even though these
files have a .TYPE EA of "WebExplorer_Url" for NS/2's benefit, this class
wasn't written to associate the type with the class. These files had to be
explicitly created as "objects" (which always results in a .CLASSINFO EA) in
order to belong to the WebExplorer_Url class. Stripped of their .CLASSINFO
EAs, WebExUrls will also revert to plain-text files and you won't be able to
restore them.
There's a frequent fundamental misunderstanding of what WebEx Url objects
really are. They are nothing but files whose .TYPE EA is "WebExplorer_Url ".
While WebEx and other apps may use PM's WPS interface calls to create them,
WebEx itself is wholely ignorant of their object wrapper when it comes time to
read them. As long as the app that originates a drag action identifies the
file being dragged as a WebExplorer_Url, WebEx will be happy to accept and read
it. The WPS need not even be loaded.
In Merlin, these files have become "WPUrl" objects and may or may not have the
WebExplorer_Url .TYPE EA. However, the WPS still identifies them as such
during a drag to keep WebEx happy. (Unlike the WebExUrl class, Merlin's WPUrl
class is automatically associated with any file having this .TYPE EA.)
Here's an experiment or two to demonstrate the above: - use EPM (or any editor
that doesn't add a Ctrl-Z to the end of a file) to create a file with a valid
URL. After saving it, open the file's settings notebook, delete any Current
Types, and add WebExplorer_Url from the list of Available Types. Now drag and
drop the file on WebEx. The URL will be loaded, even though it isn't a
"WebExplorer_Url" object. - start Merlin, then look at the file's Object Class
in a Details view of its folder. You'll see that it's WPUrl. Open its
properties notebook: it should be that of a Url object. If it isn't, you'll
have to use the "Become" tab to make it one; after a restart, it will belong
to the WPUrl class.
BTW... *no* WPS objects are "EAs hanging off the directory". If an object is
filesystem-based, it has its own .CLASSINFO EA that is used by the WPS. If the
object is abstract (like a Program reference object), the classinfo is stored
in OS2.INI. Go Up
ΓòÉΓòÉΓòÉ 10. 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 screw-driver 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"))
Go Up
ΓòÉΓòÉΓòÉ 10.1. 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. Go Up
ΓòÉΓòÉΓòÉ 10.2. 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"))
Go Up
ΓòÉΓòÉΓòÉ 10.3. 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 deleteable. 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'))
Go Up
ΓòÉΓòÉΓòÉ 11. WPVault, x:/NOWHERE, NOTVISIBLE, SHOWALLINTREEVIEW ΓòÉΓòÉΓòÉ
Don't worry, you couldn't dereg/delete this class if you wanted to. Normally,
WPVault is only assigned to the Nowhere folder; it is intended to make it hard
for you to mess this folder or its contents. The WPS sets the physical
directory's attributes to system and hidden, and the WPS object's attributes to
NoMove NoDelete NoPrint NoDrag NotVisible NoRename.
You can also try aplying the following setting against x:\NOWHERE:
NOTVISIBLE=NO;SHOWALLINTREEVIEW=YES
(see the recipe in can't choose properties of Desktop). Suddenly all objects
in Nowhere appear in the treeview and can be seen...
That's an interesting way around the visibility problem. However, I think
there's actually more there than meets the eye.
Under Warp 3, at least, <WP_NOWHERE> contained a lot of transient objects of
classes WPFilter, WPFinder, WPFolderCV, etc. On my Warp 4 system, I know these
objects exist but I can't locate them. Since each of these classes has a style
of "Private" (which means "hidden"), I'd assume they're still in Nowhere but
totally inaccessible using conventional means.
In addition, some of the conventional objects in Nowhere have an object style
of "NotVisible". Most notable is <WP_VIEWINF> which is the default viewer for
*.INF files. Most of the objects that are visible on my system (other than the
COM and LPT objects) appear to have been put there either by WarpCenter or
Object Desktop. Go Up
ΓòÉΓòÉΓòÉ 11.1. x:/NOWHERE and NOTVISIBLE ΓòÉΓòÉΓòÉ
Nowhere contains objects "they" don't want you to mess with, e.g. the program
object for view.exe that's associated with *.INF. It also contains WarpCenter
& LaunchPad shadows, some Netscape helper apps, plus objects for your COM, LPT,
and remote printer ports. It may also contain junk - some people may still
have remnants left by the NSv4.61 beta.
In Warp v4 (at least), you can't open Nowhere, display its menu, or show its
properties notebook. However, you *can* see its contents by running the script
below, then opening your boot drive in tree view and pressing the "plus" button
next to Nowhere's icon. (Note: I've played with my system so much that YMMV
greatly as to what you can see. For example, mine always shows some objects;
running the script below simply increases the number visible.)
If you have more than one Nowhere directory, you should be able to identify
the one in use by the presence of the port objects (assuming you can see them
at all). Another way is to use the folder's Object ID (<WP_NOWHERE>) rather
than its path the first time you run the script. Whichever folder is expandable
is the one in use.
Put this in Boilerspace template:
/* this makes visible two objects that are normally hidden */
rc = SysSetObjectData( "<WP_VIEWINF>","NOTVISIBLE=NO")
rc = SysSetObjectData( "<WP_RJAPPLETPROGREF>","NOTVISIBLE=NO")
/* substitute <WP_NOWHERE> for the path on the first run to
help identify which of several Nowhere folders the WPS is
actually using */
call ReportRC(SysSetObjectData( "C:\NOWHERE","SHOWALLINTREEVIEW=YES"))
Go Up
ΓòÉΓòÉΓòÉ 11.2. SHOWALLINTREEVIEW ΓòÉΓòÉΓòÉ
SHOWALLINTREEVIEW=YES ? What does this do, and where is this statement placed
? If this does what I think it does, I'll be wondering why the hell IBM didn't
make this default.
This causes folders to display all their contents in Tree view, rather than
just subfolders. You can apply this attribute to any folder using this REXX
script. Supply the name of a directory when you run it (e.g. SHOWALL
C:\DESKTOP), or simply drop a folder on its icon.
Put this in Boilerspace template:
call ReportRC(SysSetObjectData(object,"SHOWALLINTREEVIEW=YES"))
Go Up
ΓòÉΓòÉΓòÉ 11.3. SHOWALLINTREEVIEW and old (Warp 3) folders ΓòÉΓòÉΓòÉ
The ability to show a folder's entire contents was added in Warp v4, but
nothing was added to the folder notebook to turn this on. Instead, you have to
use REXX; the script in SHOWALLINTREEVIEW will do the trick. Go Up
ΓòÉΓòÉΓòÉ 11.4. NODELETE and Templates ΓòÉΓòÉΓòÉ
| >I have several objects that were created by Devcon. They are extremely
| >annoying and I would like to be rid of them. Simple deletion doesn't work,
so
| Go to the 'general' page of the settings notebook. Uncheck the
| template checkbox, close the notebook and delete 'em.
That's not enough for the Warp Toolkit objects: they are created with the
object NODELETE attribute, which you can't get at from the WPS (unless you use
an object inspection utility).
You *can* zap them with REXX, though:
call RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SYSLOADFUNCS'
call SysLoadFuncs
call SysSetObjectData 'C:\Desktop\OS!2 System\Templates\Carpp', 'NODELETE=NO;'
Remove the Template attribute as above, then you can delete them.
Ok, that partially worked...it makes the objects "deletable", but they come
back after I delete them (i.e. Run script, Delete object, Close folder, Open
folder, IT'S BAAAACK). Any other ideas? Mayhaps a recommendation as to an
"object inspection utility"? Preferrably one that will let me kill the objects?
Every time you open the Templates folder, it populates itself with a template
for every class that supports "Create Another". If the template for a class is
missing, it asks the class to create another. The only way to permanently get
rid of them is to deregister the class. If that's what you want to do, add
this line to the script above:
Call SysDeregisterObjectClass "[name of class]"
Run the script, delete the object, close the folder, restart the WPS. The
template, the class, and any supporting os2.ini entries will be gone for good.
Go Up
ΓòÉΓòÉΓòÉ 12. .HLP not shown in view.exe ΓòÉΓòÉΓòÉ
IZ: applicable only to Warp 4 (view.exe would not open hlp, use viewhelp.exe).
OTOH, if you can't dblclick on a HLP to open it in the right app, it's because
HLP files don't have any pre-assigned association. During installation, OS/2
creates a hidden program object in your Nowhere folder (also hidden) and
associates it with *.INF. To access this object's notebook so you can add
*.HLP to its associations, run this REXX script (Put this in Boilerspace
template):
call ReportRC(SysSetObjectData("<WP_VIEWINF>","OPEN=SETTINGS"))
[Probably you need to make Nowhere visible first, see x:/NOWHERE and
NOTVISIBLE.] Go Up
ΓòÉΓòÉΓòÉ 13. Drag & Drop of .dev and printers ΓòÉΓòÉΓòÉ
If you drag and drop a printer file it will assume you want to install it. I
don't know the answer to your question though, but am also curios to know. I
would just drop to the command line & copy it from there.
When I responded to Timur's original posting, I suggested he go to the
"Become" page of the file's notebook and change its class to WPDataFile.
Contrary to my normal practice, I didn't fully test the results and was later
reminded why I (almost) always test before posting: when I went to drag my
test file the next day, it wouldn't budge. Even though the object's class had
changed, its "style" settings hadn't. The following REXX script fixes that.
Just replace "C:\junk\test.drv" with the name of your problem file, then run it.
Put this in Boilerspace template, see Open View IDs for DEFAULTVIEW=4:
call ReportRC(SysSetObjectData("C:\junk\test.drv", "NoMove=NO;NoLink=NO;NoCopy=NO;NoDrag=NO;DEFAULTVIEW=4;"))
BTW... do *not* move a real printer-driver file if you've installed one of the
printers it supports. Go Up
ΓòÉΓòÉΓòÉ 14. Start a VIO window with a changed font size ΓòÉΓòÉΓòÉ
Here's a REXX script that does what's needed (on my system, at least). YMMV
because of timing issues (i.e. it's possible that the font could get reset
before the window uses this setting).
Notice that I've included two different ways to invoke scache: by running it
directly and by opening a program object that runs it. I feel more comfortable
with the latter, but it requires that the pgm object have an Object ID (in this
case "<SCACHE>"). I added mine after the fact using a feature of DTProgram.
/* SCACHE.CMD - saves old font size, sets a new size, */
/* invokes smartcache, then restores old size */
/* note: if the font is "14x8", y=14 & x=8 */
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs
x = 8
y = 8
sav = SysIni('USER','Shield','~Font Size...')
new = d2c(x) || d2c(y)
rc = SysIni('USER','Shield','~Font Size...', new)
/* OPEN PROGRAM OBJECT */
rc = SysOpenObject('<SCACHE>','4','TRUE')
/* RUN DIRECTLY */
/* 'CD F:\JAVA11\SCACHE'
'START F:\JAVA11\BIN\JAVA.EXE -ms1m scache' */
rc = SysIni('USER','Shield','~Font Size...', sav)
Go Up
ΓòÉΓòÉΓòÉ 15. Desktop background ΓòÉΓòÉΓòÉ
Is there a way to find where the desktop's background is stored and change it?
I've heard it's possible with the WinSetObjectData() function but I don't know
how to do this?
Yes, you do use WinSetObjectData(). You can find the relevant setup string in
the WPS Programming Reference. e.g.
WinSetObjectData(WinQueryObject("<WP_DESKTOP>"),
"BACKGROUND=c:\somewhere\something.bmp,T,1,I;");
Go Up
ΓòÉΓòÉΓòÉ 16. Properties of the root directory ΓòÉΓòÉΓòÉ
The easiest way to clear up problems in a root directory is to erase "WP ROOT.
SF". You'll have to turn off the hidden and system attributes and you may have
to Alt-F1/boot to a command line to actually delete it (I don't recall). After
doing so, you'll have to open this drive's notebook and reset whatever
properties you normally change (e.g. sort order, includes, etc). Doing so will
recreate this file.
FYI... Root directories have no EAs, so "WP ROOT.SF" provides an alternate
means of storing WPS info. The file itself contains the root's .CLASSINFO.
Any other EAs that would be attached to a directory (e.g. .ICONPOS) are
attached to this file instead. Go Up
ΓòÉΓòÉΓòÉ 17. PM_Workplace:Location ΓòÉΓòÉΓòÉ
See DragText. Go Up
ΓòÉΓòÉΓòÉ 18. PM_Workplace:Templates ΓòÉΓòÉΓòÉ
See Hanging template folder. Go Up
ΓòÉΓòÉΓòÉ 19. AUTHOR ΓòÉΓòÉΓòÉ
Compilation, editing, and tools info by Ilya Zakharevich. The rest obtained
from Google using the search string
classinfo extended attributes
and from Google groups with
classinfo extended attributes group:*.os2.*
classinfo wps group:*.os2.*
sysloadfuncs group:*.os2.* author:walsh
classinfo group:*.os2.* author:walsh
Most prolific info-producer is Rich Walsh (with a giant margin).
http://www.usacomputers.net/personal/rlwalsh/
Particular chunks are not attributed to their authors, please look on Google
again. Go Up