How to programmatically fight with WPS: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).

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.