home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: WPS_PM / WPS_PM.zip / howtowps.zip / howtowps.INF (.txt) < prev    next >
OS/2 Help File  |  2001-12-03  |  68KB  |  1,462 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. About ΓòÉΓòÉΓòÉ
  3.  
  4. Generated on Tue Dec  4 00:43:31 2001, by perl version 5.00553, pod2ipf version 
  5. 1.32 with arguments "HOWTO-wps-details.pod" in directory J:/HOWTO. 
  6.  
  7.  
  8. ΓòÉΓòÉΓòÉ 2. HOWTO-wps-details - how to programmatically fight with WPS ΓòÉΓòÉΓòÉ
  9.  
  10. HOWTO-wps-details - how to programmatically fight with WPS 
  11.  
  12.      SYNOPSIS 
  13.      DESCRIPTION 
  14.      TOOLS 
  15.         -  DragText 
  16.         -  Open View IDs 
  17.         -  Boilerspace template 
  18.         -  strip() in REXX for spaces in filenames 
  19.      .CLASSINFO, 90 sec delay, DEFAULTVIEW 
  20.         -  Sample script to set .TYPE and .CLASSINFO 
  21.         -  Effects of lost EA 
  22.         -  Menu items 
  23.      PMWP entries in POPUPLOG.OS2 
  24.         -  SHELLEXCEPTIONHANDLER 
  25.      Lost/broken desktop or broken Templates or Startup 
  26.         -  Order of DESKTOP and <WP_DESKTOP> 
  27.         -  Details on lost desktops 
  28.         -  Startup folder and ObjectID 
  29.         -  Hanging template folder 
  30.         -  can't choose properties of Desktop 
  31.         -  Restoring System Setup or Templates 
  32.         -  ini.rc and SysCreateObject 
  33.         -  Script to recreate all or some lost objects 
  34.      URL objects 
  35.         -  "Go to URL" action 
  36.         -  URL attribute: a guess 
  37.         -  URL objects 
  38.      WPObjData and "Hammer and ..." icons 
  39.         -  Finally fixed! 
  40.         -  WPInstall not registered 
  41.         -  Data File:1 and NODELETE 
  42.      WPVault, x:/NOWHERE, NOTVISIBLE, SHOWALLINTREEVIEW 
  43.         -  x:/NOWHERE and NOTVISIBLE 
  44.         -  SHOWALLINTREEVIEW 
  45.         -  SHOWALLINTREEVIEW and old (Warp 3) folders 
  46.         -  NODELETE and Templates 
  47.      .HLP not shown in view.exe 
  48.      Drag & Drop of .dev and printers 
  49.      Start a VIO window with a changed font size 
  50.      Desktop background 
  51.      Properties of the root directory 
  52.      PM_Workplace:Location 
  53.      PM_Workplace:Templates 
  54.      AUTHOR 
  55.  
  56.  
  57. ΓòÉΓòÉΓòÉ 3. SYNOPSIS ΓòÉΓòÉΓòÉ
  58.  
  59. View this document as (depending on the format) 
  60.  
  61.   perldoc HOWTO-wps-details.pod
  62.   view HOWTO-wps-details
  63.  
  64. Convert from POD to INF as 
  65.  
  66.   pod2ipf HOWTO-wps-details.pod >HOWTO-wps-details.ipf
  67.   ipfc /INF HOWTO-wps-details.ipf
  68.  Go Up 
  69.  
  70.  
  71. ΓòÉΓòÉΓòÉ 4. DESCRIPTION ΓòÉΓòÉΓòÉ
  72.  
  73. Programmatic access to WPS is complicated due to several reasons: 
  74.  
  75.      Most APIs are accessible only from inside the WPS process (the second 
  76.       copy of PMSHELL.EXE), or via DSOM/CORBA via remote method call.
  77.  
  78.      To call things from inside the WPS process one needs to "inject" a WPS 
  79.       class into the system; possible bugs in the object will jeopardize the 
  80.       WPS integrity, thus the usability of the computer.  This makes WPS 
  81.       classes much harder to design than "ordinary" applications.
  82.  
  83.      The current implementation of DSOM lacks run-time 
  84.       method-dispatch-by-name, thus one needs to use CORBA (DII) to make 
  85.       arbitrary method calls from scripts.  AFAIK, there is no scripting 
  86.       solution which uses DII for its operation.
  87.  
  88.      Even with this hard-to-reach API, there is no API to fetch the data which 
  89.       allows reconstruction of the object state (serialization/deserialization, 
  90.       marshalling etc).  Thus one needs to use undocumented ways to fetch the 
  91.       object state.
  92.  
  93.      There is a small subset of API (Win*Object* (C) and Sys*Object* (REXX) 
  94.       API) usable from outside of the WPS process.  However, the control 
  95.       provided by this API is very restricted. 
  96.  
  97.  However, some stuff can be done even with such low-grade stuff as plain REXX. 
  98.  Go Up 
  99.  
  100.  
  101. ΓòÉΓòÉΓòÉ 5. TOOLS ΓòÉΓòÉΓòÉ
  102.  
  103.  Object REXX injects a class into WPS, so provides a direct access to WPS 
  104.         objects (with limitations w.r.t. marshalling etc).
  105.  
  106.  REXX without extensions provides access (via and Sys*Object* API) to the 
  107.         Win*Object* (C) subset of API.
  108.  
  109.  icon.exe (GUI for WPTOOLS.DLL) (by Kelder) among others shows many things: 
  110.  
  111.             1/2-decyphered contents of .CLASSINFO
  112.  
  113.             Init strings for objects;
  114.  
  115.             Contents of NOWHERE 
  116.  
  117.             Get/Set Object ID, location 
  118.  
  119.         WPTOOLS.DLL is also accessible from REXX.  Beware: there are tools 
  120.         which require uncompatible versions of this DLL...  WPTOOLS.DLL uses 
  121.         undocumented hacks to get the object data for EA and .INI files.
  122.  
  123.  ObjectSpy Class, class-DLL, ID, location, class ancessors, icon styles 
  124.         (no-delete etc), methods, interface.
  125.  
  126.  WP Class list Application Class Tree => create an object of the given class, 
  127.         (un)replace a class.
  128.  
  129.  RWX    Class Tree => metaclass/parent, DLL, Cause?, instance/class methods/datasize.
  130.  
  131.  Object Utility/2 D&D => Class, DLL, object-id, location, get/set style flags 
  132.         (no-delete etc).
  133.  
  134.  Setup strings list 
  135.  
  136.                  http://www.os2ezine.com/v3n07/wpsetup.txt
  137.  
  138.         a  complete  listing  of setup strings for common  object classes, 
  139.         along with a list of the values used with.
  140.  
  141.  WPObjData 
  142.  
  143.                  http://www.os2ezine.com/v3n07/hammer.htm
  144.  
  145.         tame WPObjData _and_ to put it to work doing something useful.
  146.  
  147.  WPSTools: 
  148.  
  149.         mo          create/modify-by-string-id objects 
  150.  
  151.         eo          modify by handle 
  152.  
  153.         fo          create shadows in TARGET by the *-pattern in ./
  154.  
  155.         qo          report the handle by the string-id
  156.  
  157.         wplist      list classes/dll
  158.  
  159.         wpkill      delete class 
  160.  
  161.         wpmake      add class 
  162.  
  163.  Perl   has access to Win*Object* API (C) (via OS2::WinObject module).  The 
  164.         module SOM gives access to all the SOM objects and the object 
  165.         repository, but (currently) only a limited access to DSOM objects (due 
  166.         to the absense of an interface to DII). 
  167.   Go Up 
  168.  
  169.  
  170. ΓòÉΓòÉΓòÉ 5.1. DragText ΓòÉΓòÉΓòÉ
  171.  
  172. Are you saying I can hilite something that shows up in the VIO window that 
  173. CHECKINI runs in, and DragText will locate it elsewhere on the "real" desktop?
  174.  
  175.  Yes - if the object actually exists.  I just ran checkini looking for an 
  176. example and found two.  The first is sort of involved, the second is pretty straightforward.
  177.  
  178.  Example 1: 
  179.  
  180.   =================================================
  181.    PM_Abstract:Objects & PM_Abstract:FldrContents
  182.   =================================================
  183.     OBJECTID <WP_TEMPS> (from 32DCB - G:\DESKTOP\ALL\OS!2 SYSTEM\TEMPLATES)
  184.     POINTS TO ANOTHER OBJECT 32968 - F:\DESKTOP\ALL\OS!2 System\TEMPLATES
  185.  
  186.   ╨áΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨┐
  187.   ╨╖ Assign a new OBJECTID to G:\DESKTOP\ALL\OS!2 SYSTEM\TEMPLATES?  ╨╖
  188.   ╨É╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧Γòó╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨ç
  189.   ╨╖               YES              Γäû              NO                ╨╖
  190.   ΓòÿΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓò¬ΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨╝
  191.  
  192. Honestly, I wasn't quite sure what this was telling me at first (I was up way 
  193. too late last night).  I have an FP7 system on "F:" and an FP14 system on "G:". 
  194. I was running checkini against F:, so why was it identifying a problem on G:?
  195.  
  196.  Then I remembered:  I had (foolishly) opened G:'s Templates Folder while 
  197. running F: and had seen the system populate it with shadows of F:'s templates. 
  198. This produced a record in F:'s os2.ini describing the contents of G:'s 
  199. templates folder (in particular, those shadows).
  200.  
  201.  Trying to make sense of it, I highlighted <WP_TEMPS> in the VIO window where 
  202. checkini's output appears.  Clicking Ctrl+Shift MB2 caused DragText to pop up 
  203. its WPS menu.  DT adds the object's name to the menu and puts its full path on 
  204. a submenu (selecting either will open whichever folder contains the object). 
  205. Checking the path on the submenu confirmed that F:'s <WP_TEMPS> did point to 
  206. the folder on F:.  I then did the same with the two object handles (32DCB & 
  207. 32968), just to be sure.
  208.  
  209.  Finally, it dawned on me:  when an object is assigned an ID, the info is 
  210. stored in PM_Workplace:Location *and* in the object's data (in this case, in 
  211. the folder's .CLASSINFO EA).  Apparently, whenever checkini encounters an 
  212. object whose data contains an Object ID, it cross-references this with the 
  213. entry in PM_Workplace:Location.
  214.  
  215.  G:\...\TEMPLATES's EA showed its ID to be <WP_TEMPS>, but PM...:Location said 
  216. this was assigned to F:\...\TEMPLATES, so checkini wanted to be "helpful" and 
  217. change G:'s ID.  Since this ID was perfectly valid when booting G:, and since 
  218. my setup on G: would be screwed up if I removed it, I answered "No".
  219.  
  220.  Now, without some of this prior knowledge, DT alone wouldn't have enabled me 
  221. to figure this out completely.  However, being able to confirm that when booted 
  222. to F:, <WP_TEMPS> pointed at the right folder on F:, and knowing that there is 
  223. another setup on G: _should_ be enough info to cause any *cautious* user to 
  224. answer "No" as well.
  225.  
  226.  Example 2: 
  227.  
  228.   Folder : F:\DESKTOP\PRONEWS!2
  229.     Object 2E027 , Class WPProgram : Purchase ProNews/2
  230.     Exename: E:\PN15B4\PURCHASE.EXE<-UNABLE TO ACCESS! Curdir: E:\PN15B4
  231.  
  232.   ╨áΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨┐
  233.   ╨╖ Remove this object which contains errors? ╨╖
  234.   ╨É╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧Γòó╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨₧╨ç
  235.   ╨╖         YES         Γäû         NO          ╨╖
  236.   ΓòÿΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓò¬ΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòôΓòô╨╝
  237.  
  238. I didn't doubt that checkini was correct, but I still wanted to see for myself. 
  239. I selected the object handle (2E027), clicked Ctrl+Shift MB2 to display this 
  240. program object's menu, then selected 'Properties'.  As reported, it pointed at 
  241. PURCHASE.EXE.  Since this file had been included in previous distributions of 
  242. ProNews/2, I decided to check the directory.  Again, I used DT to pop up the 
  243. menu for E:\PN15B4 and selected 'Open'.  Scanning the directory, I found a 
  244. PURCHASE.APP but no PURCHASE.EXE.  Satisfied that the object was unusable, I 
  245. told checkini to delete it.  (BTW... this is the only bug I've found in PN 
  246. v1.51b4 so far.)
  247.  
  248.  FWIW...  Example 1, along with my description in the original article of how I 
  249. "lost" G:'s Desktop, suggests that it's a *bad* idea to look at one 
  250. installation's standard system folders from another setup on the same machine. 
  251. Example 1 also suggests that you're not doing yourself any favors by having it 
  252. automatically answer "Yes" to every question. User intervention *is* required 
  253. for optimal results!
  254.  
  255.  ______________________________________________________________
  256.  
  257.  There is no official way to query the OBJECTID of a given object. However, my 
  258. WPTOOLS.DLL does have some functions to do it. WPTOOLS.DLL is part of the 
  259. WPTOOLxx.ZIP archive. Please look at: http://www.os2ss.com/information/kelder/
  260.  
  261.  Hmmm.  You're right, I misread that, I guess :-( How ' bout this rexx instead: 
  262.  
  263.   /* OBJECTID.CMD - Display object ids known to Workplace Shell */
  264.   call rxfuncadd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
  265.   call sysloadfuncs
  266.   call SysIni 'USER', 'PM_Workplace:Location', 'All:', 'ids.'
  267.     do i=1 to ids.0
  268.       Say ids.i
  269.     end
  270.  
  271. PMFJI...  but this is a perfect example of where my favorite DragText feature 
  272. (WPS links) would be uncommonly helpful.
  273.  
  274.  Once you have a listing of object IDs, you can use DragText to manipulate them 
  275. as though you had a folder full of shadows rather than words in a window.  You 
  276. can select an ID, then drag the object it refers to, or you can pop up its WPS 
  277. menu.  DT adds the object's name to the top of the menu and gives it a submenu 
  278. that shows the full path. This makes it easy to identify what <PDP_SMARTPFA> 
  279. refers to (F:\Desktop\OS!2 System\Problem!!Determination Tools\Hard File Monito 
  280. r). Selecting this menu item will take you directly to the named object.  Of 
  281. course , you can use most of the other menu entries too (Open as, Copy, etc).
  282.  
  283.  You can skip the script if you have an ini editor that uses a listbox to 
  284. display its info (most do, regedit2 doesn't).  Point it at 
  285. PM_Workplace:Location in os2.ini, then select an object ID from the list.  And, 
  286. if you want skip the script but still have a listing, you can use DT to drag 
  287. the entire contents of the listbox to somewhere more convenient - your editor, 
  288. a file, etc.  Go Up 
  289.  
  290.  
  291. ΓòÉΓòÉΓòÉ 5.2. Open View IDs ΓòÉΓòÉΓòÉ
  292.  
  293. from http://www.os2ezine.com/v3n07/wpsetup.txt, same as in Setup strings list: 
  294.  
  295.     -1  UNKNOWN
  296.      0  DEFAULT
  297.      1  CONTENTS (icon view)
  298.      2  SETTINGS
  299.      3  HELP
  300.      4  RUNNING (run pgm; for data files, run associated pgm)
  301.    101  TREE (tree view)
  302.    102  DETAILS (details view)
  303.    120  AUTO (WPDisk objects only)
  304.    121  PALETTE (color and font palettes, plus the LaunchPad)
  305.   4096  the 1st pgm associated with a data file (usually 1st on its Open menu)
  306.   4097  the 2nd pgm associated with a data file (usually 2nd on its Open menu)
  307.    etc
  308.   5000  the 1st pgm added to a data file's Open menu using the Menu page
  309.   5001  the 2nd pgm added via the Menu page
  310.    etc
  311.  25856  USER (proprietary view IDs start here;  USER+1 is most common)
  312.  42818  TextView (OD v1.0)
  313.  46914  TextView (OD v1.5)
  314.  Go Up 
  315.  
  316.  
  317. ΓòÉΓòÉΓòÉ 5.3. Boilerspace template ΓòÉΓòÉΓòÉ
  318.  
  319. Change SETVIEW.CMD to the name of your script.
  320.  
  321.  Keep in mind that /* should start the script, dependint on how you copy this 
  322. script, you may need to unindent the first line.  In view.exe, use 
  323. Control-Insert to Copy the contents of this window to a clipboard, then Paste 
  324. into your favorite editor. 
  325.  
  326.   /* SETVIEW.CMD */
  327.   /*   drop a file on this script's icon, or */
  328.   /*   invoke it from the command line passing the filename as an argument */
  329.  
  330.   call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  331.   call SysLoadFuncs
  332.  
  333.   arg object
  334.   arg = strip(object,,'"')              /* Spaces in argument => quoted arg */
  335.  
  336. ... Put the code at this place! 
  337.  
  338.   exit
  339.  
  340.   ReportRC:
  341.   parse arg rc
  342.   if rc
  343.   then
  344.      say "Success"
  345.   else
  346.      say "Failure"
  347.   return
  348.  Go Up 
  349.  
  350.  
  351. ΓòÉΓòÉΓòÉ 5.4. strip() in REXX for spaces in filenames ΓòÉΓòÉΓòÉ
  352.  
  353. FYI #1...  because of limitations in REXX, you can only set the attributes for 
  354. abstract objects like program objects or shadows if you have the object's 
  355. Object ID (e.g. <WP_OS2WIN> for your OS/2 Window program object).  For files 
  356. and folders, you can supply the fully qualified name instead.
  357.  
  358.  FYI #2... the "strip" command in my REXX Boilerspace template lets you drop 
  359. files whose names contain spaces onto your cmd icon. Without it, these names 
  360. will be passed to REXX with surrounding quotes that will cause functions to 
  361. fail.  Go Up 
  362.  
  363.  
  364. ΓòÉΓòÉΓòÉ 6. .CLASSINFO, 90 sec delay, DEFAULTVIEW ΓòÉΓòÉΓòÉ
  365.  
  366. After deleting the CLASSINFO EA did you reboot, or at least restart the WPS?
  367.  
  368.  The WPS only looks at this EA when it "awakens" an object (typically, when you 
  369. open the folder containing the object);  thereafter, it uses its in-memory copy 
  370. of this info.  Restarting the WPS clears this.
  371.  
  372.  OTOH, If you close the folder in question, and you don't have anything open in 
  373. tree-view which includes this folder, the WPS will put the objects to sleep 
  374. after about 90 seconds (i.e. it will remove them from memory).  With the 
  375. CLASSINFO gone and no memory of the objects' previous settings, the WPS should 
  376. use the association currently in force.
  377.  
  378.  If you're in a hurry <g>, use this (see Open View IDs for 4096) in Boilerspace 
  379. template: 
  380.  
  381.   call ReportRC(SysSetObjectData(object,"DEFAULTVIEW=4096;"))
  382.  Go Up 
  383.  
  384.  
  385. ΓòÉΓòÉΓòÉ 6.1. Sample script to set .TYPE and .CLASSINFO ΓòÉΓòÉΓòÉ
  386.  
  387. I want to change all files with an extension of jar files to TSZipMgr so that 
  388. jar files can be opened by the OD Zip Manager. [snip] I'll come up with a REXX 
  389. script that will perform at least part of the work.
  390.  
  391.  Paste or drag the following into a file named jarz.cmd, then drop objects on 
  392. it or use it from a command line.  Your jar files should change class when you 
  393. restart the WPS.  It may happen sooner if the folder containing the objects is 
  394. closed for about 2 minutes.  YMMV. 
  395.  
  396.   /*****************************************************************/
  397.   /* JARZ.CMD                                                      */
  398.   /* (C) Copyright R L Walsh 1999 - All Rights Reserved            */
  399.   /*                                                               */
  400.   /* JARZ resets .JAR .ZIP, and optionally .EXE files'             */
  401.   /* filetype to "ZIP File" and deletes their WPS class data.      */
  402.   /*                                                               */
  403.   /* Each file should become an instance of whatever WPS class     */
  404.   /* handles ZIP Files (a reboot may be needed).  It may also      */
  405.   /* become associated with programs that handle this file type.   */
  406.   /*                                                               */
  407.   /*****************************************************************/
  408.   /* DATA                                                          */
  409.   /*****************************************************************/
  410.   /* the list of acceptable extensions;  ext.0 sets the "last"     */
  411.   /* item in the list (e.g. '2' excludes EXEs, '3' includes them   */
  412.  
  413.   ext.0 = 2
  414.   ext.1 = '.jar'
  415.   ext.2 = '.zip'
  416.   ext.3 = '.exe'
  417.  
  418.   /* The          Curr one       8 data    EA                      */
  419.   /* EA:    MVMT CP   item ACSI chars     value                    */
  420.  
  421.   typeval = 'DFFF 0000 0100 FDFF 0800'X || 'ZIP File'
  422.  
  423.   /*****************************************************************/
  424.   /* CODE                                                          */
  425.   /*****************************************************************/
  426.  
  427.   parse upper arg junk
  428.   junk = strip(junk)
  429.  
  430.   if (junk = '' | junk = '?'  | junk = '/?' | junk = '/HELP') then
  431.   do
  432.       say ''
  433.       say '    JARZ resets .JAR .ZIP, and (optionally) .EXE files' || "'"
  434.       say '    filetype to "ZIP File" and deletes their WPS class data.'
  435.       say ''
  436.       say '    JARZ filespec [filespec [...]]'
  437.       say ''
  438.       say '         filespec = file name (wildcards OK), or'
  439.       say '                  = directory name (no wildcards)'
  440.       say ''
  441.       say '    See the comments in jarz.cmd for additional info.'
  442.       exit
  443.   end
  444.  
  445.   call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  446.   call SysLoadFuncs
  447.  
  448.   /* the big loop that's executed for each file spec               */
  449.   do while junk \= ''
  450.  
  451.   /* deal with quoted names, then clean up string                  */
  452.       if left(junk, 1) = '"' then
  453.           parse var junk '"' filespec '" ' junk
  454.       else
  455.           parse var junk filespec junk
  456.       filespec = strip(filespec)
  457.       filespec = strip(filespec,,'"')
  458.       if filespec = '' then
  459.           iterate
  460.  
  461.   /* rustle up some files                                          */
  462.   /* note:  SaySFTErr performs an exit so it never returns         */
  463.       rc = SysFileTree(filespec,'file','FO')
  464.       if rc \= 0 then
  465.           call SaySFTErr
  466.  
  467.   /*  if that didn't work, see if the filespec is a directory      */
  468.       if file.0 = 0 then
  469.       do
  470.           rc = SysFileTree(filespec,'file','DO')
  471.           if rc \= 0 then
  472.               call SaySFTErr
  473.  
  474.   /* if we didn't get exactly one dir back, make this a no-op      */
  475.   /* else get a list of all files in this dir                      */
  476.           if file.0 \= 1 then
  477.               file.0 = 0
  478.           else
  479.           do
  480.               filespec = file.1 || '\*.*'
  481.               rc = SysFileTree(filespec,'file','FO')
  482.               if rc \= 0 then
  483.                 call SaySFTErr
  484.           end
  485.       end
  486.  
  487.   /* for each file, see if it's extension is on the list           */
  488.   /* if so, have DueDamage change its EAs                          */
  489.       ctr = 0
  490.       do i=1 to file.0
  491.           do j=1 to ext.0
  492.               if right(file.i,4) = ext.j then
  493.               do
  494.                   call DueDamage
  495.                   ctr = ctr + 1
  496.                   leave
  497.               end
  498.           end
  499.       end
  500.       say ctr 'files processed for <' || filespec || '>'
  501.  
  502.   end
  503.   /* bottom of the big loop                                        */
  504.  
  505.   say 'Exiting'
  506.   exit
  507.  
  508.   /*****************************************************************/
  509.  
  510.   DueDamage:
  511.  
  512.   /* write a null value for .CLASSINFO                             */
  513.       rc = SysPutEA(file.i,'.CLASSINFO','')
  514.       if rc \= 0 then
  515.           err = 'removing .CLASSINFO'
  516.       else
  517.   /* write new value for .TYPE                                     */
  518.       do
  519.           rc = SysPutEA(file.i,'.TYPE',typeval)
  520.           if rc \= 0 then
  521.               err = 'resetting .TYPE'
  522.       end
  523.  
  524.   /* display either the filename or an error message               */
  525.       if rc = 0 then
  526.           say Filespec('name',file.i)
  527.       else
  528.           say 'Error #' rc err 'for file' Filespec('name',file.i)
  529.  
  530.       return
  531.  
  532.   /*****************************************************************/
  533.  
  534.   SaySFTErr:
  535.       say 'Error #' rc 'in SYSFILETREE for <' || filespec ||'>'
  536.       say 'Exiting'
  537.       exit
  538.  
  539.   /*****************************************************************/
  540.  Go Up 
  541.  
  542.  
  543. ΓòÉΓòÉΓòÉ 6.2. Effects of lost EA ΓòÉΓòÉΓòÉ
  544.  
  545. You're right, the problem is the EAs - but why they aren't copied onto a floppy 
  546. is beyond me.  Bad news:  you've lost 2 EAs.  Good news:  you can recover the 
  547. one that counts and gain some functionality. 
  548.  
  549.  .CLASSINFO this identifies the file as a WebEx_Url to WPS.  Unlike most 
  550.         file-based classes, WebEx_Url doesn't reconstruct this, so when it's 
  551.         gone, it's gone.  No big loss:  you've lost the icon and special notebook.
  552.  
  553.  .TYPE  this is set on the first page of a standard datafile's notebook and is 
  554.         what the WebEx app uses to identify Urls.  Set your copied files to 
  555.         type 'WebExplorer_Url' and they'll become acceptable to WebEx.  Open 
  556.         WebEx's notebook and associate it with objects of this type.  They'll 
  557.         get WebEx's icon and open WebEx when you doubleclick on them. 
  558.  
  559.  The EAs for *most* files are completely superfluous.  The exceptions are those 
  560.  files which need their EAs to be recognized as belonging to a specialized WPS 
  561.  class or to be given special handling by an app. This usually applies to files 
  562.  without a distinguishing file extension. In these cases, the WPS relies on 
  563.  their .TYPE or .CLASSINFO EAs.
  564.  
  565.   A good example is a URL object: see URL objects.  (Effectively, different 
  566.  programs use .TYPE or .CLASSINFO EA to distinguish the URLs objects from data files.)
  567.  
  568.   FYI...  The WPS uses a file's extension or filetype to assign it to a class 
  569.  only if it lacks a .CLASSINFO EA.  Once it has acquired this (typically by 
  570.  opening the object's Properties notebook), the extension or type no longer 
  571.  matters and can be changed or deleted without affecting the file's class assignment.
  572.  
  573.   For folders, the only EA that really matters is .CLASSINFO, and then, 
  574.  primarily for folders in your Desktop tree.  Folders such as Desktop, 
  575.  Templates, and Nowhere only possess special properties because their CLASSINFO 
  576.  EA identifies them as belonging to a specialized class. Loss of their 
  577.  .CLASSINFO will cause serious system disruption.
  578.  
  579.   Some of your Desktop folders may be generic WPFolder objects, but their 
  580.  .CLASSINFO contains their Object ID which the system may rely upon. Since the 
  581.  Object IDs are also stored in os2.ini, loss of these EAs isn't that critical. 
  582.  Checkini will identify the problem and fix it. For all other folders, all 
  583.  you'll lose is your customizations such as sort order, icon positioning, etc.
  584.  
  585.   Miscellanea: If you have files or folders with longnames on a FAT drive, 
  586.  you'll lose the name when the .LONGNAME EA is stripped.  On any file system, 
  587.  titles that include illegal file characters like linefeeds or backslashes will 
  588.  be lost.  When restored, the titles will match the file or folder's real name 
  589.  and have exclamation points where the illegal characters were.
  590.  
  591.   A very few exe's will lose their icons when their .ICON EA is removed. In 
  592.  most cases, the WPS can look in the file to get the icon, but in some cases 
  593.  this fails.  Other than this, you can safely strip the EAs from your 
  594.  application files and never notice the difference.
  595.  
  596.   In those cases where the EAs _are_ critical, use EAUTIL to strip them before 
  597.  backup and to restore them when you return the files and directories to use. 
  598.  Better yet, use backup and restore products that were designed for OS/2.  If 
  599.  all else fails, use Info-zip, then backup the zips.  Go Up 
  600.  
  601.  
  602. ΓòÉΓòÉΓòÉ 6.3. Menu items ΓòÉΓòÉΓòÉ
  603.  
  604. So you're saying there's no way to do what I want to do?  Those menu items have 
  605. to be stored SOMEWHERE.  Even if I can't use a standard API, there's got to be 
  606. a way to add these menu items. Are they part of the EA's for the Desktop folder?
  607.  
  608.  Yes they are. They are stored in the .CLASSINFO ea.
  609.  
  610.  As I recall well, there has been a beta toolkit for Warp 3 that even included 
  611. the syntax for adding menues to objects of WPFileSystem or derived classes. 
  612. Unfortunattely, this vanished again in the non-beta version. It didn't work anyway....
  613.  
  614.  Theoretically, you could alter the .CLASSINFO EA, but I am not sure you will 
  615. be able to keep the changes since the WPS tends to overwrite this EA on shutdown.
  616.  
  617.  I can tell you where exactly it is stored. Should you want this, please first 
  618. download my 'icontool' from my homepage since this will help you is 
  619. understanding what I mean.
  620.  
  621.  Still I wouldn't advise you to do this...
  622.  
  623.  Henk Kelder  Go Up 
  624.  
  625.  
  626. ΓòÉΓòÉΓòÉ 7. PMWP entries in POPUPLOG.OS2 ΓòÉΓòÉΓòÉ
  627.  
  628. I've been looking at this for quite a while, and have come up with a possible 
  629. explanation and a cure that's worse than the disease.  AFAIK, the WPS uses 
  630. "deferred parameter checking" - IOW, it doesn't check parameters for validity, 
  631. it just uses them.  If they cause a trap, the WPS's exception handler cleans 
  632. up, usually by aborting the current operation.  As such, PMWP isn't the "cause" 
  633. of the problem, just the unsuspecting victim of bad data.  Overall, the system 
  634. is working as designed.  Go Up 
  635.  
  636.  
  637. ΓòÉΓòÉΓòÉ 7.1. SHELLEXCEPTIONHANDLER ΓòÉΓòÉΓòÉ
  638.  
  639. If you're really hell-bent on eliminating this, you can try adding this line to 
  640. config.sys: 
  641.  
  642.   SET SHELLEXCEPTIONHANDLER=OFF
  643.  
  644. This turns off the WPS's exception handler, guaranteeing any errors will cause 
  645. a crash.  It's normally used by developers of WPS classes to keep the WPS from 
  646. covering up bugs in their code.  (That's why I've pursued this problem so 
  647. vigorously: with the exception handler off, I couldn't keep the WPS up long 
  648. enough to begin my debugging.)  Go Up 
  649.  
  650.  
  651. ΓòÉΓòÉΓòÉ 8. Lost/broken desktop or broken Templates or Startup ΓòÉΓòÉΓòÉ
  652.  
  653. Where to begin...  How about a warning?  The best way to "lose" your Desktop 
  654. (without suffering any real damage) is to access one installation's Desktop 
  655. from another setup on the same machine. E.g. I installed FP14 on my alternate 
  656. setup, then later started looking at its Desktop from my FP7 setup.  When I 
  657. rebooted to the FP14 system, all I got was a command window on an empty Desktop.
  658.  
  659.  First step:  edit config.sys and add this line, then reboot. 
  660.  
  661.     SET DESKTOP=C:\DESKTOP
  662.  
  663. (see Order of DESKTOP and <WP_DESKTOP>). If everything comes back as it should 
  664. be, run the following code 
  665.  
  666.   call ReportRC(SysSetObjectData("C:\DESKTOP","OBJECTID=<WP_DESKTOP>"))
  667.  
  668. (put this in Boilerspace template); then "rem-out" the line in config.sys until 
  669. the next time it's needed.  You need to run the REXX script or else many 
  670. installers will be unable to create Desktop objects; you'll want to disable the 
  671. config.sys entry so you'll know when a problem has occurred.  These two steps 
  672. will solve most lost Desktop problems.
  673.  
  674.  After rebooting, if your Desktop returns and all of the folders and files are 
  675. present but all of the program objects, shadows, and miscellanea are missing, 
  676. then os2sys.ini is probably corrupted. If you have pgm objects or shadows that 
  677. point at files on other disks, see if they're still good in order to guage the 
  678. extent of the damage.  Also, pop up the Desktop menu and select 'System Setup'. 
  679. Does the folder open?
  680.  
  681.  At this point, you have several options (see also Script to recreate all or 
  682. some lost objects).  The best would be to restore a *recent* archive of your 
  683. Desktop from the Alt-F1 boot screen.  If you were able to open System Setup 
  684. from the Desktop menu, you may instead want to restore recent backups of 
  685. os2.ini & os2sys.ini, such as those made by checkini.  You can either reboot to 
  686. a command line and copy them over, or you can edit config.sys and (temporarily) 
  687. change SET SYSTEM_INI= and SET USER_INI= to point to them, then reboot.  If you 
  688. choose the latter option, you can copy & rename the files and reedit config.sys 
  689. after you're satisfied with the results.
  690.  
  691.  Lacking recent backups, you still have some options.  First run checkini in 
  692. diagnostic mode (i.e. *without* the "/C" option). If you weren't able to open 
  693. System Setup from the Desktop menu, see if it offers to assign the object ID 
  694. <WP_CONFIG> to the System Setup folder (and makes similar offers for other 
  695. standard folders as well).  This will determine whether you'll be forced to run 
  696. MAKEINI.  Also, see if it finds valid objects assigned to "missing" folders. 
  697. If so, you should be able to recover them when you run it again in "fixit" mode.
  698.  
  699.  If opening System Setup wasn't a problem, or if checkini offered to fix it, 
  700. you can rerun checkini with "/C" to recover as much as possible.  Avoid letting 
  701. it delete anything and skip the final filehandles check altogether.  After a 
  702. reboot, see how things look.  You may have to drag a lot of recovered objects 
  703. back to their proper folders, and some things may still be screwed up. By not 
  704. deleting anything on the first run, you may have invalid program objects but at 
  705. least you'll know what you used to have and what needs fixing.  When things are 
  706. back to normal, then run checkini again and let it do all the cleanup still required.
  707.  
  708.  My repeated mention of opening System Setup from the Desktop menu is simply a 
  709. quick way to see if the standard folders have the object IDs they need for a 
  710. properly functioning system.  If they don't, then you probably have other 
  711. problems as well that need fixing.  For this you'll want to run a 
  712. *non-destructive* MAKEINI with this command line (after making a backup): 
  713.  
  714.     MAKEINI OS2.INI INI.RC
  715.  
  716. Before doing so, you may want to customize INI.RC and eliminate or comment-out 
  717. things you don't want (e.g. all those tired URL objects, or, at the end of the 
  718. file, the 3 lines that will reset your display to VGA).
  719.  
  720.  When you reboot, the WPS will create a new Desktop with all new folders and 
  721. objects, and will rename your current (defective) one as Previous Desktop. 
  722. After another reboot (just in case), run checkini and see what it can recover 
  723. (in this case, let it remove any duplicate object IDs it finds from the 
  724. previous Desktop's objects).  Chances are that you'll have to drag a lot of 
  725. things from the old desktop to the new.
  726.  
  727.  When this long ordeal is finally over, you can delete the previous or 
  728. temporary Desktop folder(s).  Because they have the NODELETE style, you'll have 
  729. to get rid of this before 'Delete' appears on their menus. One way is to plug 
  730. this into the Boilerspace template): 
  731.  
  732.   rc = SysSetObjectData( "C:\PREVIOUS DESKTOP","NODELETE=NO")
  733.  
  734. Except for a few details here and there, AFAIK, that about covers it.  Did I 
  735. answer your question, Barbara?
  736.  
  737.  BTW... since I haven't plugged DragText yet, I should mention that it can be a 
  738. handy adjunct when dealing with these problems, e.g., validating required 
  739. object IDs (as found in INI.RC), accessing & examining objects as checkini 
  740. finds them (via the numeric object handles it displays for each), etc.  See 
  741. DragText.  Go Up 
  742.  
  743.  
  744. ΓòÉΓòÉΓòÉ 8.1. Order of DESKTOP and <WP_DESKTOP> ΓòÉΓòÉΓòÉ
  745.  
  746. If D:\DESKTOP does exist and your config.sys says SET DESKTOP=D:\DESKTOP, the 
  747. WPS will attempt to use it.  If that directory doesn't exist, of course you're 
  748. going to have problems.
  749.  
  750.  If this line is not in config.sys, the WPS will try to locate the Desktop 
  751. using os2.ini info.  If that info is missing, you'll have your current problem. 
  752. Use the following REXX script to restore the info to os2.ini.  Just be sure 
  753. that it points to your current, *valid* Desktop path (and don't forget to 
  754. delete the "set desktop=" line in config.sys).  Go Up 
  755.  
  756.  
  757. ΓòÉΓòÉΓòÉ 8.2. Details on lost desktops ΓòÉΓòÉΓòÉ
  758.  
  759. [More on Lost/broken desktop or broken Templates or Startup.]
  760.  
  761.  This problem comes in two flavors:  "plain vanilla" and "rocky road".
  762.  
  763.  First, restore the backup ini files (even though they didn't work last time). 
  764. In config.sys, add "SET DESKTOP=E:\DESKTOP", then reboot.  This will point PM 
  765. at your original Desktop directory.  If all your program objects, shadows, and 
  766. other non-filesystem objects reappear, you had the "plain vanilla" problem. 
  767. All you need to do now is run the REXX script below.
  768.  
  769.  OTOH, if only files and folders reappear and/or you get unexpected objects in 
  770. unexpected places, you've got "rocky road".  In this case, consider yourself 
  771. lucky if you can recover any of your old setup.  If you don't already have it, 
  772. get wptool19.zip so you can run checkini.exe.  The first time you run it, you 
  773. may want to omit the "/C" command line parameter so that it only reports errors 
  774. and doesn't try to fix them.
  775.  
  776.  The first time you have it try to fix things, your primary goal is to have it 
  777. recover objects that it says are located in non-existent directories.  Say 'no' 
  778. to most offers to fix other problems.  After a reboot, your Desktop will be 
  779. filled with folders full of found objects.  Retrieve and fix your own objects 
  780. but skip system-supplied ones.  Things will be so messed up that you'd do well 
  781. to run a nondestructive MAKEINI to recreate your System Setup, Startup, etc. 
  782. folders and the objects therein (see Startup folder and ObjectID, Hanging 
  783. template folder, Restoring System Setup or Templates, ini.rc and 
  784. SysCreateObject, Script to recreate all or some lost objects).  After that's 
  785. done (and you've rebooted yet again), run checkini again to clean up the mess 
  786. that remains.
  787.  
  788.  FYI... the "plain vanilla" problem is common and easy to fix: the Desktop 
  789. folder's Object ID (i.e. <WP_DESKTOP>) has disappeared, so the WPS can't find 
  790. it.  The REXX line in Lost/broken desktop or broken Templates or Startup 
  791. restores it.  The "rocky road" problem is semi-catastrophic: the file handles 
  792. table in os2sys.ini got lost/corrupted and the system assigned all new handles 
  793. to the files and folders on your E: drive.  The WPS uses these handles to 
  794. associate abstract (i.e. non- filesystem) objects with particular folders.  Now 
  795. that the folders' handles have changed, your abstract objects are no longer 
  796. associated with any folder, so they're in limbo.  Checkini will fix this by 
  797. associating these objects with new folders it creates.  Go Up 
  798.  
  799.  
  800. ΓòÉΓòÉΓòÉ 8.3. Startup folder and ObjectID ΓòÉΓòÉΓòÉ
  801.  
  802. To actually do anything, your Startup folder must be of class WPStartup and 
  803. have the object ID "<WP_START>".
  804.  
  805.  For future reference...  Chances are that this Startup folder had lost either 
  806. its ObjectID ("<WP_START>") or its .CLASSINFO extended attribute.  ObjectID is 
  807. easy to fix: use SysSetObjectData in a REXX script to restore it.  Losing the 
  808. EA that tells the WPS that this is a Startup folder renders it useless, so you 
  809. have to create a new Startup folder.  If you search \os2\ini.rc, you'll find 
  810. any entry for this folder that contains all the parameters you'll need to 
  811. recreate it using SysCreateObject.  Note that the parms are *not* listed in the 
  812. order that SysCreateObject requires, so you'll have to do some transposition. 
  813. See ini.rc and SysCreateObject, Script to recreate all or some lost objects. 
  814. Go Up 
  815.  
  816.  
  817. ΓòÉΓòÉΓòÉ 8.4. Hanging template folder ΓòÉΓòÉΓòÉ
  818.  
  819. More than likely, there's some invalid object in there which is causing the 
  820. hang - perhaps a template for some object class you've deregistered.  Here's a 
  821. list of steps you can take to fix things, starting with the most benign: 
  822.  
  823.      run checkini.
  824.  
  825.        No comment necessary :-)
  826.  
  827.      delete the Templates Folder's .ICONPOS EA 
  828.  
  829.        I've seen invalid entries or references to nonexistent classes in here 
  830.       cause stuff to disappear 
  831.  
  832.      delete "PM_Workplace:Templates" from os2.ini
  833.  
  834.        This provides the list of options on the Create Another submenu; it will 
  835.       be rebuilt as the WPS rediscovers your templates.
  836.  
  837.      delete the contents of Templates 
  838.  
  839.        Obviously not an option here since you can't access them. It's worth 
  840.       noting that any class that provides a template will recreate it on demand 
  841.       - only the ones that are customized or "variations on a theme" will be 
  842.       lost.  If you do this, be sure to delete "PM_Workplace:Templates" from 
  843.       os2.ini afterwards.
  844.  
  845.      delete the Templates Folder, then recreate it 
  846.  
  847.       -           Before doing so, use your filemanager to move any customized 
  848.                   file templates to another directory.  For example, Lotus 
  849.                   WordPro has a subfolder in there filled with specialized 
  850.                   templates that will be lost otherwise.  The best place to put 
  851.                   them is a folder deep in your directory tree where neither it 
  852.                   nor it parent is likely to be accessed.
  853.  
  854.       -           After saving what you want, delete the remaining files and 
  855.                   directories, then delete the Templates folder itself.  I 
  856.                   don't know if you'll be able to do this while the WPS is 
  857.                   running.  Regardless, avoid accessing both Templates and 
  858.                   whatever folder it's in during the session you do all this.
  859.  
  860.       -           Delete "PM_Workplace:Templates" from os2.ini.
  861.  
  862.       -           Kill the WPS or reboot, then run this script to recreate 
  863.                   Templates (the SysCreateObject call should all be on one 
  864.                   line): 
  865.  
  866.                                       /* script to recreate the TEMPLATEs folder */
  867.  
  868.                                       call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  869.                                       call SysLoadFuncs
  870.                                       rc = SysCreateObject( "WPTemplates", "Templates", "<WP_OS2SYS>",
  871.                                            "HELPPANEL=15680;NODELETE=YES;OBJECTID=<WP_TEMPS>", "UPDATE")
  872.  
  873.                   (compare with Restoring System Setup or Templates).
  874.  
  875.       -           Finally, open your new Templates folder.  There should be a 
  876.                   lot of activity as the WPS recreates all of the standard 
  877.                   templates.  Return any templates you saved *and* open every 
  878.                   folder you know contains templates (this will repopulate 
  879.                   "PM_Workplace:Templates" and your Create Another menus). 
  880.  
  881.  A final note:  if you've installed Feature Installer, you probably have a 
  882.  template labelled Data File:1 that shows a hammer and screwdriver.  Then see 
  883.  Data File:1 and NODELETE.
  884.  
  885.   You can put this to good use if you want to delete undeletable templates. 
  886.  Open this file in a text editor (you can Shift-drag its icon to your editor's 
  887.  icon, then Shift-drop it). Add this single line (without quotes), then save 
  888.  the file: 
  889.  
  890.     "NODELETE=NO"
  891.  
  892.  Whenever you need to delete an undeleteable template, just drop it on this 
  893.  template.  The dropped object will now have a Delete entry on its popup menu 
  894.  and can be deleted in any of the usual ways.  Go Up 
  895.  
  896.  
  897. ΓòÉΓòÉΓòÉ 8.5. can't choose properties of Desktop ΓòÉΓòÉΓòÉ
  898.  
  899.   When I press RMB on the desktop I can't choose properties. Does anyone
  900.   know the reason? I used to be able to choose it. I have installed FP1
  901.   and FP3 on my Warp 4.
  902.  
  903. When you say you "can't choose properties", do you mean: 
  904.  
  905.  - that entry is missing from the menu?
  906.  - the entry is present but disabled (grayed-out)?
  907.  - you can select Properties but nothing happens?
  908.  
  909. I'm sorry... The properties entry is missing from the menu.
  910.  
  911.  OK...  Have you recently installed any WPS "enhancements", or more likely, any 
  912. WPS security add-ons that are designed to keep users from changing things?  If 
  913. not, try the following REXX script.  Either drop your Desktop folder icon on 
  914. it, or run it from the command line supplying the path of your Desktop folder 
  915. as an argument (i.e.  settings c:\desktop  ).
  916.  
  917.  Put this in Boilerspace template: 
  918.  
  919.   call ReportRC(SysSetObjectData(object,"NOSETTINGS=NO"))
  920.  Go Up 
  921.  
  922.  
  923. ΓòÉΓòÉΓòÉ 8.6. Restoring System Setup or Templates ΓòÉΓòÉΓòÉ
  924.  
  925. The desktop pop-up menu which displays the System Setup line to show the 
  926. particular folder is still there, but doesn't bring up the folder. System setup 
  927. itself is in the OS/2 system folder and is still there.
  928.  
  929.  Can anyone tell me how to "re-activate" the System Setup line in the pop up menu?
  930.  
  931.  I hope I'm not too late and you haven't done a reinstall...  Try this (Put 
  932. this in Boilerspace template): 
  933.  
  934.   call ReportRC(SysSetObjectData("F:\Desktop\OS!2 System\System Setup","OBJECTID=<WP_CONFIG>"))
  935.  
  936. Similarly for templates: 
  937.  
  938.   call ReportRC(SysSetObjectData("F:\Desktop\OS!2 System\Templates","OBJECTID=<WP_TEMPS>"))
  939.  Go Up 
  940.  
  941.  
  942. ΓòÉΓòÉΓòÉ 8.7. ini.rc and SysCreateObject ΓòÉΓòÉΓòÉ
  943.  
  944. Whenever you damge or destroy a system-supplied object, go to \os2\ini.rc, find 
  945. the entry for the object, then reformat the parameters for use with the REXX 
  946. SysCreateObject command.  In this case, the line from ini.rc is: 
  947.  
  948.   "PM_InstallObject" "Drives;WPDrives;<WP_CONNECTIONSFOLDER>;RELOCATE"
  949.   "ALWAYSSORT=YES;NODELETE=YES;DEFAULTVIEW=ICON;OBJECTID=<WP_DRIVES>"
  950.  
  951. Below is a REXX script that uses these parms.  Note that neither 
  952. "PM_InstallObject" nor "RELOCATE" are applicable in a REXX script.  OTOH, the 
  953. "REPLACE" parameter included below is REXX-specific;  it is documented in your 
  954. online REXX ref. (N.B.  this is for Warp v4;  for v3, change 
  955. <WP_CONNECTIONSFOLDER> to <WP_OS2SYS>)
  956.  
  957.  Put this in Boilerspace template, SysCreateObject() call should be all on the 
  958. same line: 
  959.  
  960.   /* REXX script to recreate the Drives folder*/
  961.   call ReportRC(SysCreateObject("WPDrives", "Drives", "<WP_CONNECTIONSFOLDER>",
  962.     "ALWAYSSORT=YES;NODELETE=YES;DEFAULTVIEW=ICON;OBJECTID=<WP_DRIVES>",
  963.     "REPLACE"))
  964.  Go Up 
  965.  
  966.  
  967. ΓòÉΓòÉΓòÉ 8.8. Script to recreate all or some lost objects ΓòÉΓòÉΓòÉ
  968.  
  969.   /* ReCreate.CMD - restore lost desktop objects              */
  970.   /* by Greg Czaja - July 29, 1992                            */
  971.   /*               - April 9, 1993  ver.2                     */
  972.   /*                 handle 2.1-style INI.RC                  */
  973.   /* the July 1992 REXXUTIL version is required for 2.0 GA    */
  974.   /* (look for REXX20 in Lib 17 in OS2SUPPORT)                */
  975.   /* no additional requirements for GA+SP or 2.1              */
  976.   Call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  977.   Call SysLoadFuncs;
  978.   SysBootDrive=Filespec('Drive',Value('SYSTEM_INI',,'OS2ENVIRONMENT'));
  979.   file_name=SysBootDrive||'\OS2\INI.RC';
  980.   Say "The program will list all single standard objects from your desktop"
  981.   Say "Reply Y(es) if you want recreate the listed object - E(nd) to end the program"
  982.   Say "N(o) is the default if you press ENTER:"
  983.   Do While Lines(file_name) > 0;
  984.   line=Linein(file_name);
  985.   If line='' Then Iterate;        /* skip blanks   */
  986.   Parse Var line '"PM_InstallObject"' line;
  987.   If line='' Then Iterate;        /* skip others   */
  988.   Parse Var line '"'head'" 'line; /* get header    */
  989.   Parse Var line '"'setup'"' .;   /* get setup string */
  990.   Parse Var head title';'object';'location';' . ;
  991.   Say title "- Yes/No/End ?";
  992.   Pull reply ;
  993.   If Left(reply,1) ='E' Then Leave;
  994.   If Left(reply,1) <> 'Y' Then Iterate;
  995.   If SysCreateObject(object,title,location,setup,'Update') = 0
  996.      Then Say 'Error creating:' title;
  997.      Else Say title 'created !';
  998.   End;
  999.   rc=Stream(file_name,'C','Close');
  1000.   Return 0        /* enjoy your desktop! */
  1001.   /*
  1002.   Did you delete your Command Prompts ? Shredded your Shredder ?
  1003.   This program restores the standard WPS desktop objects on 2.x.
  1004.   It will preserve any current settings/objects you may have created and this
  1005.   is its advantage over the Alt-F1 or MAKEINI method.
  1006.   You will need the latest REXX fixes (REXX20 available in library 17) to make
  1007.   it run correctly on 2.0 GA system, no fixes required on GA+SP or 2.1.
  1008.   */
  1009.  Go Up 
  1010.  
  1011.  
  1012. ΓòÉΓòÉΓòÉ 9. URL objects ΓòÉΓòÉΓòÉ
  1013.  
  1014. URL objects 
  1015.  
  1016.      "Go to URL" action 
  1017.      URL attribute: a guess 
  1018.      URL objects 
  1019.   Go Up 
  1020.  
  1021.  
  1022. ΓòÉΓòÉΓòÉ 9.1. "Go to URL" action ΓòÉΓòÉΓòÉ
  1023.  
  1024. Can anybody explain me how to permanently set the "Go to URL" action on the 
  1025. "open" menu of the URL object?
  1026.  
  1027.  You can't under Warp v3.0.  The WebEx class explicitly resets the default view 
  1028. each time a WebEx object is "awakened" (made visible when the folder it's in is 
  1029. opened).  I know this for a fact because the code outputs this debugging 
  1030. message: 
  1031.  
  1032.     **WebExplorer:wpObjectReady(): wpSetDefaultView succeeded
  1033.  
  1034. Your only option under v3.0 is to use an EA editor to delete the .CLASSINFO 
  1035. extended attribute.  Then the file will no longer be a WebExplorer_Url object 
  1036. and can be associated with WebEx (or rather, WebEx can be associated with files 
  1037. of type WebExplorer_Url).  The file can still be dropped on WebEx to load the 
  1038. Url - WebEx looks at the type, not the object class, to determine whether 
  1039. you're dropping a Url or a file.  (Confused?  See URL objects.)
  1040.  
  1041.  Under Warp v4.0 (Merlin), you won't have this problem because the new wpUrl 
  1042. class doesn't mess with your choice of default open actions.  However, AFAIK, 
  1043. you will have to manually change each old WebEx object to open the browser you 
  1044. choose.  Go Up 
  1045.  
  1046.  
  1047. ΓòÉΓòÉΓòÉ 9.2. URL attribute: a guess ΓòÉΓòÉΓòÉ
  1048.  
  1049. I think that this has to do with how the URL attribute is stored. Rather and an 
  1050. EA, I think that it is an ini file thing <sigh>.  I found that object desktop's 
  1051. package system will work to transport URLs, or you can use a REXX program to 
  1052. rewrite 'em as webx URLs.
  1053.  
  1054.  [Does URL objects refute this?]  Go Up 
  1055.  
  1056.  
  1057. ΓòÉΓòÉΓòÉ 9.3. URL objects ΓòÉΓòÉΓòÉ
  1058.  
  1059. The WPS uses its .TYPE EA of "UniformResourceLocator" to assign it to the WPUrl 
  1060. class while NS/2 uses the EA to identify its special function.  Without this 
  1061. EA, URL objects will revert to plain-text files when copied back into your 
  1062. system.  You will have to reassign them a type to restore their functionality.
  1063.  
  1064.  Some file objects belong to a particular class solely because their CLASSINFO 
  1065. EA says so.  Warp 3's WebExplorer_Url class is an example. Even though these 
  1066. files have a .TYPE EA of "WebExplorer_Url" for NS/2's benefit, this class 
  1067. wasn't written to associate the type with the class. These files had to be 
  1068. explicitly created as "objects" (which always results in a .CLASSINFO EA) in 
  1069. order to belong to the WebExplorer_Url class.  Stripped of their .CLASSINFO 
  1070. EAs, WebExUrls will also revert to plain-text files and you won't be able to 
  1071. restore them.
  1072.  
  1073.  There's a frequent fundamental misunderstanding of what WebEx Url objects 
  1074. really are.  They are nothing but files whose .TYPE EA is "WebExplorer_Url ". 
  1075. While WebEx and other apps may use PM's WPS interface calls to create them, 
  1076. WebEx itself is wholely ignorant of their object wrapper when it comes time to 
  1077. read them.  As long as the app that originates a drag action identifies the 
  1078. file being dragged as a WebExplorer_Url, WebEx will be happy to accept and read 
  1079. it.  The WPS need not even be loaded.
  1080.  
  1081.  In Merlin, these files have become "WPUrl" objects and may or may not have the 
  1082. WebExplorer_Url .TYPE EA.  However, the WPS still identifies them as such 
  1083. during a drag to keep WebEx happy.  (Unlike the WebExUrl class, Merlin's WPUrl 
  1084. class is automatically associated with any file having this .TYPE EA.)
  1085.  
  1086.  Here's an experiment or two to demonstrate the above: - use EPM (or any editor 
  1087. that doesn't add a Ctrl-Z to the end of a file) to create a file with a valid 
  1088. URL.  After saving it, open the file's settings notebook, delete any Current 
  1089. Types, and add WebExplorer_Url from the list of Available Types.  Now drag and 
  1090. drop the file on WebEx.  The URL will be loaded, even though it isn't a 
  1091. "WebExplorer_Url" object. - start Merlin, then look at the file's Object Class 
  1092. in a Details view of its folder.  You'll see that it's WPUrl.  Open its 
  1093. properties notebook:  it should be that of a Url object.  If it isn't, you'll 
  1094. have to use the "Become" tab to make it one;  after a restart, it will belong 
  1095. to the WPUrl class.
  1096.  
  1097.  BTW...  *no* WPS objects are "EAs hanging off the directory".  If an object is 
  1098. filesystem-based, it has its own .CLASSINFO EA that is used by the WPS. If the 
  1099. object is abstract (like a Program reference object), the classinfo is stored 
  1100. in OS2.INI.  Go Up 
  1101.  
  1102.  
  1103. ΓòÉΓòÉΓòÉ 10. WPObjData and "Hammer and ..." icons ΓòÉΓòÉΓòÉ
  1104.  
  1105. Just curious. Back when I applied FP1 to Warp 4, my e.exe lost its pretty icon 
  1106. due to the ea glitch. I got the icon back from one of my previous files & 
  1107. everything was fine. Now we have FP3. Things have seemed to be golden since the 
  1108. service. Now I notice many of my *.txt files that would normally be associated 
  1109. with e.exe (and still open with it) have a new icon consisting of a rather drab 
  1110. looking screw-driver and hammer. Is my system secretly trying to make me feel 
  1111. more like a man or is this something to worry about? TIA.
  1112.  
  1113.  These files have been sucked up by the WPObjData class which is an adjunct to 
  1114. the Feature Installer (WPInstall).  Apparently, the people who are writing 
  1115. these WPS classes don't know how the WPS works.  The files WPObjData creates 
  1116. are supposed to be of type "Plain Text".  However, the way they wrote it, *any* 
  1117. Plain Text file becomes an instance of WPObjData if it isn't already classified 
  1118. as a WPDataFile.  Your best bet is to deregister WPObjData using this REXX 
  1119. script, then restart the WPS.
  1120.  
  1121.  Put this in Boilerspace template: 
  1122.  
  1123.   call ReportRC(SysDeregisterObjectClass("WPObjData"))
  1124.  Go Up 
  1125.  
  1126.  
  1127. ΓòÉΓòÉΓòÉ 10.1. Finally fixed! ΓòÉΓòÉΓòÉ
  1128.  
  1129. You'll be pleased to know that IBM *has* finally addressed the problem: the 
  1130. version of WPObjData that comes with WSeB no longer exhibits this obnoxious 
  1131. behavior.  Let's see...  I first posted the script Tim cites on Sept 20, 1997 
  1132. and the fixed version of objdata.dll is dated April 5, 1999. So, it only took 
  1133. 19+ months to correct - pretty good for "them" <g>.
  1134.  
  1135.  FYI...  You may want to read my article in os2ezine, _Using That Hammer and 
  1136. Screwdriver_ (http://www.os2ezine.com/v3n07/hammer.htm), for a way to both tame 
  1137. WPObjData and to put it to work doing something useful.  Go Up 
  1138.  
  1139.  
  1140. ΓòÉΓòÉΓòÉ 10.2. WPInstall not registered ΓòÉΓòÉΓòÉ
  1141.  
  1142. My guess is that the WPInstall class isn't registered.  You should be able to 
  1143. restore it by installing the latest Feature Installer, or by using the 
  1144. following script (I assume you have an INSTALL.DLL in C:\OS2\DLL).  Put this in 
  1145. Boilerspace template: 
  1146.  
  1147.   /* REXX script to reregister the WPInstall class*/
  1148.   rc = SysDeregisterObjectClass("WPInstall")
  1149.  
  1150.   call ReportRC(SysRegisterObjectClass("WPInstall","C:\OS2\DLL\INSTALL.DLL"))
  1151.  Go Up 
  1152.  
  1153.  
  1154. ΓòÉΓòÉΓòÉ 10.3. Data File:1 and NODELETE ΓòÉΓòÉΓòÉ
  1155.  
  1156. gobbled up a template and then everything froze. CAD brought me back and the 
  1157. template had been deleted and the entry had been removed from the ini (not by me).
  1158.  
  1159.  This needn't be so difficult.  You either have, or can have, an object that 
  1160. will make other objects deleteable.  If you're running Warp 3 or 4.0 and have 
  1161. installed Feature Installer, you probably have a template labeled "Data File:1" 
  1162. whose icon shows a hammer & screwdriver.  If running MCP or eCS, you have the 
  1163. required dll but the WPS class it contains (WPObjData) is not yet registered. 
  1164. Once this is set up, you'll be able to drop most any object on your ObjData 
  1165. icon to restore the Delete option to its menu. And, your system will not freeze 
  1166. up (well, it certainly shouldn't...).
  1167.  
  1168.  If you don't have the "hammer & screwdriver" template, register the class 
  1169. using the script below.  Doing so will create a new template.  While you could 
  1170. create a normal object from the template, you'll probably have little other use 
  1171. for it, so edit the template itself.  Drag the template to your editor's icon, 
  1172. press Shift to make it droppable, then drop.  The object is actually an empty 
  1173. datafile to which you will add this one line: 
  1174.  
  1175.     NODELETE=NO
  1176.  
  1177. Save the file, then try out its template object.  Drop something that's 
  1178. undeleteable on it, then pop up the dropped object's menu.  There should now be 
  1179. a usable "Delete" entry on it.  I've found that some classes will restore their 
  1180. NODELETE flag if you manipulate them or drag them to the shredder, so delete 
  1181. the object ASAP after using your ObjData icon.
  1182.  
  1183.  FYI... you could use a REXX script to do this for files and directories, but 
  1184. REXX can't operate on abstract objects like Program Objects unless they have an 
  1185. object ID.  A WPObjData object will work with any type of object (if a file has 
  1186. its "read-only" or "system" attributes set, you may have to turn these off first).
  1187.  
  1188.  Put this in Boilerspace template: 
  1189.  
  1190.   /* OBJDATA.DLL _should_ be in your os2\dll directory and           */
  1191.   /* accessible via your LIBPATH statement.  If it isn't,            */
  1192.   /* it may be in your FISETUP directory;  in this case you          */
  1193.   /* must supply the dll's full path & filename, e.g.                */
  1194.   /* SysRegisterObjectClass('WPObjData','E:\FI\FISETUP\objdata.dll') */
  1195.   /* Be sure to use a file dated June 7, 1999 or later - earlier     */
  1196.   /* versions had a major bug and were a real PITA                   */
  1197.  
  1198.   call ReportRC(SysRegisterObjectClass('WPObjData','OBJDATA'))
  1199.  Go Up 
  1200.  
  1201.  
  1202. ΓòÉΓòÉΓòÉ 11. WPVault, x:/NOWHERE, NOTVISIBLE, SHOWALLINTREEVIEW ΓòÉΓòÉΓòÉ
  1203.  
  1204. Don't worry, you couldn't dereg/delete this class if you wanted to. Normally, 
  1205. WPVault is only assigned to the Nowhere folder; it is intended to make it hard 
  1206. for you to mess this folder or its contents. The WPS sets the physical 
  1207. directory's attributes to system and hidden, and the WPS object's attributes to 
  1208. NoMove NoDelete NoPrint NoDrag NotVisible NoRename.
  1209.  
  1210.  You can also try aplying the following setting against x:\NOWHERE: 
  1211.  
  1212.  NOTVISIBLE=NO;SHOWALLINTREEVIEW=YES
  1213.  
  1214. (see the recipe in can't choose properties of Desktop).  Suddenly all objects 
  1215. in Nowhere appear in the treeview and can be seen...
  1216.  
  1217.  That's an interesting way around the visibility problem.  However, I think 
  1218. there's actually more there than meets the eye.
  1219.  
  1220.  Under Warp 3, at least, <WP_NOWHERE> contained a lot of transient objects of 
  1221. classes WPFilter, WPFinder, WPFolderCV, etc.  On my Warp 4 system, I know these 
  1222. objects exist but I can't locate them.  Since each of these classes has a style 
  1223. of "Private" (which means "hidden"), I'd assume they're still in Nowhere but 
  1224. totally inaccessible using conventional means.
  1225.  
  1226.  In addition, some of the conventional objects in Nowhere have an object style 
  1227. of "NotVisible".  Most notable is <WP_VIEWINF> which is the default viewer for 
  1228. *.INF files.  Most of the objects that are visible on my system (other than the 
  1229. COM and LPT objects) appear to have been put there either by WarpCenter or 
  1230. Object Desktop.  Go Up 
  1231.  
  1232.  
  1233. ΓòÉΓòÉΓòÉ 11.1. x:/NOWHERE and NOTVISIBLE ΓòÉΓòÉΓòÉ
  1234.  
  1235. Nowhere contains objects "they" don't want you to mess with, e.g. the program 
  1236. object for view.exe that's associated with *.INF.  It also contains WarpCenter 
  1237. & LaunchPad shadows, some Netscape helper apps, plus objects for your COM, LPT, 
  1238. and remote printer ports.  It may also contain junk - some people may still 
  1239. have remnants left by the NSv4.61 beta.
  1240.  
  1241.  In Warp v4 (at least), you can't open Nowhere, display its menu, or show its 
  1242. properties notebook.  However, you *can* see its contents by running the script 
  1243. below, then opening your boot drive in tree view and pressing the "plus" button 
  1244. next to Nowhere's icon. (Note:  I've played with my system so much that YMMV 
  1245. greatly as to what you can see.  For example, mine always shows some objects; 
  1246. running the script below simply increases the number visible.)
  1247.  
  1248.  If you have more than one Nowhere directory, you should be able to identify 
  1249. the one in use by the presence of the port objects (assuming you can see them 
  1250. at all).  Another way is to use the folder's Object ID (<WP_NOWHERE>) rather 
  1251. than its path the first time you run the script. Whichever folder is expandable 
  1252. is the one in use.
  1253.  
  1254.  Put this in Boilerspace template: 
  1255.  
  1256.   /* this makes visible two objects that are normally hidden */
  1257.   rc = SysSetObjectData( "<WP_VIEWINF>","NOTVISIBLE=NO")
  1258.   rc = SysSetObjectData( "<WP_RJAPPLETPROGREF>","NOTVISIBLE=NO")
  1259.  
  1260.   /* substitute <WP_NOWHERE> for the path on the first run to
  1261.      help identify which of several Nowhere folders the WPS is
  1262.      actually using */
  1263.   call ReportRC(SysSetObjectData( "C:\NOWHERE","SHOWALLINTREEVIEW=YES"))
  1264.  Go Up 
  1265.  
  1266.  
  1267. ΓòÉΓòÉΓòÉ 11.2. SHOWALLINTREEVIEW ΓòÉΓòÉΓòÉ
  1268.  
  1269. SHOWALLINTREEVIEW=YES ?  What does this do, and where is this statement placed 
  1270. ? If this does what I think it does, I'll be wondering why the hell IBM didn't 
  1271. make this default.
  1272.  
  1273.  This causes folders to display all their contents in Tree view, rather than 
  1274. just subfolders.  You can apply this attribute to any folder using this REXX 
  1275. script.  Supply the name of a directory when you run it (e.g. SHOWALL 
  1276. C:\DESKTOP), or simply drop a folder on its icon.
  1277.  
  1278.  Put this in Boilerspace template: 
  1279.  
  1280.   call ReportRC(SysSetObjectData(object,"SHOWALLINTREEVIEW=YES"))
  1281.  Go Up 
  1282.  
  1283.  
  1284. ΓòÉΓòÉΓòÉ 11.3. SHOWALLINTREEVIEW and old (Warp 3) folders ΓòÉΓòÉΓòÉ
  1285.  
  1286. The ability to show a folder's entire contents was added in Warp v4, but 
  1287. nothing was added to the folder notebook to turn this on.  Instead, you have to 
  1288. use REXX;  the script in SHOWALLINTREEVIEW will do the trick.  Go Up 
  1289.  
  1290.  
  1291. ΓòÉΓòÉΓòÉ 11.4. NODELETE and Templates ΓòÉΓòÉΓòÉ
  1292.  
  1293.   | >I have several objects that were created by Devcon. They are extremely
  1294.   | >annoying and I would like to be rid of them. Simple deletion doesn't work,
  1295.  so
  1296.   | Go to the 'general' page of the settings notebook.  Uncheck the
  1297.   | template checkbox, close the notebook and delete 'em.
  1298.  
  1299. That's not enough for the Warp Toolkit objects:  they are created with the 
  1300. object NODELETE attribute, which you can't get at from the WPS (unless you use 
  1301. an object inspection utility).
  1302.  
  1303.  You *can* zap them with REXX, though: 
  1304.  
  1305.   call RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SYSLOADFUNCS'
  1306.   call SysLoadFuncs
  1307.   call SysSetObjectData 'C:\Desktop\OS!2 System\Templates\Carpp', 'NODELETE=NO;'
  1308.  
  1309. Remove the Template attribute as above, then you can delete them.
  1310.  
  1311.  Ok, that partially worked...it makes the objects "deletable", but they come 
  1312. back after I delete them (i.e. Run script, Delete object, Close folder, Open 
  1313. folder, IT'S BAAAACK).  Any other ideas? Mayhaps a recommendation as to an 
  1314. "object inspection utility"? Preferrably one that will let me kill the objects?
  1315.  
  1316.  Every time you open the Templates folder, it populates itself with a template 
  1317. for every class that supports "Create Another".  If the template for a class is 
  1318. missing, it asks the class to create another.  The only way to permanently get 
  1319. rid of them is to deregister the class.  If that's what you want to do, add 
  1320. this line to the script above: 
  1321.  
  1322.     Call SysDeregisterObjectClass "[name of class]"
  1323.  
  1324. Run the script, delete the object, close the folder, restart the WPS. The 
  1325. template, the class, and any supporting os2.ini entries will be gone for good. 
  1326. Go Up 
  1327.  
  1328.  
  1329. ΓòÉΓòÉΓòÉ 12. .HLP not shown in view.exe ΓòÉΓòÉΓòÉ
  1330.  
  1331. IZ: applicable only to Warp 4 (view.exe would not open hlp, use viewhelp.exe).
  1332.  
  1333.  OTOH, if you can't dblclick on a HLP to open it in the right app, it's because 
  1334. HLP files don't have any pre-assigned association.  During installation, OS/2 
  1335. creates a hidden program object in your Nowhere folder (also hidden) and 
  1336. associates it with *.INF.  To access this object's notebook so you can add 
  1337. *.HLP to its associations, run this REXX script (Put this in Boilerspace 
  1338. template): 
  1339.  
  1340.   call ReportRC(SysSetObjectData("<WP_VIEWINF>","OPEN=SETTINGS"))
  1341.  
  1342. [Probably you need to make Nowhere visible first, see x:/NOWHERE and 
  1343. NOTVISIBLE.]  Go Up 
  1344.  
  1345.  
  1346. ΓòÉΓòÉΓòÉ 13. Drag & Drop of .dev and printers ΓòÉΓòÉΓòÉ
  1347.  
  1348. If you drag and drop a printer file it will assume you want to install it. I 
  1349. don't know the answer to your question though, but am also curios to know. I 
  1350. would just drop to the command line & copy it from there.
  1351.  
  1352.  When I responded to Timur's original posting, I suggested he go to the 
  1353. "Become" page of the file's notebook and change its class to WPDataFile. 
  1354. Contrary to my normal practice, I didn't fully test the results and was later 
  1355. reminded why I (almost) always test before posting:  when I went to drag my 
  1356. test file the next day, it wouldn't budge.  Even though the object's class had 
  1357. changed, its "style" settings hadn't.  The following REXX script fixes that. 
  1358. Just replace "C:\junk\test.drv" with the name of your problem file, then run it.
  1359.  
  1360.  Put this in Boilerspace template, see Open View IDs for DEFAULTVIEW=4: 
  1361.  
  1362.   call ReportRC(SysSetObjectData("C:\junk\test.drv", "NoMove=NO;NoLink=NO;NoCopy=NO;NoDrag=NO;DEFAULTVIEW=4;"))
  1363.  
  1364. BTW... do *not* move a real printer-driver file if you've installed one of the 
  1365. printers it supports.  Go Up 
  1366.  
  1367.  
  1368. ΓòÉΓòÉΓòÉ 14. Start a VIO window with a changed font size ΓòÉΓòÉΓòÉ
  1369.  
  1370. Here's a REXX script that does what's needed (on my system, at least). YMMV 
  1371. because of timing issues (i.e. it's possible that the font could get reset 
  1372. before the window uses this setting).
  1373.  
  1374.  Notice that I've included two different ways to invoke scache: by running it 
  1375. directly and by opening a program object that runs it. I feel more comfortable 
  1376. with the latter, but it requires that the pgm object have an Object ID (in this 
  1377. case "<SCACHE>").  I added mine after the fact using a feature of DTProgram. 
  1378.  
  1379.   /* SCACHE.CMD - saves old font size, sets a new size, */
  1380.   /* invokes smartcache, then restores old size         */
  1381.   /* note:  if the font is "14x8", y=14 & x=8           */
  1382.  
  1383.   call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  1384.   call SysLoadFuncs
  1385.  
  1386.   x = 8
  1387.   y = 8
  1388.  
  1389.   sav = SysIni('USER','Shield','~Font Size...')
  1390.   new = d2c(x) || d2c(y)
  1391.   rc = SysIni('USER','Shield','~Font Size...', new)
  1392.  
  1393.   /* OPEN PROGRAM OBJECT */
  1394.   rc = SysOpenObject('<SCACHE>','4','TRUE')
  1395.  
  1396.   /* RUN DIRECTLY */
  1397.   /* 'CD F:\JAVA11\SCACHE'
  1398.   'START F:\JAVA11\BIN\JAVA.EXE -ms1m scache' */
  1399.  
  1400.   rc = SysIni('USER','Shield','~Font Size...', sav)
  1401.  Go Up 
  1402.  
  1403.  
  1404. ΓòÉΓòÉΓòÉ 15. Desktop background ΓòÉΓòÉΓòÉ
  1405.  
  1406. Is there a way to find where the desktop's background is stored and change it? 
  1407. I've heard it's possible with the WinSetObjectData() function but I don't know 
  1408. how to do this?
  1409.  
  1410.  Yes, you do use WinSetObjectData(). You can find the relevant setup string in 
  1411. the WPS Programming Reference. e.g. 
  1412.  
  1413.   WinSetObjectData(WinQueryObject("<WP_DESKTOP>"),
  1414.     "BACKGROUND=c:\somewhere\something.bmp,T,1,I;");
  1415.  Go Up 
  1416.  
  1417.  
  1418. ΓòÉΓòÉΓòÉ 16. Properties of the root directory ΓòÉΓòÉΓòÉ
  1419.  
  1420. The easiest way to clear up problems in a root directory is to erase "WP ROOT. 
  1421. SF".  You'll have to turn off the hidden and system attributes and you may have 
  1422. to Alt-F1/boot to a command line to actually delete it (I don't recall).  After 
  1423. doing so, you'll have to open this drive's notebook and reset whatever 
  1424. properties you normally change (e.g. sort order, includes, etc).  Doing so will 
  1425. recreate this file.
  1426.  
  1427.  FYI...  Root directories have no EAs, so "WP ROOT.SF" provides an alternate 
  1428. means of storing WPS info.  The file itself contains the root's .CLASSINFO. 
  1429. Any other EAs that would be attached to a directory (e.g. .ICONPOS) are 
  1430. attached to this file instead.  Go Up 
  1431.  
  1432.  
  1433. ΓòÉΓòÉΓòÉ 17. PM_Workplace:Location ΓòÉΓòÉΓòÉ
  1434.  
  1435. See DragText.  Go Up 
  1436.  
  1437.  
  1438. ΓòÉΓòÉΓòÉ 18. PM_Workplace:Templates ΓòÉΓòÉΓòÉ
  1439.  
  1440. See Hanging template folder.  Go Up 
  1441.  
  1442.  
  1443. ΓòÉΓòÉΓòÉ 19. AUTHOR ΓòÉΓòÉΓòÉ
  1444.  
  1445. Compilation, editing, and tools info by Ilya Zakharevich.  The rest obtained 
  1446. from Google using the search string 
  1447.  
  1448.   classinfo extended attributes
  1449.  
  1450. and from Google groups with 
  1451.  
  1452.   classinfo extended attributes group:*.os2.*
  1453.   classinfo wps group:*.os2.*
  1454.   sysloadfuncs group:*.os2.* author:walsh
  1455.   classinfo group:*.os2.* author:walsh
  1456.  
  1457. Most prolific info-producer is Rich Walsh (with a giant margin). 
  1458.  
  1459.    http://www.usacomputers.net/personal/rlwalsh/
  1460.  
  1461. Particular chunks are not attributed to their authors, please look on Google 
  1462. again.  Go Up