home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 14 Text / 14-Text.zip / REDBOOK3.ZIP / GG243732.INF (.txt)
OS/2 Help File  |  1992-08-27  |  492KB  |  7,946 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. (C) Copyright IBM Corp. 1992 ΓòÉΓòÉΓòÉ
  3.  
  4. (C) Copyright International Business Machines Coporation 1992. All rights 
  5. reserved. 
  6.  
  7. Note to U.S. Government Users - Documentation related to restricted rights - 
  8. Use, duplication or disclosure is subject to restrictions set forth in GSA ADP 
  9. Schedule Contract with IBM Corp. 
  10.  
  11.  
  12. ΓòÉΓòÉΓòÉ 2. Cover ΓòÉΓòÉΓòÉ
  13.  
  14.  
  15. ΓòÉΓòÉΓòÉ <hidden> Title Page ΓòÉΓòÉΓòÉ
  16.  
  17.  
  18.                                                                 OS/2 Version 2.0
  19.                                                           Volume 3: Presentation
  20.                                                                      Manager and
  21.                                                                  Workplace Shell
  22.  
  23.                                                     Document Number GG24-3732-00
  24.  
  25.                                                                       April 1992
  26.  
  27.  
  28.                                                          International Technical
  29.                                                                   Support Center
  30.  
  31.                                                                       Boca Raton
  32.  
  33.  
  34. ΓòÉΓòÉΓòÉ 3. Version Notice ΓòÉΓòÉΓòÉ
  35.  
  36. Take Note:  Before using this information and the product it supports, be sure 
  37.             to read the general information under Special Notices. 
  38.  
  39. First Edition (April 1992) 
  40.  
  41. This edition applies to OS/2 Version 2.0. 
  42.  
  43. Order publications through your IBM representative or the IBM branch office 
  44. serving your locality. Publications are not stocked at the address given below. 
  45.  
  46. A form for reader's comments appears at the back of this publication. If the 
  47. form has been removed, address your comments to: 
  48.  
  49. IBM Corporation, International Technical Support Center
  50. Dept. 91J, Building 235-2 Internal Zip 4423
  51. 901 NW 51st Street
  52. Boca Raton, Florida 33432 USA
  53.  
  54. When you send information to IBM, you grant IBM a non-exclusive right to use or 
  55. distribute the information in any way it believes appropriate without incurring 
  56. any obligation to you. 
  57.  
  58. MAK - Revision 1.0
  59.  
  60.  
  61. ΓòÉΓòÉΓòÉ 4. Abstract ΓòÉΓòÉΓòÉ
  62.  
  63. This document describes the Presentation Manager component of OS/2 Version 2.0. 
  64. It forms Volume 3 of a five volume set; the other volumes are: 
  65.  
  66.  OS/2 Version 2.0 - Volume 1:  Control Program, GG24-3730 
  67.  
  68.  OS/2 Version 2.0 - Volume 2:  DOS and Windows Environment, GG24-3731 
  69.  
  70.  OS/2 Version 2.0 - Volume 4:  Application Development, GG24-3774 
  71.  
  72.  OS/2 Version 2.0 - Volume 5:  Print Subsystem, GG24-3775 
  73.  
  74. The entire set may be ordered as OS/2 Version 2.0 Technical Compendium, 
  75. GBOF-2254. 
  76.  
  77. This document is intended for IBM system engineers, IBM authorized dealers, IBM 
  78. customers, and others who require a knowledge of Presentation Manager features, 
  79. functions, and implementation under OS/2 Version 2.0. 
  80.  
  81. This document assumes that the reader is generally familiar with the function 
  82. provided in previous releases of OS/2. 
  83.  
  84.  
  85. ΓòÉΓòÉΓòÉ 5. Acknowledgements ΓòÉΓòÉΓòÉ
  86.  
  87. The project leaders and editors for this project were: 
  88.  
  89. Hans J. Goetz
  90. International Technical Support Center, Boca Raton
  91.  
  92. Giffin Lorimer
  93. International Technical Support Center, Boca Raton
  94.  
  95. The authors of this document are: 
  96.  
  97. Alan Chambers
  98. IBM United Kingdom
  99.  
  100. Karsten D╨æring
  101. IBM Germany
  102.  
  103. Gert Ehing
  104. IBM Germany
  105.  
  106. Franco Federico
  107. IBM United Kingdom
  108.  
  109. Dennis Lock
  110. ISM, South Africa
  111.  
  112. Joachim M╨æller
  113. IBM Germany
  114.  
  115. Jouko Ruuskanen
  116. IBM Finland
  117.  
  118. Neil Stokes
  119. IBM Australia
  120.  
  121. Katsutoshi Suzuki
  122. IBM Japan
  123.  
  124. This publication is the result of a series of residencies conducted at the 
  125. International Technical Support Center, Boca Raton. 
  126.  
  127. This document was converted to the Information Presentation Facility by: 
  128.  
  129. Michael Kaply
  130. IBM Development Laboratories, Austin.
  131.  
  132. Thanks to the following people for the invaluable advice and guidance provided 
  133. in the production of this document: 
  134.  
  135. Lori Brown
  136. IBM Programming Center, Boca Raton.
  137.  
  138. Sam Casto and his staff
  139. IBM Programming Center, Boca Raton.
  140.  
  141. Ann Ford
  142. IBM Programming Center, Boca Raton.
  143.  
  144. Alfredo Guti╨Ærrez
  145. IBM EMEA Education Center, Boca Raton.
  146.  
  147. Steve Robinson and his staff
  148. IBM PRGS, Cary.
  149.  
  150. David Kerr
  151. IBM Programming Center, Boca Raton.
  152.  
  153. Peter Magid
  154. IBM Programming Center, Boca Raton.
  155.  
  156. Michael Perks
  157. IBM Programming Center, Boca Raton.
  158.  
  159. Tom Richards
  160. IBM PRGS, Cary
  161.  
  162. Thanks also to the many people, both within and outside IBM, who provided 
  163. suggestions and guidance, and who reviewed this document prior to publication. 
  164.  
  165. Thanks to the following people who created the excellent tools used during the 
  166. production of this document: 
  167.  
  168. Dave Hock (CUA Draw)
  169. IBM PRGS, Carry.
  170.  
  171. J╨ærg von K╨önel (PM Camera)
  172. IBM Yorktown Heights.
  173.  
  174. Georg Haschek (BM2IPF)
  175. IBM Austria.
  176.  
  177.  
  178. ΓòÉΓòÉΓòÉ 6. Figures ΓòÉΓòÉΓòÉ
  179.  
  180.  Presentation Manager Window 
  181.  Presentation Manager Dialog Box 
  182.  Presentation Manager Message Box 
  183.  Clipboard Copy from an OS/2 Window into an OS/2 PM Editor 
  184.  Container Control Used in Folder Window 
  185.  Presentation Manager Notebook for Desktop Setting 
  186.  Presentation Manager Notebook used in Master Help Index 
  187.  Slider Control 
  188.  Value Set Control 
  189.  Progress Indicator Control 
  190.  Standard File Dialog for "Open" 
  191.  Standard Font Dialog 
  192.  Workplace Shell Desktop Appearance 
  193.  Different Views of the Same Objects 
  194.  System Setup 
  195.  Keyboard Settings Notebook 
  196.  Workplace with Objects 
  197.  Local Drives and LAN Drives 
  198.  Shredder Object With A Folder For Deletion 
  199.  Job List View of Print Object 
  200.  Templates After Full Installation 
  201.  Example of a Folder With User Templates 
  202.  Example of a Menu Showing the Association 
  203.  Tree View of the LAN Server 
  204.  Different Objects - Different Functions 
  205.  Expanded Desktop Menu 
  206.  Setup of an Expanded Menu 
  207.  Starting XCOPY From the First Line in CONFIG.SYS to Back Up the INI Files 
  208.  Building Back Up History of the INI Files from STARTUP.CMD 
  209.  A REXX Procedure To Prevent Programs Restarting 
  210.  REXX Procedure for Host Upload 
  211.  REXX Procedure to Create a New Folder 
  212.  REXX Procedure to Add a Program to a Folder 
  213.  REXX Procedure to Register a New WPS Class 
  214.  REXX Procedure to Deregister a WPS Class 
  215.  Workplace Shell Quotations Work Area 
  216.  Presentation Manager Application Structure 
  217.  Message Queues 
  218.  Workplace Shell Class Hierarchy 
  219.  An ASSOCTABLE Resource Script File Statement 
  220.  Disk Structure Supporting the Workplace Shell 
  221.  Drag/Drop - Physical Implementation 
  222.  Relationship of Folder to Directory and OS2.INI File 
  223.  Effect of Changing Description on HPFS file names 
  224.  Effect of Copying Files on Filenames 
  225.  
  226.  
  227. ΓòÉΓòÉΓòÉ 6.1. Presentation Manager Window ΓòÉΓòÉΓòÉ
  228.  
  229.  
  230. ΓòÉΓòÉΓòÉ 6.2. Presentation Manager Dialog Box ΓòÉΓòÉΓòÉ
  231.  
  232.  
  233. ΓòÉΓòÉΓòÉ 6.3. Presentation Manager Message Box ΓòÉΓòÉΓòÉ
  234.  
  235.  
  236. ΓòÉΓòÉΓòÉ 6.4. Clipboard Copy from an OS/2 Window into an OS/2 PM Editor ΓòÉΓòÉΓòÉ
  237.  
  238.  
  239. ΓòÉΓòÉΓòÉ 6.5. Container Control Used in Folder Window ΓòÉΓòÉΓòÉ
  240.  
  241.  
  242. ΓòÉΓòÉΓòÉ 6.6. Presentation Manager Notebook for Desktop Setting ΓòÉΓòÉΓòÉ
  243.  
  244.  
  245. ΓòÉΓòÉΓòÉ 6.7. Presentation Manager Notebook used in Master Help Index ΓòÉΓòÉΓòÉ
  246.  
  247.  
  248. ΓòÉΓòÉΓòÉ 6.8. Slider Control ΓòÉΓòÉΓòÉ
  249.  
  250.  
  251. ΓòÉΓòÉΓòÉ 6.9. Value Set Control ΓòÉΓòÉΓòÉ
  252.  
  253.  
  254. ΓòÉΓòÉΓòÉ 6.10. Progress Indicator Control ΓòÉΓòÉΓòÉ
  255.  
  256.  
  257. ΓòÉΓòÉΓòÉ 6.11. Standard File Dialog for "Open" ΓòÉΓòÉΓòÉ
  258.  
  259.  
  260. ΓòÉΓòÉΓòÉ 6.12. Standard Font Dialog ΓòÉΓòÉΓòÉ
  261.  
  262.  
  263. ΓòÉΓòÉΓòÉ 6.13. Workplace Shell Desktop Appearance ΓòÉΓòÉΓòÉ
  264.  
  265.  
  266. ΓòÉΓòÉΓòÉ 6.14. Different Views of the Same Objects ΓòÉΓòÉΓòÉ
  267.  
  268.  
  269. ΓòÉΓòÉΓòÉ 6.15. System Setup ΓòÉΓòÉΓòÉ
  270.  
  271.  
  272. ΓòÉΓòÉΓòÉ 6.16. Keyboard Settings Notebook ΓòÉΓòÉΓòÉ
  273.  
  274.  
  275. ΓòÉΓòÉΓòÉ 6.17. Workplace with Objects ΓòÉΓòÉΓòÉ
  276.  
  277.  
  278. ΓòÉΓòÉΓòÉ 6.18. Local Drives and LAN Drives ΓòÉΓòÉΓòÉ
  279.  
  280.  
  281. ΓòÉΓòÉΓòÉ 6.19. Shredder Object With A Folder For Deletion ΓòÉΓòÉΓòÉ
  282.  
  283.  
  284. ΓòÉΓòÉΓòÉ 6.20. Job List View of Print Object ΓòÉΓòÉΓòÉ
  285.  
  286.  
  287. ΓòÉΓòÉΓòÉ 6.21. Templates After Full Installation ΓòÉΓòÉΓòÉ
  288.  
  289.  
  290. ΓòÉΓòÉΓòÉ 6.22. Example of a Folder With User Templates ΓòÉΓòÉΓòÉ
  291.  
  292.  
  293. ΓòÉΓòÉΓòÉ 6.23. Example of a Menu Showing the Association ΓòÉΓòÉΓòÉ
  294.  
  295.  
  296. ΓòÉΓòÉΓòÉ 6.24. Tree View of the LAN Server ΓòÉΓòÉΓòÉ
  297.  
  298.  
  299. ΓòÉΓòÉΓòÉ 6.25. Different Objects - Different Functions ΓòÉΓòÉΓòÉ
  300.  
  301.  
  302. ΓòÉΓòÉΓòÉ 6.26. Expanded Desktop Menu ΓòÉΓòÉΓòÉ
  303.  
  304.  
  305. ΓòÉΓòÉΓòÉ 6.27. Setup of an Expanded Menu ΓòÉΓòÉΓòÉ
  306.  
  307.  
  308. ΓòÉΓòÉΓòÉ 6.28. Starting XCOPY From the First Line in CONFIG.SYS to Back Up the INI Files ΓòÉΓòÉΓòÉ
  309.  
  310. RUN=C:\OS2\XCOPY.EXE C:\OS2\OS2*.INI C:\OS2\INSTALL
  311.  
  312.  
  313. ΓòÉΓòÉΓòÉ 6.29. Building Back Up History of the INI Files from STARTUP.CMD ΓòÉΓòÉΓòÉ
  314.  
  315. REM *** Build Backup History ***
  316. C:
  317. CD \OS2\INSTALL
  318. COPY OS2.3 OS2.OLD
  319. COPY OS2.2 OS2.3
  320. COPY OS2.1 OS2.2
  321. COPY OS2.INI OS2.1
  322. COPY OS2SYS.3 OS2SYS.OLD
  323. COPY OS2SYS.2 OS2SYS.3
  324. COPY OS2SYS.1 OS2SYS.2
  325. COPY OS2SYS.INI OS2SYS.1
  326. CD\
  327. REM *** That's all folks ... ***
  328.  
  329.  
  330. ΓòÉΓòÉΓòÉ 6.30. A REXX Procedure To Prevent Programs Restarting ΓòÉΓòÉΓòÉ
  331.  
  332. /* Clear startup programs from OS2.INI */
  333. call RxFuncAdd 'SysIni','RexxUtil','SysIni'
  334. call SysIni,'PM_WorkPlace:Restart','DELETE:'
  335. call SysIni,'FolderworkareaRunningObjects','DELETE:'
  336.  
  337.  
  338. ΓòÉΓòÉΓòÉ 6.31. REXX Procedure for Host Upload ΓòÉΓòÉΓòÉ
  339.  
  340. /*put a file on the host*/
  341. '@echo off'
  342. arg file
  343. lastdot=lastpos('.',file)
  344. lastbslash=lastpos('\',file)
  345. ext=substr(file,lastdot+1) fn=substr(file,lastbslash+1,
  346. lastdot-lastbslash-1)
  347. select
  348. when ext='SCR'  then ft='SCRIPT'
  349. when ext='TXT'  then ft='TEXT'
  350. when ext='PSE'  then ft='PSEBIN'
  351. when ext='BMP'  then ft='BMPBIN'
  352. otherwise  ft=ext
  353. end
  354. select
  355. when ext='SCR'  then opt=asc
  356. when ext='TXT'  then opt=asc
  357. when ext='CMD'  then opt=asc
  358. when fn='CONFIG' & ext='SYS'  then opt=asc
  359. when ext='BAT'  then opt=asc
  360. when ext='RC'  then opt=asc
  361. otherwise  opt='(RECFM V'
  362. end
  363. if opt=asc then
  364. opt='(ASCII CRLF RECFM V LRECL 255' 'SEND' file fn ft 'A' opt
  365. 'exit'
  366.  
  367.  
  368. ΓòÉΓòÉΓòÉ 6.32. REXX Procedure to Create a New Folder ΓòÉΓòÉΓòÉ
  369.  
  370. RetCode = SysCreateObject( "WPFolder",,
  371.                            "MyFolder",,
  372.                            "<WP_DESKTOP>",,
  373.                            "OBJECTID=<MYFOLDER>")
  374.  
  375. if RetCode then
  376.    say 'Folder Object created'
  377. else do
  378.    say 'Error creating object'
  379.    exit(1)
  380.    end
  381.  
  382.  
  383. ΓòÉΓòÉΓòÉ 6.33. REXX Procedure to Add a Program to a Folder ΓòÉΓòÉΓòÉ
  384.  
  385. RetCode = SysCreateObject( "WPProgram",,
  386.                            "Editor",,
  387.                            "<MYFOLDER>",,
  388.                            "PROGTYPE=PM;EXENAME=C:\OS2\E.EXE;")
  389.  
  390. if RetCode then
  391.    say 'Program Object created'
  392. else do
  393.    say 'Error creating object'
  394.    exit(1)
  395.    end
  396.  
  397.  
  398. ΓòÉΓòÉΓòÉ 6.34. REXX Procedure to Register a New WPS Class ΓòÉΓòÉΓòÉ
  399.  
  400. RetCode = SysRegisterObjectClass( "PWFolder", "pwfolder")
  401.  
  402. if RetCode then
  403.    say 'PWFolder Class registered'
  404. else do
  405.    say 'Error PWFolder Class failed to register'
  406.    exit(1)
  407.    end
  408.  
  409.  
  410. ΓòÉΓòÉΓòÉ 6.35. REXX Procedure to Deregister a WPS Class ΓòÉΓòÉΓòÉ
  411.  
  412. RetCode = SysDeregisterObjectClass( "PWFolder");
  413.  
  414. if RetCode then
  415.     say 'Uninstall successfully completed for PWFolder class'
  416.  
  417. say 'Re-boot NOW in order to release DLL'
  418.  
  419.  
  420. ΓòÉΓòÉΓòÉ 6.36. Workplace Shell Quotations Work Area ΓòÉΓòÉΓòÉ
  421.  
  422. We apologize for the quality.  The original was not available. 
  423.  
  424.  
  425. ΓòÉΓòÉΓòÉ 6.37. Presentation Manager Application Structure ΓòÉΓòÉΓòÉ
  426.  
  427.  
  428. ΓòÉΓòÉΓòÉ 6.38. Message Queues ΓòÉΓòÉΓòÉ
  429.  
  430.  
  431. ΓòÉΓòÉΓòÉ 6.39. Workplace Shell Class Hierarchy ΓòÉΓòÉΓòÉ
  432.  
  433.  
  434. ΓòÉΓòÉΓòÉ 6.40. An ASSOCTABLE Resource Script File Statement ΓòÉΓòÉΓòÉ
  435.  
  436. ASSOCTABLE 5 PRELOAD
  437. BEGIN
  438.     "Expense form", "*.exp", EAF_DEFAULTOWNER, expenses.ico
  439. END
  440.  
  441.  
  442. ΓòÉΓòÉΓòÉ 6.41. Disk Structure Supporting the Workplace Shell ΓòÉΓòÉΓòÉ
  443.  
  444. C:\OS!2 2.0 DESKTOP
  445.      Γö£ΓöÇΓöÇΓöÇΓöÇ\DOCUMENTS
  446.      Γöé   Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇ\SCRIPTFILES
  447.      Γöé   Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇ\PERSONAL
  448.      Γöé   ΓööΓöÇΓöÇΓöÇΓöÇΓöÇ\1992PLAN
  449.      Γö£ΓöÇΓöÇΓöÇΓöÇ\DRAWINGS
  450.      Γö£ΓöÇΓöÇΓöÇΓöÇ\MYFOLDER
  451.      Γö£ΓöÇΓöÇΓöÇΓöÇ\TEMPLATES
  452.      Γö£ΓöÇΓöÇΓöÇΓöÇ\1991SPREADSHEETS
  453.      ΓööΓöÇΓöÇΓöÇΓöÇ\1992SPREADSHEETS
  454.  
  455.  
  456. ΓòÉΓòÉΓòÉ 6.42. Drag/Drop - Physical Implementation ΓòÉΓòÉΓòÉ
  457.  
  458. We apologize for the picture quality.  The original was not available. 
  459.  
  460.  
  461. ΓòÉΓòÉΓòÉ 6.43. Relationship of Folder to Directory and OS2.INI File ΓòÉΓòÉΓòÉ
  462.  
  463.        OS2.INI           MyFolder (EA)
  464.   ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ    ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ    ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  465.   Γöé                Γöé    Γöé H1 H3          Γöé    Γöé MyFolder     Γöé
  466.   Γöé AbstObj1 H1    Γöé    Γöé                Γöé    Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  467.   Γöé AbstObj2 H2    Γöé    Γöé                Γöé    Γöé              Γöé
  468.   Γöé AbstObj3 H3    Γöé    Γöé                Γöé    Γöé IH1 IF1 IH3  Γöé
  469.   Γöé ...            Γöé    ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ    Γöé              Γöé
  470.   Γöé                Γöé    \MyFolder (directory) Γöé  IF2 IF3     Γöé
  471.   Γöé MyFolder       Γöé    ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ    Γöé              Γöé
  472.   Γöé H1 H3          Γöé    Γöé                Γöé    Γöé IF4          Γöé
  473.   Γöé                Γöé    Γöé File1          Γöé    Γöé              Γöé
  474.   Γöé Folder2        Γöé    Γöé File2          Γöé    Γöé              Γöé
  475.   Γöé H2 H4          Γöé    Γöé File3          Γöé    ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  476.   Γöé ...            Γöé    Γöé File4          Γöé
  477.   Γöé                Γöé    Γöé ...            Γöé
  478.   Γöé                Γöé    Γöé                Γöé
  479.   Γöé                Γöé    ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  480.   ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  481.  
  482.  
  483. ΓòÉΓòÉΓòÉ 6.44. Effect of Changing Description on HPFS file names ΓòÉΓòÉΓòÉ
  484.  
  485.  
  486.       ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ                                  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  487.       Γöé     Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ                            Γöé     Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  488.       ΓöéICON Γöé     Γöé                            ΓöéICON Γöé     Γöé
  489.       ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ     Γöé                            ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ     Γöé
  490.    ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ  Γöé  Change description     ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ  Γöé
  491.    ΓöéOldFilenameΓö£ΓöÇΓöÉΓöé  ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ   Γöé Myfile    Γö£ΓöÇΓöÉΓöé
  492.    ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓöéΓöé  to "Myfile"            ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓöéΓöé
  493.                  ΓöéΓöé                                       ΓöéΓöé
  494.                  ΓöéΓöé                                       ΓöéΓöé
  495.                  ΓöéΓöé                                       ΓöéΓöé
  496.                                                         
  497.     ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÉ                        ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÉ
  498.     Γöé FILE   Γöé Γöé EA Γöé                        Γöé FILE   Γöé Γöé EA Γöé
  499.     ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓööΓöÇΓöÇΓöÇΓöÇΓöÿ                        ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓööΓöÇΓöÇΓöÇΓöÇΓöÿ
  500.     OldFilename.XYZ                          Myfile.XYZ
  501.  
  502.  
  503. ΓòÉΓòÉΓòÉ 6.45. Effect of Copying Files on Filenames ΓòÉΓòÉΓòÉ
  504.  
  505.  
  506.      Copy to Folder2       Copy back to Folder1
  507.      ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ   ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
  508.      Γöé                     Γöé
  509.  ΓöîΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÉ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÉ     ΓöîΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÉ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÉ         ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ ΓöîΓöÇΓöÇΓöÇΓöÇΓöÉ
  510.  Γöé FILE   Γöé Γöé EA Γöé     Γöé FILE   Γöé Γöé EA Γöé         Γöé FILE   Γöé Γöé EA Γöé
  511.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓööΓöÇΓöÇΓöÇΓöÇΓöÿ     ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓööΓöÇΓöÇΓöÇΓöÇΓöÿ         ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ ΓööΓöÇΓöÇΓöÇΓöÇΓöÿ
  512.   ABCD.XYZ              ABCD.XYZ                 ABCD1.XYZ
  513.  
  514.  
  515. ΓòÉΓòÉΓòÉ 7. Tables ΓòÉΓòÉΓòÉ
  516.  
  517.  Mouse Button Settings 
  518.  Workplace Shell Object Persistence Summary 
  519.  Fundamental Items 
  520.  Recommended Items 
  521.  
  522.  
  523. ΓòÉΓòÉΓòÉ 7.1. Mouse Button Settings ΓòÉΓòÉΓòÉ
  524.  
  525.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  526.  Γöé FUNCTION              Γöé MOUSE BUTTON - ACTION               Γöé
  527.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  528.  Γöé Select                Γöé mb1 - Click                         Γöé
  529.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  530.  Γöé Open icon to window   Γöé mb1 - Double-click                  Γöé
  531.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  532.  Γöé Context (pop-up) menu Γöé mb2 - Click                         Γöé
  533.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  534.  Γöé Edit icon description Γöé Alt - Down plus select              Γöé
  535.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  536.  Γöé Drag                  Γöé mb2 - Down on source                Γöé
  537.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  538.  Γöé Drop                  Γöé mb2 - Up on target                  Γöé
  539.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  540.  Γöé Drag and drop         Γöé mb2 - Down then mb2 - Up            Γöé
  541.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  542.  Γöé Create on drag        Γöé Ctrl -Down plus drag and drop       Γöé
  543.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  544.  Γöé Create shadow         Γöé Ctrl - Down plus Shift - Down       Γöé
  545.  Γöé                       Γöé             plus drag and drop      Γöé
  546.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  547.  Γöé Change desktop scheme Γöé Alt - Down plus drag and drop       Γöé
  548.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  549.  Γöé Window List           Γöé mb1 plus mb2 - Click simultaneously Γöé
  550.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  551.      mb1 = mouse button 1, mb2 = mouse button 2 
  552.  
  553. Note:   To click simultaneously on mb1 plus mb2 is called "chording" 
  554.  
  555.  
  556. ΓòÉΓòÉΓòÉ 7.2. Workplace Shell Object Persistence Summary ΓòÉΓòÉΓòÉ
  557.  
  558.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  559.  Γöé TYPE OF      Γöé OBJECT    Γöé CONTENTS   Γöé SETTINGS  Γöé PROGRAM  Γöé
  560.  Γöé OBJECT       Γöé LOCATION  Γöé            Γöé           Γöé OPTIONS  Γöé
  561.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  562.  Γöé Data file    Γöé File      Γöé File       Γöé File EAs  Γöé          Γöé
  563.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  564.  Γöé Program file Γöé File      Γöé File       Γöé File EAs  Γöé Set by   Γöé
  565.  Γöé              Γöé           Γöé            Γöé           Γöé program  Γöé
  566.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  567.  Γöé Shadow       Γöé OS2.INI   Γöé Original   Γöé Original  Γöé          Γöé
  568.  Γöé              Γöé           Γöé file       Γöé file      Γöé          Γöé
  569.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  570.  Γöé Prog. ref.   Γöé OS2.INI   Γöé Original   Γöé OS2.INI   Γöé Original Γöé
  571.  Γöé              Γöé           Γöé file       Γöé           Γöé program  Γöé
  572.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  573.  Γöé Folder       Γöé Directory Γöé Directory, Γöé Directory Γöé          Γöé
  574.  Γöé              Γöé           Γöé OS2.INI    Γöé EAs       Γöé          Γöé
  575.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  576.  
  577.  
  578. ΓòÉΓòÉΓòÉ 7.3. Fundamental Items ΓòÉΓòÉΓòÉ
  579.  
  580. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  581. Γöé Fundamental Items                                                       Γöé
  582. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  583. Γöé DESCRIPTION                                                  Γöé REFER-   Γöé
  584. Γöé    PROBLEM STATEMENT                                         Γöé ENCE     Γöé
  585. Γöé    RECOMMENDATIONS/ALTERNATIVES                              Γöé PAGE     Γöé
  586. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  587. Γöé There are several areas where OS/2 V2.0 mouse behavior is    Γöé 153/G13, Γöé
  588. Γöé inconsistent with that described in CUA 91.                  Γöé 184/G2,  Γöé
  589. Γöé                                                              Γöé 257/G10  Γöé
  590. Γöé In general, applications should follow OS/2 for UI           Γöé          Γöé
  591. Γöé consistency since consistency between OS/2 and application   Γöé          Γöé
  592. Γöé is of primary importance to users.  However, they must use   Γöé          Γöé
  593. Γöé logical messages rather than responding to particular mouse  Γöé          Γöé
  594. Γöé buttons, so that user customization, or a future change in   Γöé          Γöé
  595. Γöé OS/2, will automatically be reflected in the application.    Γöé          Γöé
  596. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  597. Γöé OS/2 does not contain visible menu bars on object container  Γöé 141/G2   Γöé
  598. Γöé windows.  Lack of menu bars is likely to cause coexistence   Γöé          Γöé
  599. Γöé and migration difficulties.  Testing also indicates that     Γöé          Γöé
  600. Γöé users prefer to have menu bars present.                      Γöé          Γöé
  601. Γöé                                                              Γöé          Γöé
  602. Γöé Applications have control over the window frame and should   Γöé          Γöé
  603. Γöé therefore provide menu bars.                                 Γöé          Γöé
  604. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  605. Γöé OS/2 has merged the system menu icon and title bar icon      Γöé 113/G3,  Γöé
  606. Γöé along with some of their functions.  Title bar icons, when   Γöé 253/W1   Γöé
  607. Γöé provided, must behave as a manipulable item which behaves    Γöé and      Γöé
  608. Γöé the same as the object's icon; the merged icon in OS/2 does  Γöé Defi-    Γöé
  609. Γöé not exhibit this behavior.                                   Γöé nition   Γöé
  610. Γöé                                                              Γöé          Γöé
  611. Γöé One problem with this is that the consistency of the OO user Γöé          Γöé
  612. Γöé interface, which requires clear separation of model, view    Γöé          Γöé
  613. Γöé and controller functions, is reduced.  Many applications     Γöé          Γöé
  614. Γöé will choose not to add a separate title bar icon because the Γöé          Γöé
  615. Γöé title bar will then present two identical icons side-by-side;Γöé          Γöé
  616. Γöé they look the same but act differently.                      Γöé          Γöé
  617. Γöé                                                              Γöé          Γöé
  618. Γöé Unless an application has subclassed WPS objects, such as    Γöé          Γöé
  619. Γöé Folders, they have control over the System Menu contents and Γöé          Γöé
  620. Γöé should conform to CUA 91.  If a program provides a title bar Γöé          Γöé
  621. Γöé icon then it must conform to CUA rules.                      Γöé          Γöé
  622. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  623. Γöé OS/2 does not allow users to change the view in a window.    Γöé 268/W1   Γöé
  624. Γöé The IBM Systems Application Architecture CUA Advanced        Γöé          Γöé
  625. Γöé Interface Design Reference requires applications to support  Γöé          Γöé
  626. Γöé changing the view in a window, so that users are not forced  Γöé          Γöé
  627. Γöé to open another window onto the same object.                 Γöé          Γöé
  628. Γöé                                                              Γöé          Γöé
  629. Γöé Applications have control over views and should follow the   Γöé          Γöé
  630. Γöé CUA architecture recommendations.                            Γöé          Γöé
  631. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  632. Γöé OS/2 has implemented "conditional" cascade menus which       Γöé 36/G1    Γöé
  633. Γöé behave differently from CUA rules on cascade menus.          Γöé          Γöé
  634. Γöé Selecting a cascading choice can cause a default action to   Γöé          Γöé
  635. Γöé occur unless the user clicks on the arrow portion of the     Γöé          Γöé
  636. Γöé choice.                                                      Γöé          Γöé
  637. Γöé                                                              Γöé          Γöé
  638. Γöé The CUA architecture recommends avoiding conditional cascade Γöé          Γöé
  639. Γöé menus.                                                       Γöé          Γöé
  640. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  641. Γöé OS/2 currently does not display scroll bars in windows if    Γöé 216/W1,  Γöé
  642. Γöé all objects are displayed.  CUA maintains that scroll bars   Γöé W2, G2   Γöé
  643. Γöé must always be displayed, following unavailable-state        Γöé          Γöé
  644. Γöé emphasis guidelines; this presents the user with a visual    Γöé          Γöé
  645. Γöé cue that the object extends beyond the window boundary.      Γöé          Γöé
  646. Γöé                                                              Γöé          Γöé
  647. Γöé If the application has implemented its own container         Γöé          Γöé
  648. Γöé control, then it should conform to the CUA guidelines.       Γöé          Γöé
  649. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  650. Γöé DOS Session Settings uses a scroll bar to set numeric values Γöé 216/G3   Γöé
  651. Γöé for such things as FILES, FCBS, RMSIZE, etc.  This is        Γöé          Γöé
  652. Γöé inconsistent with the behavior of scroll bars in windows.    Γöé          Γöé
  653. Γöé                                                              Γöé          Γöé
  654. Γöé Both slider or spin button controls are available in OS/2    Γöé          Γöé
  655. Γöé V2.0 should be used to set numeric values; scroll bars       Γöé          Γöé
  656. Γöé should only be used for scrolling.                           Γöé          Γöé
  657. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  658. Γöé Message windows must have title bars and correct window      Γöé 272/G1   Γöé
  659. Γöé frames.  Some OS/2 message windows lack these features.      Γöé          Γöé
  660. Γöé                                                              Γöé          Γöé
  661. Γöé Since applications have control over the generation of these Γöé          Γöé
  662. Γöé windows they should conform to CUA guidelines.               Γöé          Γöé
  663. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  664.  
  665.  
  666. ΓòÉΓòÉΓòÉ 7.4. Recommended Items ΓòÉΓòÉΓòÉ
  667.  
  668. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  669. Γöé Recommended Items                                                       Γöé
  670. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  671. Γöé DESCRIPTION                                         Γöé REFER-  Γöé DEPEND- Γöé
  672. Γöé    PROBLEM STATEMENT                                Γöé ENCE    Γöé ENCY ON Γöé
  673. Γöé    RECOMMENDATIONS/ALTERNATIVES                     Γöé PAGE    Γöé OS/2    Γöé
  674. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  675. Γöé OS/2 does not provide a separate title bar icon.    Γöé 272/G2, Γöé YES     Γöé
  676. Γöé Thse are recommended by the CUA architecture.       Γöé 113/G3  Γöé         Γöé
  677. Γöé                                                     Γöé         Γöé         Γöé
  678. Γöé Many programs will wish to wait until this is       Γöé         Γöé         Γöé
  679. Γöé supported in OS/2.                                  Γöé         Γöé         Γöé
  680. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  681. Γöé Changing a folder into a work area and vice versa   Γöé 114/G2  Γöé YES     Γöé
  682. Γöé should result in an immediate change in visual      Γöé         Γöé         Γöé
  683. Γöé appearance of the object icon.                      Γöé         Γöé         Γöé
  684. Γöé                                                     Γöé         Γöé         Γöé
  685. Γöé If a program implements its own containers using    Γöé         Γöé         Γöé
  686. Γöé the container control, it should adhere to CUA      Γöé         Γöé         Γöé
  687. Γöé guidelines, but most applications will probably     Γöé         Γöé         Γöé
  688. Γöé prefer to use the OS/2 facilities.                  Γöé         Γöé         Γöé
  689. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  690. Γöé OS/2 does not always provide progress indicators    Γöé 191/W1  Γöé NO      Γöé
  691. Γöé during lengthy operations which indicate percent    Γöé         Γöé         Γöé
  692. Γöé completion, and allow users to halt system          Γöé         Γöé         Γöé
  693. Γöé execution.                                          Γöé         Γöé         Γöé
  694. Γöé                                                     Γöé         Γöé         Γöé
  695. Γöé Applications should provide these progress          Γöé         Γöé         Γöé
  696. Γöé indicators.  OS/2 does provide controls for         Γöé         Γöé         Γöé
  697. Γöé implementing progress indicators.                   Γöé         Γöé         Γöé
  698. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  699. Γöé OS/2 does not provide and use an information area   Γöé 119/W1  Γöé NO      Γöé
  700. Γöé in its windows.  These are very useful in providing Γöé         Γöé         Γöé
  701. Γöé timely feedback to users.                           Γöé         Γöé         Γöé
  702. Γöé                                                     Γöé         Γöé         Γöé
  703. Γöé Adherence to CUA is required.                       Γöé         Γöé         Γöé
  704. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  705. Γöé OS/2 does not display a count of objects in         Γöé 51/G7   Γöé YES     Γöé
  706. Γöé containers.  The container control keeps track of   Γöé         Γöé         Γöé
  707. Γöé count (CM_QUERYCNRINFO).  However, OS/2 does not    Γöé         Γöé         Γöé
  708. Γöé display it on WPS containers.                       Γöé         Γöé         Γöé
  709. Γöé                                                     Γöé         Γöé         Γöé
  710. Γöé If a program implements its own containers using    Γöé         Γöé         Γöé
  711. Γöé the container control, it should adhere to CUA      Γöé         Γöé         Γöé
  712. Γöé guidelines, but most applications will probably     Γöé         Γöé         Γöé
  713. Γöé prefer to use the OS/2 facilities.                  Γöé         Γöé         Γöé
  714. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  715.  
  716.  
  717. ΓòÉΓòÉΓòÉ 8. Special Notices ΓòÉΓòÉΓòÉ
  718.  
  719. This publication is intended to help customers and system engineers to 
  720. understand and utilize the new features in Version 2.0 of OS/2. The information 
  721. in this publication is not intended as the specification of the programming 
  722. interfaces that are provided by OS/2 V2.0, Presentation Manager and the 
  723. Workplace Shell. See the PUBLICATIONS SECTION of the IBM Programming 
  724. Announcement for OS/2 Version 2.0 for more information about what publications 
  725. are considered to be product documentation. 
  726.  
  727. References in this publication to IBM products, programs or services do not 
  728. imply that IBM intends to make these available in all countries in which IBM 
  729. operates.  Any reference to an IBM product, program, or service is not intended 
  730. to state or imply that only IBM's product, program, or service may be used. Any 
  731. functionally equivalent program that does not infringe any of IBM's 
  732. intellectual property rights may be used instead of the IBM product, program or 
  733. service. 
  734.  
  735. Information in this book was developed in conjunction with use of the equipment 
  736. specified, and is limited in application to those specific hardware and 
  737. software products and levels. 
  738.  
  739. IBM may have patents or pending patent applications covering subject matter in 
  740. this document.  The furnishing of this document does not give you any license 
  741. to these patents.  You can send license inquiries, in writing, to the IBM 
  742. Director of Commercial Relations, IBM Corporation, Purchase, NY 10577. 
  743.  
  744. The information contained in this document has not been submitted to any formal 
  745. IBM test and is distributed AS IS. The information about non-IBM ("vendor") 
  746. products in this manual has b  een supplied by the vendor and IBM assumes no 
  747. responsibility for its accuracy completeness. The use of this information or 
  748. the implementation of any of these techniques is a customer responsibility and 
  749. depends on the customer's ability to evaluate and integrate them into the 
  750. customer's operational environment.  While each item may have been reviewed by 
  751. IBM for accuracy in a specific situation, there is no guarantee that the same 
  752. or similar results will be obtained elsewhere.  Customers attempting to adapt 
  753. these techniques to their own environments do so at their own risk. 
  754.  
  755. References in this publication to IBM products, programs or services do not 
  756. imply that IBM intends to make these available in all countries in which IBM 
  757. operates.  Any reference to an IBM product, program, or service is not intended 
  758. to state or imply that only IBM's product, program, or service may be used. Any 
  759. functionally equivalent program that does not infringe any of IBM's 
  760. intellectual property rights may be used instead of the IBM product, program or 
  761. service. 
  762.  
  763. This document has not been subjected to any formal review and has not been 
  764. checked for technical accuracy.  Results may be individually evaluated for 
  765. applicability to a particular installation.  You may discuss pertinent 
  766. information from this document with a customer, and you may abstract pertinent 
  767. information for presentation to your customers.  However, any code included is 
  768. for internal information purposes only and may not be given to customers. If 
  769. included code is identified as incidental programming, its use must conform to 
  770. the guidelines in the relevant section of the sales manual. 
  771.  
  772. Any performance data contained in this document was obtained in a controlled 
  773. environment based on the use of specific data and is presented only to 
  774. illustrate techniques and procedures to assist IBM personnel to better 
  775. understand IBM products.  The results that may be obtained in other operating 
  776. environments may vary significantly.  Users of this document should verify the 
  777. applicable data in their specific environment.  No performance data may be 
  778. abstracted or reproduced and given to non-IBM personnel without prior written 
  779. approval by Business Practices. 
  780.  
  781. Any performance data contained in this document was determined in a controlled 
  782. environment, and therefore, the results that may be obtained in other operating 
  783. environments may vary significantly. Users of this document should verify the 
  784. applicable data for their specific environment. 
  785.  
  786. The following document contains examples of data and reports used in daily 
  787. business operations.  To illustrate them as completely as possible, the 
  788. examples contain the names of individuals, companies, brands, and products. 
  789. All of these names are fictitious and any similarity to the names and addresses 
  790. used by an actual business enterprise is entirely coincidental. 
  791.  
  792. Reference to PTF numbers that have not been released through the normal 
  793. distribution process does not imply general availability. The purpose of 
  794. including these reference numbers is to alert IBM customers to specific 
  795. information relative to the implementation of the PTF when it becomes available 
  796. to each customer according to the normal IBM PTF distribution process. 
  797.  
  798. You can reproduce a page in this document as a transparency, if that page has 
  799. the copyright notice on it.  The copyright notice must appear on each page 
  800. being reproduced. 
  801.  
  802. The following terms, which are denoted by an asterisk (*) in this publication, 
  803. are trademarks of the International Business Machines Corporation in the United 
  804. States and/or other countries: 
  805.  
  806.  AIX
  807.  C/2
  808.  Common User Access
  809.  CUA
  810.  IBM
  811.  Micro Channel
  812.  OfficeVision
  813.  Operating System/2
  814.  OS/2
  815.  Personal System/2
  816.  PS/2
  817.  SAA
  818.  Systems Application Architecture
  819.  WIN-OS/2
  820.  Workplace Shell
  821.  
  822. The following terms, which are denoted by a double asterisk (**) in this 
  823. publication, are trademarks of other companies: 
  824.  
  825. 286, 386, 486, SX are trademarks of Intel Corporation.
  826. dBase IV is a trademark of Ashton-Tate, Inc.
  827. Intel is a trademark of Intel Corporation.
  828. Lotus, 1-2-3 are trademarks of the Lotus Development Corporation.
  829. Microsoft, Windows are trademarks of Microsoft Corporation.
  830. Novell, Advanced Netware are trademarks of Novell, Inc.
  831. SY-TOS is a trademark of Sytron Corporation.
  832. Smalltalk/V is a trademark of Digitalk, Inc.
  833. WordPerfect is a trademark of WordPerfect Corporation.
  834.  
  835.  
  836. ΓòÉΓòÉΓòÉ 9. Preface ΓòÉΓòÉΓòÉ
  837.  
  838. This document gives a description of the functions and facilities provided by 
  839. the Presentation Manager and Workplace Shell in OS/2 Version 2.0 and their 
  840. implementation. 
  841.  
  842. The document discusses the migration of Presentation Manager applications from 
  843. previous versions of OS/2 and the considerations for deciding whether to 
  844. implement new applications as Presentation Manager or as Workplace Shell 
  845. applications. 
  846.  
  847. This document is intended for planners and technical support personnel who 
  848. require an understanding of the function provided by the Presentation Manager 
  849. and Workplace Shell in OS/2 Version 2.0, and the implementation of that 
  850. function. 
  851.  
  852. Sample code relating to the Workplace Shell is available in electronic form via 
  853. CompuServe** or through a local IBM Support BBS, as package RB3774.ZIP. IBM 
  854. employees may obtain the code examples from the GG243774 PACKAGE on OS2TOOLS. 
  855.  
  856. This sample code was developed primarily for OS/2 Version 2.0 - Volume 4: 
  857. Application Development and therefore has the same package name. 
  858.  
  859. The document is organized as follows: 
  860.  
  861.  Introduction to the Presentation Manager and Workplace Shell provides a brief 
  862.   introduction to the topics covered in this document. 
  863.  
  864.   This chapter is recommended for all readers of the document. 
  865.  
  866.  Presentation Manager Components provides an overview of the Presentation 
  867.   Manager graphical user interface, describing the components of the interface 
  868.   and the interaction between them. 
  869.  
  870.   This chapter is recommended for those readers who are not familiar with 
  871.   Presentation Manager and its operation. 
  872.  
  873.  New Presentation Manager Features describes the new controls, dialogs and 
  874.   functions provided by Presentation Manager. 
  875.  
  876.   This chapter is recommended for those readers who are familiar with 
  877.   Presentation Manager and wish to learn how it has been enhanced in OS/2 
  878.   Version 2.0. 
  879.  
  880.  Workplace Shell Components gives a brief introduction to the Workplace Shell 
  881.   and its role in CUA. It provides an overview of the Workplace Shell user 
  882.   interface components, including both local resources and those available 
  883.   through the LAN Independent Shell. 
  884.  
  885.   This chapter is recommended for those readers who are not familiar with CUA 
  886.   concepts or the Workplace Shell facilities. 
  887.  
  888.  Using the Workplace Shell explains how the components of the Workplace Shell 
  889.   work and gives guidance on how to use them effectively in a number of user 
  890.   scenarios. 
  891.  
  892.   This chapter is recommended for those readers who are not familiar with the 
  893.   Workplace Shell and its use. 
  894.  
  895.  Installing and Supporting the Workplace Shell gives guidance on the 
  896.   installation and configuration of the Workplace Shell and some advice on 
  897.   sorting out problems that may arise. 
  898.  
  899.   This chapter should be read by anyone planning to install or to support OS/2 
  900.   Version 2.0 Workplace Shell. 
  901.  
  902.  Presentation Manager and Workplace Shell Application Development provides a 
  903.   conceptual introduction to the Presentation Manager and Workplace Shell 
  904.   application models, describing the major components of the two styles of 
  905.   application and their interaction. It also discusses the question of how far 
  906.   a Presentation Manager application can integrate with, and make use of, 
  907.   Workplace Shell facilities such as printers and the shredder. 
  908.  
  909.   This chapter is recommended for readers considering any application 
  910.   development for OS/2 Version 2.0 
  911.  
  912.  Workplace Shell Implementation discusses how Workplace Shell is implemented 
  913.   on OS/2 and Presentation Manager.  In particular, this chapter describes 
  914.   Workplace Shell's use of such OS/2 facilities as Extended Attributes and 
  915.   OS2.INI for its data. 
  916.  
  917.   This chapter is recommended for those readers who will be supporting OS/2 
  918.   Version 2.0 and for whom an understanding of the implementation of Workplace 
  919.   Shell should prove invaluable when problems arise. 
  920.  
  921.  Using REXX in OS/2 V2.0 provides information on using Workplace Shell 
  922.   commands in REXX and gives an overview of a few of the most important 
  923.   commands. 
  924.  
  925.  CUA Conformance in the Workplace Shell discusses the degree to which the 
  926.   Workplace Shell is compliant with CUA 91. It also provides some guidance to 
  927.   application developers on which behaviors are determined by the WPS and which 
  928.   should be set in the program. 
  929.  
  930.  
  931. ΓòÉΓòÉΓòÉ 10. Related Publications ΓòÉΓòÉΓòÉ
  932.  
  933. The following publications are considered particularly suitable for a more 
  934. detailed discussion of the topics covered in this document. 
  935.  
  936. Prerequisite Publications 
  937.  
  938.  IBM Systems Application Architecture CUA Advanced Guide to User Interface 
  939.   Design, SC34-4289 
  940.  
  941. Additional Publications 
  942.  
  943.  OS/2 Version 2.0 - Volume 1:  Control Program, GG24-3730 
  944.  
  945.  OS/2 Version 2.0 - Volume 2:  DOS and Windows Environment, GG24-3731 
  946.  
  947.  OS/2 Version 2.0 - Volume 4:  Application Development, GG24-3774 
  948.  
  949.  OS/2 Version 2.0 - Volume 5:  Print Subsystem, GG24-3775 
  950.  
  951.  OS/2 Version 2.0 Remote Installation and Maintenance, GG24-3780 
  952.  
  953.  IBM Systems Application Architecture CUA Advanced Interface Design Reference, 
  954.   SC34-4290 
  955.  
  956.  IBM Personal Systems Developer, Winter 1992 
  957.  
  958.  IBM Icon Reference Book, SC34-4348 
  959.  
  960.  IBM OS/2 Version 2.0 Application Design Guide, 10G6260 
  961.  
  962.  OS/2 2.0 Programming Guide Volume II, 10G6494 
  963.  
  964.  
  965. ΓòÉΓòÉΓòÉ 11. Introduction to the Presentation Manager and Workplace Shell ΓòÉΓòÉΓòÉ
  966.  
  967. OS/2* Version 2.0 brings new levels of computing power to users' desktops, and 
  968. is designed to deliver this power to a very wide range of users, many of whom 
  969. may have little experience with computers. 
  970.  
  971. Power and sophistication could mean complexity for the user, but OS/2 Version 
  972. 2.0 has been provided with an advanced user interface designed to provide users 
  973. with this power in a way that is easy to learn and, as far as possible, 
  974. intuitive, enabling them to make the most of their investment in hardware and 
  975. software. 
  976.  
  977. The components of OS/2 Version 2.0 that provide this user interface are 
  978. Presentation Manager* and the Workplace Shell*. These are the subjects of this 
  979. document. 
  980.  
  981. This introductory chapter: 
  982.  
  983.  Describes a vision of what is made possible with the Workplace Shell 
  984.  
  985.  Describes what Presentation Manager and the Workplace Shell are and how they 
  986.   fit with one another and the rest of OS/2 
  987.  
  988.  Includes a summary of the enhancements to Presentation Manager. 
  989.  
  990.  
  991. ΓòÉΓòÉΓòÉ 11.1. The Vision ΓòÉΓòÉΓòÉ
  992.  
  993. Those who have worked with computers for many years are very happy to talk 
  994. about files, programs, directories, records, spoolers, etc. The inexperienced 
  995. computer user is not. We are used to the idea that when editing a document we 
  996. must first load the data from disk into memory and later, when we have finished 
  997. editing it,  save it back onto disk.  The new computer user is not. 
  998.  
  999. While we are using a computer we can visualize what is going on in the computer 
  1000. - programs being loaded into memory, print files being written to disk before 
  1001. being printed, and the whole hierarchy of disks, directories and files.  The 
  1002. user interface, for us, is a means by which we control these processes.  There 
  1003. have been good user interfaces and bad user interfaces, but so far they have 
  1004. all been designed to allow the knowledgeable user to control a system he 
  1005. understands to some degree. Becoming proficient in the use of a personal 
  1006. computer meant understanding what it does internally. 
  1007.  
  1008. With Presentation Manager and the Workplace Shell a new user can enjoy much of 
  1009. the function of OS/2 and its applications, without needing to understand these 
  1010. things.  He does not even need to think of what he sees on the screen as an 
  1011. interface - that would imply that he is aware that there is something beyond it 
  1012. to which he is interfacing. What he sees on the screen is all he needs to know 
  1013. about.  And what he sees there are representations of everyday items such as 
  1014. folders, documents, an alarm clock, a shredder, and printers. 
  1015.  
  1016. These items - known as objects and represented on the screen by little images 
  1017. known as icons - behave in familiar ways; for example to destroy a document a 
  1018. user would probably guess that he had to put it through the shredder.  With 
  1019. Workplace Shell this is almost exactly what he would do - using the mouse he 
  1020. would drag the icon representing the document onto the icon representing the 
  1021. shredder.  Having discovered that, he might then guess that moving a document 
  1022. to a printer would cause it to be printed, or moving it onto a mailbox icon 
  1023. would result in its being sent to another user. 
  1024.  
  1025. Of course, if all you could do with OS/2 Version 2.0 were the same things you 
  1026. could do without it, there would be no need to have a computer at all. The 
  1027. point is, of course, that though the objects with which the OS/2 user works do 
  1028. familiar things in familiar ways, they also have capabilities far beyond their 
  1029. real-life counterparts.  Consider, for example: 
  1030.  
  1031.  A folder that will, on request, automatically give you all the monthly 
  1032.   cashflow summaries, from its contents of 1000 miscellaneous papers 
  1033.  
  1034.  A pad of order forms that never runs out 
  1035.  
  1036.  A desk on which you can leave all your papers at the end of the day and be 
  1037.   sure that they are still as you left them when you come in the next day, with 
  1038.   no fear of their being moved by the cleaners, or of confidential documents 
  1039.   being removed 
  1040.  
  1041.  A sheet of paper which automatically corrects the spelling of everything you 
  1042.   write on it. 
  1043.  
  1044.   (This would be the Workplace Shell equivalent of a word-processor with a 
  1045.   spellcheck function - the difference is that the user need not know of the 
  1046.   existence of any word-processing package;  to him, the spell-checking 
  1047.   capability is a characteristic of the document itself. This is the essential 
  1048.   difference between object-oriented and application-oriented interfaces.) 
  1049.  
  1050. OS/2's Workplace Shell can do all this and, moreover, do it in a way that the 
  1051. inexperienced user will find a straightforward and natural extension to the 
  1052. real-life behavior of the objects concerned. Furthermore, the Workplace Shell 
  1053. allows application developers to extend the range of objects available to the 
  1054. user to include many more sophisticated or specialized types than those 
  1055. provided as standard with OS/2. 
  1056.  
  1057.  
  1058. ΓòÉΓòÉΓòÉ 11.1.1. The Workplace Shell User with Older Applications ΓòÉΓòÉΓòÉ
  1059.  
  1060. In reality, relatively few users will be able to work in this way all the time. 
  1061. The chances are they will want to use some applications that were written for 
  1062. OS/2 1.3, or for DOS or Windows.  These generally work in ways that are not 
  1063. consistent with the purely object-oriented interface described above. 
  1064.  
  1065. For these users the Workplace Shell provides a very flexible desktop 
  1066. environment from which to launch their non-object-oriented applications. For 
  1067. example, the Program Reference allows the user to represent any program as a 
  1068. Workplace Shell object.  This lets it be placed on the desktop or in any 
  1069. convenient folder and started when required. Furthermore, the Workplace Shell 
  1070. provides the ability to associate any program with particular types of data 
  1071. files, so that the user need only open the data file for the associated program 
  1072. to be automatically invoked. This provides an object-oriented technique for 
  1073. starting some programs that were not written with this in mind. 
  1074.  
  1075.  
  1076. ΓòÉΓòÉΓòÉ 11.1.2. What About the Experienced PC User? ΓòÉΓòÉΓòÉ
  1077.  
  1078. Although the Workplace Shell can provide the inexperienced user with this ideal 
  1079. working environment requiring no knowledge of how OS/2 works, there are many 
  1080. users who are already quite comfortable with basic computing concepts. These 
  1081. users could feel frustrated if they were denied the ability to access the 
  1082. files, directories and programs with which they are familiar. 
  1083.  
  1084. The Workplace Shell does not prevent this.  For example, it provides the Drives 
  1085. object, offering similar function to the file managers of OS/2 Version 1.3 or 
  1086. Microsoft Windows**. The Program Reference object class provides a way to 
  1087. install and run ordinary - non-Workplace Shell - programs.  OS/2 and DOS 
  1088. command prompts may be invoked, allowing the use of commands some of which date 
  1089. back over 10 years to the first releases of DOS.  Workplace Shell is also so 
  1090. flexible that a user can set it up to look and behave very much like OS/2 
  1091. Version 1.3 or Windows, if that is what is preferred. 
  1092.  
  1093. So, experienced PC users may find the Workplace Shell unfamiliar at first, and 
  1094. may not even fully understand the point of it, but they have the option of 
  1095. working in whatever way they choose - using a command prompt if they want to, 
  1096. or perhaps an interface similar to OS/2 Version 1.3 or Windows. In time, they 
  1097. may learn to to think in a less computer-oriented way and start using the 
  1098. additional productivity features of the Workplace Shell. 
  1099.  
  1100.  
  1101. ΓòÉΓòÉΓòÉ 11.2. What is Presentation Manager? ΓòÉΓòÉΓòÉ
  1102.  
  1103. Presentation Manager provides a windowed graphical user interface for OS/2 
  1104. applications. The user interacts with these applications using interface 
  1105. constructs controlled by Presentation Manager, with either the keyboard or the 
  1106. mouse.  For example, when a program asks you to enter a short piece of text 
  1107. such as a file name, you type it into a Presentation Manager control known as 
  1108. an Entry Field,  when a program wishes to display a scrollable list it uses a 
  1109. control known as a List Box, and so on. Presentation Manager has two basic 
  1110. objectives: 
  1111.  
  1112.  To provide a consistent user interface for both the operating system and 
  1113.   applications, so that users may more easily interact with a number of 
  1114.   applications, without the need to learn different sets of interface rules. 
  1115.  
  1116.  To provide an intuitive interface for the end user, in order to ease the task 
  1117.   of learning applications and reduce the amount of formal training required by 
  1118.   encouraging learning through exploration. 
  1119.  
  1120. The Presentation Manager user interface is based on icons, which are used to 
  1121. represent the objects with which the user wishes to work, and windows, which 
  1122. typically provide views of the contents of those objects.  For example, an icon 
  1123. might represent a document which the user wants to modify; in order to do this 
  1124. he would open a view of the document in the form of a window displaying the 
  1125. text in an editable form.  When he has finished working on the document he 
  1126. would close the view. 
  1127.  
  1128. The basics of the Presentation Manager user interface are described in 
  1129. Presentation Manager Components. 
  1130.  
  1131. The implementation of Presentation Manager under OS/2 Version 2.0 has been 
  1132. enhanced over previous versions of OS/2.  Presentation Manager itself has been 
  1133. rewritten to take advantage of the 32-bit functions available in Version 2.0, 
  1134. resulting in improved performance, particularly for complex graphical 
  1135. applications, and several new user interface controls and standard dialogs have 
  1136. been introduced  in conformance with the 1991 Systems Application Architecture* 
  1137. (SAA*) Common User Access* (CUA*) Workplace Environment. The Information 
  1138. Presentation Facility (IPF) has also been enhanced. 
  1139.  
  1140.  
  1141. ΓòÉΓòÉΓòÉ 11.3. What is the Workplace Shell? ΓòÉΓòÉΓòÉ
  1142.  
  1143. The Workplace Shell is both a user interface to OS/2 itself and an application 
  1144. environment in which user-written programs can integrate themselves with one 
  1145. another, and with OS/2's user interface.  This section describes these two 
  1146. aspects of the Workplace Shell. 
  1147.  
  1148.  
  1149. ΓòÉΓòÉΓòÉ 11.3.1. Workplace Shell as an Operating System Shell ΓòÉΓòÉΓòÉ
  1150.  
  1151. Any operating system must provide a user interface that allows the user to make 
  1152. use of the functions of the system, for example to start programs, manage files 
  1153. and so on. This interface is known as its shell, and in some operating systems 
  1154. is no more than a command line and a set of commands;  the user has to know the 
  1155. correct commands to start programs, manipulate files, tailor the system, and so 
  1156. on.  An example of such a shell is the command line interface of DOS 3.3. 
  1157.  
  1158. OS/2 1.1 had a shell that used the Presentation Manager interface. This 
  1159. consisted of a collection of utility programs allowing for starting, stopping 
  1160. and switching between programs (the Desktop Manager), manipulating directories 
  1161. and files (the File Manager), altering system settings (the Control Panel), and 
  1162. managing printers, print queues and the spooler (the Print Manager). 
  1163.  
  1164. This shell provided a degree of consistency for the user through its use of 
  1165. Presentation Manager. However, it was still no more than a collection of 
  1166. separate programs, each working in its own way and having to be learned by the 
  1167. user.  Furthermore, it made no attempt to hide from the user the complexities 
  1168. of the operating system, requiring him to understand concepts such as programs, 
  1169. files, and directories. Nevertheless, this shell remained, with only minor 
  1170. changes, through OS/2 Releases 1.2 and 1.3. 
  1171.  
  1172. OS/2 Version 2.0 introduces a new shell - the Workplace Shell - which takes 
  1173. this development one stage further. It provides a shell that is more 
  1174. consistent, and allows the inexperienced user to remain largely ignorant of the 
  1175. operating system itself.  The Workplace Shell implements a type of interface 
  1176. known as an Object-Oriented User Interface because with it the user interacts 
  1177. with icons representing familiar objects, such as documents, printers, 
  1178. shredders, and folders. The user's attention is focused on these objects, 
  1179. rather than on the programs and files that lie behind them, as with most other 
  1180. kinds of user interface. 
  1181.  
  1182. The Workplace Shell provides all the function of the old OS/2 Version 1.3 shell 
  1183. in a more consistent and easily learned way, while at the same time providing 
  1184. much greater flexibility for the user to organize his work in the way that 
  1185. suits him. 
  1186.  
  1187.  
  1188. ΓòÉΓòÉΓòÉ 11.3.2. Workplace Shell as an Application Environment ΓòÉΓòÉΓòÉ
  1189.  
  1190. The Workplace Shell provides a programming environment, in which suitably 
  1191. written programs can add user-defined object types to those provided with the 
  1192. system.  Such objects may simply be modified versions of the supplied object 
  1193. types - such as a new type of folder that requests a password before the user 
  1194. is allowed to open it - or object types related to specific productivity 
  1195. applications, such as a spreadsheet object, or even object types that are 
  1196. specific to a particular user's business, such as Customer, Order or Motor 
  1197. Insurance Policy. 
  1198.  
  1199. It has been found that a natural and productive way to implement this kind of 
  1200. user interface is to use object-oriented programming techniques.  The Workplace 
  1201. Shell itself is written in this way, using a new component of OS/2 V2.0 called 
  1202. the System Object Model (SOM). SOM is a set of tools and APIs that allows 
  1203. object-oriented programs to be written in a mixture of programming languages, 
  1204. including languages that are not themselves object-oriented, such as C.  All 
  1205. the Workplace Shell object types - folders, data files, printers, etc. - are 
  1206. implemented as SOM objects. 
  1207.  
  1208.  
  1209. ΓòÉΓòÉΓòÉ 11.3.3. WPS Objects versus SOM Objects ΓòÉΓòÉΓòÉ
  1210.  
  1211. Please note that in this book, and in most other discussion of the Workplace 
  1212. Shell, we use the word object in two quite distinct, but closely related, 
  1213. senses: 
  1214.  
  1215.  A Workplace Shell object is something that a user interacts with and 
  1216.   manipulates, and is represented by an icon.  It normally represents some 
  1217.   real-world item that the user understands, such as a printer or an order 
  1218.   form. 
  1219.  
  1220.  A SOM object is a programming construct and is the basis of SOM's 
  1221.   implementation of object-oriented programming (OOP).  It may represent 
  1222.   something quite meaningless to the user such as a database table, or an APPC 
  1223.   conversation; fortunately, a user would not normally know anything about SOM 
  1224.   objects. 
  1225.  
  1226. Workplace Shell objects are implemented as SOM objects, but SOM objects do not 
  1227. necessarily have anything to do with Workplace Shell; indeed a SOM object may 
  1228. not have any visible form at all, being no more than a piece of program code 
  1229. and data. 
  1230.  
  1231. It should normally be clear from the context which sense of the word object is 
  1232. intended. 
  1233.  
  1234.  
  1235. ΓòÉΓòÉΓòÉ 11.4. Presentation Manager Enhancements in OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  1236.  
  1237. This section introduces the Presentation Manager enhancements in OS/2 Version 
  1238. 2.0, all of which are discussed in more detail later in this document. 
  1239.  
  1240.  
  1241. ΓòÉΓòÉΓòÉ 11.4.1. New Controls and Dialogs ΓòÉΓòÉΓòÉ
  1242.  
  1243. A number of new control window classes are provided under OS/2 Version 2.0. 
  1244. These are primarily used to aid in the implementation of the Workplace Shell 
  1245. and the 1991 SAA CUA Workplace Environment, and are available for use by 
  1246. application developers.  They are: 
  1247.  
  1248. Container 
  1249.  
  1250. The purpose of the container control is to hold other objects within the 
  1251. Workplace Shell, in order to allow grouping of objects on the desktop in a 
  1252. logical manner determined by the end user. A container control may display 
  1253. objects in various formats or views, where each view displays different 
  1254. information about the objects. 
  1255.  
  1256. Notebook 
  1257.  
  1258. The notebook control provides a method for organization and navigation of user 
  1259. dialogs, where the required information and prompts may not be easily displayed 
  1260. in a single dialog box.  A notebook control looks like a multi-page notebook, 
  1261. with a dialog on each page.  The user can interact with the top page, and can 
  1262. move to the others either page-by-page or directly, by using tabs attached to 
  1263. the edges of the pages. 
  1264.  
  1265. Slider 
  1266.  
  1267. The slider control looks rather like the slider controls found on some audio 
  1268. equipment, and is used where a value must be chosen from a continuous but 
  1269. finite range of settings. It is ideal for setting approximate values and 
  1270. properties, particularly analog values which are not easily enumerated or 
  1271. expressed in other ways. The slider indicates a particular quantity and the 
  1272. range of allowable values for that quantity. 
  1273.  
  1274. Value Set 
  1275.  
  1276. The value set control is similar in function to the radio button control 
  1277. implemented in previous versions of OS/2, but provides additional flexibility 
  1278. in that it may be used to display a set of values in graphical, numeric, or 
  1279. textual format, whereas the radio button is limited to textual format only.  As 
  1280. with a radio button, selecting one item in the set deselects any previously 
  1281. selected value. 
  1282.  
  1283. Progress Indicator 
  1284.  
  1285. The progress indicator control is used to display the progress of a 
  1286. long-running operation, such as file transfer or disk backup/restore, by means 
  1287. of a hollow bar that fills with color from one end like a thermometer. 
  1288.  
  1289.  
  1290. ΓòÉΓòÉΓòÉ 11.4.2. Information Presentation Facility Enhancements ΓòÉΓòÉΓòÉ
  1291.  
  1292. A number of functional enhancements have been made to the Information 
  1293. Presentation Facility (IPF), which provides context-sensitive help panels and 
  1294. online documentation. These enhancements are as follows: 
  1295.  
  1296.  The ability to predefine default sizes for help panels; these sizes are used 
  1297.   unless overridden by the calling routine. 
  1298.  
  1299.  The ability to define hypertext and hypergraphic links across multiple 
  1300.   concatenated help or documentation files. 
  1301.  
  1302.  Support for multiple viewports within a panel, allowing different types of 
  1303.   complimentary information to be displayed together but to be manipulated 
  1304.   independently. 
  1305.  
  1306.  Dynamic data formatting, allowing help text or explanatory information to be 
  1307.   formatted and placed into a help panel at run time, thereby allowing help 
  1308.   information to be closely tied to the current user action. 
  1309.  
  1310.  Support for tables in help files and online documentation. 
  1311.  
  1312.  Support for multiple fonts and text sizes. 
  1313.  
  1314. These enhancements are described in greater detail in New Presentation Manager 
  1315. Features. 
  1316.  
  1317.  
  1318. ΓòÉΓòÉΓòÉ 11.5. Programming Environment ΓòÉΓòÉΓòÉ
  1319.  
  1320. The Presentation Manager programming environment under OS/2 Version 2.0 has 
  1321. changed very little from that provided under OS/2 Version 1.3.  Presentation 
  1322. Manager applications written for previous versions of OS/2 will execute without 
  1323. modification under Version 2.0. 
  1324.  
  1325. A high degree of source code compatibility is also provided which allows such 
  1326. applications to be recompiled for execution in a 32-bit environment,  providing 
  1327. enhanced performance, with only very minor modifications in most cases. 
  1328.  
  1329. A number of new API functions have been added to Presentation Manager under 
  1330. OS/2 Version 2.0, providing additional function to applications. These include 
  1331. the WinPopUpMenu() function which allows the creation of context menus and a 
  1332. number of other functions to simplify tasks such as checking or unchecking menu 
  1333. items, that were previously achieved by means of PM messages, some enhancement 
  1334. to the Gpi graphical functions, and some other minor changes to function names 
  1335. etc. 
  1336.  
  1337. A number of standard CUA-conforming dialogs for file and font manipulation have 
  1338. been included within the operating system, removing the need for application 
  1339. developers to write these commonly needed functions as part of their 
  1340. application code. 
  1341.  
  1342. Presentation Manager applications under OS/2 Version 2.0 may also mix 16-bit 
  1343. and 32-bit executable modules, in the same way as other applications.  The 
  1344. operating system provides a "thunk" layer for the PM APIs as it does for the 
  1345. kernel APIs. Some additional considerations arise, however, when registering 
  1346. windows between environments and when passing pointers as message parameters, 
  1347. due to the difference in addressing schemes;  this is handled automatically for 
  1348. the standard message classes. Functions are provided to enable programmers to 
  1349. implement thunks for their user-defined messages classes. For a general 
  1350. explanation of thunks see OS/2 Version 2.0 - Volume 1:  Control Program and for 
  1351. examples of their use see OS/2 Version 2.0 - Volume 4:  Application 
  1352. Development. 
  1353.  
  1354. In order to implement application objects that integrate fully with those 
  1355. provided with the Workplace Shell one must write parts of one's application in 
  1356. a new way, using the System Object Model.  The System Object Model provides a 
  1357. language for defining object classes, their methods and instance data, known as 
  1358. Object Interface Definition Language (OIDL) and some utility programs to assist 
  1359. in the generation of the language source files that are needed to build those 
  1360. object classes. Although currently only implemented for the C language, the 
  1361. System Object Model has been designed to enable object classes to be written in 
  1362. a variety of both object-oriented and non-object-oriented languages. 
  1363.  
  1364. All the object classes that the user sees when using Workplace Shell, such as 
  1365. folder, data file and printer, are implemented internally as SOM classes 
  1366. (wpFolder, wpDataFile, wpPrinter, etc.). By sub-classing these and other 
  1367. Workplace Shell classes, programmers can develop new classes for the particular 
  1368. needs of his users, inheriting all the useful instance data and methods while 
  1369. adding to or replacing them with those that their new objects require. 
  1370.  
  1371. Programming for the Presentation Manager and Workplace Shell environments under 
  1372. OS/2 Version 2.0, including the use of the System Object Model and the 
  1373. Workplace Shell classes, is described in detail in OS/2 Version 2.0 - Volume 4: 
  1374. Application Development. 
  1375.  
  1376.  
  1377. ΓòÉΓòÉΓòÉ 11.6. Summary ΓòÉΓòÉΓòÉ
  1378.  
  1379. Presentation Manager provides the strategic graphical-based user interface and 
  1380. programming environment for OS/2 Version 2.0.  The implementation of 
  1381. Presentation Manager  under Version 2.0 has been significantly enhanced over 
  1382. previous versions of OS/2 by exploiting the 32-bit application environment, and 
  1383. by providing additional controls and functions. These can make development more 
  1384. productive for the programmer and the interface more consistent for the user. 
  1385.  
  1386. The object-oriented Workplace Shell, which replaces the PM shell of previous 
  1387. releases, implements the SAA CUA Workplace Model, both for itself and for 
  1388. applications written to exploit the programming environment it provides.  Such 
  1389. applications behave in a more intuitive manner, allowing the user to spend less 
  1390. time learning system-specific operations and more time concentrating on the 
  1391. work tasks to be performed.  The functions previously implemented in desktop 
  1392. utilities have been combined within the Workplace Shell, insulating the user 
  1393. from the complexities of the system. 
  1394.  
  1395. A number of new Presentation Manager control windows and functions have been 
  1396. added under Version 2.0, providing additional function to applications and 
  1397. enhancing the flexibility of user dialogs by providing additional mechanisms 
  1398. for displaying information and receiving user input.  Standard dialogs have 
  1399. also been provided for common file and font manipulation functions, ensuring 
  1400. SAA CUA conformance and removing the need for applications to include such 
  1401. functions within the application code. 
  1402.  
  1403. The Presentation Manager programming environment has changed very little under 
  1404. OS/2 Version 2.0. Applications written and compiled for previous versions will 
  1405. normally run with no changes. For applications to take full advantage of the 
  1406. 32-bit environment and new Presentation Manager functions, some changes to the 
  1407. source code are required, though these are mostly minor. 
  1408.  
  1409. A new, object-oriented, programming model is introduced in the System Object 
  1410. Model, which, in conjunction with the object classes supplied by the Workplace 
  1411. Shell, enables application objects to be developed that integrate seamlessly 
  1412. with the Workplace Shell. Applications written in this way can inherit useful 
  1413. behavior from the supplied Workplace Shell object classes and add function 
  1414. unique to the requirements of a user's business. 
  1415.  
  1416. In general, Presentation Manager under OS/2 Version 2.0 provides improved 
  1417. performance through the use of a 32-bit graphics engine and the Workplace Shell 
  1418. provides improved usability. The redesigned shell with its more intuitive 
  1419. interface helps to insulate the user from the inherent complexity of OS/2, 
  1420. allowing the user to concentrate on the task being performed. The result is 
  1421. improved productivity with reduced training requirements. 
  1422.  
  1423.  
  1424. ΓòÉΓòÉΓòÉ 12. Presentation Manager Components ΓòÉΓòÉΓòÉ
  1425.  
  1426. The OS/2 Presentation Manager user interface was introduced in OS/2 Version 
  1427. 1.1, replacing the textual interface provided by OS/2 Version 1.0. Presentation 
  1428. Manager provides a graphical, windowed presentation environment that lets a 
  1429. user execute and view multiple applications on the screen at the same time. The 
  1430. user can interact with those applications using an event-driven, object-action 
  1431. user interface which conforms to the guidelines laid down in the IBM Systems 
  1432. Application Architecture CUA Advanced Guide to User Interface Design. 
  1433.  
  1434. The Systems Application Architecture CUA component has two major objectives: 
  1435.  
  1436.  1. To provide a consistent interface to applications, in order that users may 
  1437.     more easily interact with a variety of applications and operating system 
  1438.     environments without the need to learn and remember a different set of 
  1439.     interface rules and guidelines for each application or system. 
  1440.  
  1441.  2. To implement the aforementioned consistency objective in such a way that 
  1442.     the interface to applications is highly intuitive, in order to minimize the 
  1443.     amount of formal application training required by affording an easy to use 
  1444.     interface which encourages users to learn by exploration. 
  1445.  
  1446. Both of these objectives can be fulfilled by the Presentation Manager 
  1447. components. This chapter will outline some of the major features of the 
  1448. Presentation Manager user interface, for those readers who may be unfamiliar 
  1449. with it. 
  1450.  
  1451. The Workplace Shell is not a complete implementation of the CUA 91 Workplace 
  1452. Environment.  Differences are discussed in CUA Conformance in the Workplace 
  1453. Shell. /In this chapter, we use standard Presentation Manager terminology. This 
  1454. is consistent with the terminology used in the accompanying OS/2 Version 2.0 - 
  1455. Volume 4:  Application Development. It is also more correct than using CUA 
  1456. terminology with objects which are not CUA-compliant. 
  1457.  
  1458.  
  1459. ΓòÉΓòÉΓòÉ 12.1. Windows ΓòÉΓòÉΓòÉ
  1460.  
  1461. Presentation Manager applications revolve around the concept of windows.  A 
  1462. window appears as a rectangular area on the screen, in which information may be 
  1463. displayed and user input entered. 
  1464.  
  1465. An application may create multiple windows, and multiple windows created by one 
  1466. or more applications may be displayed concurrently on the screen. 
  1467.  
  1468. While the Presentation Manager interface is graphics-oriented, the information 
  1469. input and output through a window need not be graphical; text may be 
  1470. manipulated in windows without the complication of using graphics fonts.  While 
  1471. a mouse is recommended for user interaction in the Presentation Manager 
  1472. environment, many Presentation Manager  functions can be achieved by the use of 
  1473. the keyboard only. 
  1474.  
  1475. Windows are displayed on the screen overlaying a background known as the 
  1476. desktop. This desktop may be altered to any color, or a bitmapped image may be 
  1477. displayed, using utilities provided with Presentation Manager as part of OS/2 
  1478. Version 2.0. 
  1479.  
  1480. An application may create multiple windows; the desktop may simultaneously 
  1481. display multiple windows created by multiple applications, and these windows 
  1482. may be updated concurrently by their parent applications, due to the 
  1483. multitasking nature of the OS/2 operating system.  However, since OS/2 is a 
  1484. single-user system, the user provides input to only one window at a time.  This 
  1485. window is said to possess the input focus. The user may switch the input focus 
  1486. from one window to another by pointing to the desired window with the mouse and 
  1487. pressing mouse button 1, or with the keyboard using the Ctrl+Esc or Alt+Esc key 
  1488. combinations. 
  1489.  
  1490. The use of the mouse button depends on whether the user is left- or 
  1491. right-handed.  It can be selected during the installation process of OS/2 
  1492. Version 2.0. In this document we conform to the CUA convention of using mouse 
  1493. button 1 (MB1) for "select" and mouse button 2 (MB2) for "drag" functions. More 
  1494. information on this is provided in WPS Navigation and Techniques. 
  1495.  
  1496. When many windows are displayed on the desktop at one time, the desktop can 
  1497. become cluttered and almost unworkable. To avoid this situation and remove 
  1498. unwanted windows from the screen without terminating their associated 
  1499. applications, Presentation Manager allows the user to minimize a window. When a 
  1500. window is minimized, it is removed from the desktop and its icon is placed in 
  1501. the Minimized Window Viewer folder. See Icons for a further discussion of this. 
  1502.  
  1503. Clicking MB2 on an icon causes Presentation Manager to display a context (or 
  1504. pop-up) menu. This lets the user restore, move or close the window (that is, 
  1505. terminate the application). If the user "double clicks" MB1 on the icon, 
  1506. Presentation Manager will restore the window to its previous size and position 
  1507. on the screen, without displaying the menu. 
  1508.  
  1509. In order to display a window to the full size of the display screen, a user may 
  1510. maximize a window.  The window is then resized to the maximum defined by the 
  1511. program.  For some programs this will be the whole screen.  A window may also 
  1512. be restored to its former size and position on the screen. See Frame Area for a 
  1513. description of the way in which this is achieved. 
  1514.  
  1515. A window on the screen consists of two distinct areas; the frame area and the 
  1516. client area.  The frame area allows the user to manipulate the window (that is, 
  1517. resize the window, move the window on the screen, etc.) while the client area 
  1518. is used by the application to display information and solicit user input. 
  1519.  
  1520.  
  1521. ΓòÉΓòÉΓòÉ 12.1.1. Frame Area ΓòÉΓòÉΓòÉ
  1522.  
  1523. The frame area contains a number of other windows, such as the system menu, 
  1524. title bar and menu bar, which allow the user to perform window manipulation 
  1525. functions.  These control windows partly conform to the definitions laid down 
  1526. in the IBM Systems Application Architecture CUA Advanced Guide to User 
  1527. Interface Design. They are illustrated in Figure "Presentation Manager Window" 
  1528. and explained below: 
  1529.  
  1530. Sizing Border  A standard window has a sizing border, which allows the window 
  1531.                to be sized (that is, made smaller or larger) using the mouse or 
  1532.                a function-key sequence.  When the mouse pointer is moved over 
  1533.                the sizing border, the pointer changes from the standard (arrow) 
  1534.                pointer to a special sizing pointer.  The user clicks and holds 
  1535.                one of the mouse button while moving the mouse, and the window 
  1536.                is sized accordingly. 
  1537.  
  1538. Title Bar      A standard window has a title bar, which performs two functions. 
  1539.                Firstly, it identifies an application or window to the user. 
  1540.                Secondly, it acts as a "handle" whereby the window may be 
  1541.                repositioned on the screen.  The user moves the mouse pointer 
  1542.                over the title bar, clicks and holds mouse button 2 while moving 
  1543.                the mouse, and the window moves accordingly. 
  1544.  
  1545.                The 1991 SAA CUA guidelines  stipulate that the title bar for a 
  1546.                window should contain both the system menu icon and a title bar 
  1547.                icon for that window. 
  1548.  
  1549. Menu Bar       The main window of an application also has a menu bar, which 
  1550.                acts as a primary menu for the application.  Entries in the menu 
  1551.                bar are selected by pointing with the mouse pointer and clicking 
  1552.                a mouse button.  Each menu bar entry is associated with a 
  1553.                pull-down menu; (a list of actions associated with the entry), 
  1554.                which appears when the bar entry is selected.  The pull-down 
  1555.                menu provides submenus for the menu bar.  Multiple levels of 
  1556.                pull-down menus may be used in an application, although the 
  1557.                number of levels is normally minimized for the sake of 
  1558.                simplicity. 
  1559.  
  1560. Minimize Icon  In the top-right corner of a standard window, two icons are 
  1561.                displayed; the left one is the minimize icon.  When it is 
  1562.                selected, the window itself is reduced to an icon.  The icon may 
  1563.                be generated by the application controlling the window, or may 
  1564.                be a default icon supplied by the Presentation Manager. 
  1565.  
  1566. Maximize Icon  The maximize icon is displayed in the top-right corner of a 
  1567.                standard window along with the minimize icon.  When selected, 
  1568.                the maximize icon causes the window to be resized to the maximum 
  1569.                defined by the program.  Other windows on the screen may be made 
  1570.                invisible (although they are still present, logically "behind" 
  1571.                the maximized window). If a maximized window is explicitly 
  1572.                resized using the sizing border, other windows may become 
  1573.                visible again.  A maximized window may be restored to its former 
  1574.                size and position on the screen by using the restore icon (see 
  1575.                below). 
  1576.  
  1577. Restore Icon   In a maximized window only, the restore icon replaces the 
  1578.                maximize icon.  When selected, this icon causes the window to 
  1579.                return to the size and position it occupied before it was 
  1580.                maximized. 
  1581.  
  1582. Small Icon     In the top-left corner of a standard window, a small icon is 
  1583.                displayed. This is a minimized version of the object icon. When 
  1584.                selected using the mouse pointer, it displays a system menu with 
  1585.                move, size, minimize, maximize and restore options. This menu 
  1586.                provides an alternative to the use of the frame area border, 
  1587.                title bar and icons for these operations. 
  1588.  
  1589. Scroll Bars    If the information in the client area is too big to fit into the 
  1590.                size of the window on the screen, scroll bars should be created 
  1591.                to allow the user to scroll through the information. A scroll 
  1592.                bar can be either vertical or horizontal. It consists of a 
  1593.                slider with arrow icons at each end of the bar. Clicking the 
  1594.                mouse on an arrow scrolls one line in the indicated direction, 
  1595.                while clicking on the bar between the arrow and the slider 
  1596.                scrolls one page in the indicated direction.  Clicking and 
  1597.                holding down  MB1 while dragging the slider up or down the 
  1598.                scroll bar results in continuous scrolling. 
  1599.  
  1600. Note that these facilities are common to most, if not all Presentation Manager 
  1601. applications, and their processing is handled by Presentation Manager rather 
  1602. than by the application.  Thus the user is provided with a consistent interface 
  1603. for interacting with and manipulating windowed applications on the screen, 
  1604. which mostly conforms to the guidelines laid down in the IBM Systems 
  1605. Application Architecture CUA Advanced Guide to User Interface Design. 
  1606.  
  1607.  
  1608. ΓòÉΓòÉΓòÉ 12.1.2. Client Area ΓòÉΓòÉΓòÉ
  1609.  
  1610. The client area of a window contains information which is specific to the 
  1611. application, and thus the contents and layout of the client area will vary from 
  1612. one application to the next.  To preserve the ideal of a consistent user 
  1613. interface, however, Presentation Manager provides a number of standard control 
  1614. windows which may be used to display and receive information to and from the 
  1615. user. 
  1616.  
  1617. For further information about control windows see Control Windows. 
  1618.  
  1619.  
  1620. ΓòÉΓòÉΓòÉ 12.1.3. Parent and Child Windows ΓòÉΓòÉΓòÉ
  1621.  
  1622. An application will normally have one main window and may have one or more 
  1623. child windows, subordinate to this main window.  The main window is known as 
  1624. the parent of these child windows, and the child windows themselves may be the 
  1625. parents of other child windows.  An application may thus have a hierarchy of 
  1626. windows.  Too deep a hierarchy, however, can be very confusing to the user. 
  1627. Windows which exist at the same level in the hierarchy and have the same parent 
  1628. window are known as siblings. 
  1629.  
  1630. While multiple windows may be visible on the screen at any time, the keyboard 
  1631. can only be associated with one window at a time; this window is said to have 
  1632. "input focus". Input focus is normally attributed to a control window on the 
  1633. client area, such as an entry field or list box. The window that contains the 
  1634. control with input focus, is then called the "active window". Presentation 
  1635. Manager automatically indicates this by making the active window the top window 
  1636. and changing the colors of its sizing border and title bar. The active window 
  1637. and input focus can be easily changed by the user. The same technique is used 
  1638. for both windows and controls; move the mouse over the desired window and 
  1639. select it using mouse button 1. Alternatively, a user may key combinations, 
  1640. such as ALT+ESC or ALT+TAB, to move between windows. 
  1641.  
  1642.  
  1643. ΓòÉΓòÉΓòÉ 12.2. Dialog Boxes ΓòÉΓòÉΓòÉ
  1644.  
  1645. A dialog box is a special type of window for use in certain circumstances where 
  1646. an additional interaction with the user is required.  Dialog boxes may be of 
  1647. two distinct types; modal or modeless. 
  1648.  
  1649. A dialog box is created as a short-lived window to receive and/or display a 
  1650. particular set of information required for the correct performance of an action 
  1651. by the application. 
  1652.  
  1653. With a modal dialog box, the user may not interact with another window until 
  1654. the dialog is complete. This modality may be within an application (preventing 
  1655. interaction with other windows controlled by this application program, while 
  1656. allowing interaction with other applications in the system) or system-wide 
  1657. (preventing interaction with any other window until the dialog is complete). 
  1658.  
  1659. With a modeless dialog box, the user may continue to work with the primary 
  1660. application window, for example using the "Find" window with the OS/2 System 
  1661. Editor. Modeless dialogs are preferred by CUA. 
  1662.  
  1663. One difference between a dialog box and a standard window is that the dialog 
  1664. box may not be sized on the screen, nor may it be maximized or minimized except 
  1665. in certain circumstances.  This property of a dialog box is crucial in 
  1666. maintaining the integrity of the dialog with the end user. Note that although a 
  1667. dialog box is not sizable, it may be moved on the desktop. 
  1668.  
  1669. An example of a dialog box is shown in Figure "Presentation Manager Dialog 
  1670. Box". 
  1671.  
  1672. For example, if a user selects "Open" from the "File" pull-down menu, the 
  1673. application requires the name of the file before it can be opened; this 
  1674. information will be requested using a modal dialog box.  For confirmation with 
  1675. the user, a message box may be used as an alternative to a dialog box; see 
  1676. Message Boxes for further information. 
  1677.  
  1678.  
  1679. ΓòÉΓòÉΓòÉ 12.3. Message Boxes ΓòÉΓòÉΓòÉ
  1680.  
  1681. A message box is a short-lived window, similar to a dialog box, which is used 
  1682. to display a message to the user and to receive acknowledgement and a simple 
  1683. decision from the user.  A message box is used to inform the user of an event 
  1684. in situations where the information to be conveyed is relatively simple, and 
  1685. the response returned by the user is limited to a single choice from a finite 
  1686. set of options.  In such a case, the range of facilities provided by a dialog 
  1687. box is not required.  Message boxes and their uses are discussed in detail in 
  1688. OS/2 Version 2.0 - Volume 4:  Application Development.  An example of a message 
  1689. box is given in Figure "Presentation Manager Message Box". 
  1690.  
  1691. A message box displays an application-supplied text string, along with one or 
  1692. more push buttons such as "OK", "Cancel", "Help", etc.  The user selects one of 
  1693. these buttons in response to the text displayed in the message box. 
  1694.  
  1695. As defined in the IBM Systems Application Architecture CUA Advanced Guide to 
  1696. User Interface Design, a message box is a modal dialog with the user, since the 
  1697. user is required to acknowledge and act upon the message before continuing 
  1698. interaction.  Presentation Manager allows both application-modal messages, 
  1699. which prohibit the user from interacting with any other window in the same 
  1700. application before responding to the message, and system-modal messages, which 
  1701. block interaction with any other window in the system until the message has 
  1702. been acknowledged. 
  1703.  
  1704.  
  1705. ΓòÉΓòÉΓòÉ 12.4. Control Windows ΓòÉΓòÉΓòÉ
  1706.  
  1707. The window areas and dialog boxes contain a number of control windows to 
  1708. display and receive information.  These control windows are in fact specialized 
  1709. classes of window defined by Presentation Manager.  The various types of 
  1710. control window are briefly explained below; complete definitions of the 
  1711. appearance and behavior of each type of control window are given in the IBM 
  1712. Systems Application Architecture CUA Advanced Guide to User Interface Design. 
  1713.  
  1714. Static Text   This is constant text, displayed in the dialog box for 
  1715.               information purposes only; such text does not change from one 
  1716.               invocation of the dialog to the next. 
  1717.  
  1718. Entry Field   This is an area, of a defined size, where a user may enter 
  1719.               alphanumeric or numeric data.  An application may also place a 
  1720.               default entry in an entry field to simplify the user's task of 
  1721.               entering information; the user may then edit the existing data or 
  1722.               replace it with new data. 
  1723.  
  1724.               Entry fields may be single-line or multi-line. 
  1725.  
  1726. List Box      This is an area which contains a list of items, one or more of 
  1727.               which may be selected by the user.  If a list contains more 
  1728.               information than will fit into the designated area, a list box 
  1729.               may contain vertical and/or horizontal scroll bars. 
  1730.  
  1731. Combo Box     The combo box or prompted entry field is a combination of the 
  1732.               entry field and list box types;  by default, an entry field is 
  1733.               displayed into which the user may enter text.  At the right-hand 
  1734.               side of the entry field however, is an icon which when selected, 
  1735.               causes a drop-down list box to appear below the entry field, 
  1736.               containing a list of valid entries.  The user may enter a value 
  1737.               directly into the entry field or, if unsure, may use the list box 
  1738.               to select a valid entry. 
  1739.  
  1740. Check Box     This is a square area, surrounded by a border with accompanying 
  1741.               text, which denotes an option that may be toggled on and off by 
  1742.               the user.  For instance, in a text search the option to ignore 
  1743.               case may be implemented as a check box. 
  1744.  
  1745. Radio Button  Radio buttons are small round areas which are usually displayed 
  1746.               in groups; a group of radio buttons denotes a series of mutually 
  1747.               exclusive options from which the user may select one option only. 
  1748.               Making a selection immediately deselects any previous choice. 
  1749.               The selected option in a group of radio buttons is indicated by a 
  1750.               dark center in the button. 
  1751.  
  1752. Push Button   This is a square or rectangular area containing some brief text 
  1753.               and surrounded by a border. It denotes an option which may be 
  1754.               selected for immediate action.  Selections such as "Enter" and 
  1755.               "Cancel" to complete or cancel a dialog are normally implemented 
  1756.               in this way. 
  1757.  
  1758. Spin Button   The spin button is used to display a currently selected option 
  1759.               from a finite range of options.  The items displayed in the spin 
  1760.               button control are textual, and may represent any alphanumeric 
  1761.               item.  It consists of a single-line entry field, and up and down 
  1762.               arrows that are stacked on top of one another. 
  1763.  
  1764. Slider        This is a scale with an index which may be moved along the scale 
  1765.               using the mouse or keyboard.  The slider allows the selection of 
  1766.               a value from a contiguous set of values. 
  1767.  
  1768. Value Set     This is similar in concept to a group of radio buttons, except 
  1769.               that items within the group may be icons, bitmaps or color 
  1770.               patches as well as text strings. The value set control window 
  1771.               allows the selection of a non-textual item from a set of mutually 
  1772.               exclusive options. 
  1773.  
  1774. Container     A container acts as a repository and provides a mechanism to 
  1775.               organize the desktop to suit the requirements of the user.  Its 
  1776.               basic function is to hold objects such as files, applications and 
  1777.               devices represented by icons. 
  1778.  
  1779. Notebook      A notebook is a visual component that organizes information on 
  1780.               individual pages so that a user can find and display that 
  1781.               information quickly and easily. This component simulates a real 
  1782.               notebook but improves on it by overcoming the real notebooks 
  1783.               natural limitations. 
  1784.  
  1785. These control windows are defined as child windows with the main window as 
  1786. their parent. 
  1787.  
  1788. Note also that control windows are not restricted to use in the main window 
  1789. client area, and may also be created within dialog boxes. Control windows are 
  1790. clipped to the boundaries of their parent window according to the same rules as 
  1791. other child windows. 
  1792.  
  1793.  
  1794. ΓòÉΓòÉΓòÉ 12.5. Icons ΓòÉΓòÉΓòÉ
  1795.  
  1796. An icon is a small graphical image on the screen, used as a visual 
  1797. representation of an object such as an application or a window.  While the use 
  1798. of icons is not restricted to object-oriented applications, the implementation 
  1799. of an icon-based user interface, where icons representing objects are directly 
  1800. manipulated on the screen by the user to achieve a desired result, is the 
  1801. essence of the object-oriented workplace environment implemented by the 
  1802. Workplace Shell under OS/2 Version 2.0. For more information see Installing and 
  1803. Supporting the Workplace Shell and Workplace Shell Implementation. 
  1804.  
  1805. Icons are designed using the Icon Editor program supplied with OS/2 Version 
  1806. 2.0.  This utility offers the interactive design of icons, pointers and bitmaps 
  1807. by the user.  The resulting objects are saved in files for subsequent use by 
  1808. applications. 
  1809.  
  1810. The implementation of an icon depends on the associated application.  There are 
  1811. three different possibilities: 
  1812.  
  1813.  1. For a full-screen protected-mode application (that is, those which do not 
  1814.     utilize Presentation Manager facilities) or for an application which 
  1815.     executes in a text window under Presentation Manager, an icon can be 
  1816.     provided for use with the application.  It must be in the same directory 
  1817.     and with the same file name as the application executable module.  For 
  1818.     example, the icon for the application MBOOGLE.EXE would have the name 
  1819.     MBOOGLE.ICO.  When loading the application, the Presentation Manager 
  1820.     automatically checks the directory for a corresponding icon file.  If it 
  1821.     exists, it will use it to represent the application.  Otherwise a default 
  1822.     icon will be used. 
  1823.  
  1824.  2. For Presentation Manager applications, icons are generally incorporated 
  1825.     into the executable modules when the applications are created.  See OS/2 
  1826.     Version 2.0 - Volume 4:  Application Development for further information on 
  1827.     creating icons and including them in Presentation Manager applications. 
  1828.  
  1829.  3. If there is no default icon available for the application, the user can 
  1830.     associate an icon by using the "General" page in the Settings notebook. 
  1831.     This dialog box allows the user to create a new one or to search for 
  1832.     another available icon with the find command. 
  1833.  
  1834. Data files generally have a default icon, but this can be changed in the same 
  1835. way as for an application. 
  1836.  
  1837.  
  1838. ΓòÉΓòÉΓòÉ 12.6. Clipboard ΓòÉΓòÉΓòÉ
  1839.  
  1840. The clipboard provides a temporary storage area for a piece of text, a bitmap 
  1841. or a metafile. It enables the user to move data within a single application or 
  1842. exchange data among applications.  Typically, a user selects data in the 
  1843. application using the mouse or keyboard, then initiates a cut or copy operation 
  1844. on that selection.  Using the paste command the user can insert this data into 
  1845. another place in the same application or in another application.  All these 
  1846. operations are performed by applications. 
  1847.  
  1848. Generally an application should first verify that no other applications are 
  1849. trying to retrieve or set clipboard data. Finally, when the application 
  1850. finishes its access to the clipboard data, it releases the clipboard so that 
  1851. other applications can use it. 
  1852.  
  1853. These operations are described below: 
  1854.  
  1855. Operation     Description 
  1856.  
  1857. Cut           Deletes the selected data from the application and copies it to 
  1858.               the clipboard.  Any previous contents of the clipboard are 
  1859.               destroyed. 
  1860.  
  1861. Copy          Copies the selected data to the clipboard.  The selection remains 
  1862.               unchanged.  Previous contents of the clipboard are destroyed. 
  1863.               Before an application performs a cut or copy operation, it 
  1864.               removes any previously stored data in the clipboard. Then it 
  1865.               writes its data to the clipboard in as many standard formats as 
  1866.               possible. 
  1867.  
  1868. Paste         Deletes any selected data from the application and replaces it 
  1869.               with the contents of the clipboard. The contents of the clipboard 
  1870.               are not changed. When the application performs a paste operation 
  1871.               it verifies the format where the data are stored. If the 
  1872.               clipboard contains one of the requested formats, such as text 
  1873.               data, the application gets a pointer to a shareable memory object 
  1874.               containing the text. For bitmap data or metafile, it gets a 
  1875.               corresponding handle. 
  1876.  
  1877. The clipboard is a small amount of system memory for user-driven data exchange. 
  1878. The clipboard only stores pointers to data.  A set of API functions enables the 
  1879. application to move and exchange data. Figure "Clipboard Copy from an OS/2 
  1880. Window into an OS/2 PM Editor" is an example of copying data from one 
  1881. application and pasting it to another, by way of the clipboard. 
  1882.  
  1883. The data in the clipboard is maintained in memory only.  Clipboard data is lost 
  1884. when the computer is turned off. 
  1885.  
  1886.  
  1887. ΓòÉΓòÉΓòÉ 12.6.1. Shared Memory and the Clipboard ΓòÉΓòÉΓòÉ
  1888.  
  1889. An application must store, in shared memory, text data that is destined for the 
  1890. clipboard. The application passes the clipboard a pointer, which the clipboard 
  1891. uses to access the shared memory object. To pass a bit map or metafile to the 
  1892. clipboard, an application passes the clipboard a bit map or metafile handle. 
  1893. The clipboard functions make the bit map or metafile shareable. 
  1894.  
  1895.  
  1896. ΓòÉΓòÉΓòÉ 12.7. Summary ΓòÉΓòÉΓòÉ
  1897.  
  1898. The Presentation Manager user interface provides the capability for the user to 
  1899. interact with applications in a consistent, intuitive manner. Presentation 
  1900. Manager components conform to the guidelines laid down in the IBM Systems 
  1901. Application Architecture CUA Advanced Guide to User Interface Design. 
  1902.  
  1903. The Presentation Manager user interface makes extensive use of windows and a 
  1904. series of defined user interface constructs which appear and behave in a 
  1905. consistent manner, and which may be used by applications to interact with the 
  1906. user.  Special-purpose windows such as dialog boxes and message boxes are also 
  1907. supported by the interface for use in specific circumstances, and their 
  1908. appearance and behavior is also defined and regulated by CUA guidelines.  The 
  1909. use of such predefined constructs by applications allows a high level of 
  1910. consistency between applications in terms of their interaction with the user, 
  1911. thus simplifying the level of training required to use those applications. 
  1912.  
  1913. The event-driven, object-action style of the user interface implemented by 
  1914. Presentation Manager is highly intuitive. This fact, combined with the high 
  1915. level of consistency between applications, encourages learning by exploration. 
  1916. In turn, this helps reduce the need for formal training and enables users to 
  1917. become more productive with new applications in a shorter period of time. 
  1918.  
  1919.  
  1920. ΓòÉΓòÉΓòÉ 13. New Presentation Manager Features ΓòÉΓòÉΓòÉ
  1921.  
  1922. The component of the operating system which is responsible for interaction with 
  1923. the end user is known as the user shell. The PM Shell in OS/2 V1.3 has been 
  1924. replaced in OS/2 Version 2.0 by an enhanced, object-oriented user shell known 
  1925. as the Workplace Shell, which implements the 1991 CUA Workplace Environment. 
  1926.  
  1927. The Workplace Shell allows users to become more task-oriented by simplifying 
  1928. the user interface and reducing the amount of system-specific knowledge 
  1929. required to perform work tasks. The high degree of consistency in the operating 
  1930. system also reduces the amount of user education needed to operate the system. 
  1931.  
  1932. The shell has been redesigned for OS/2 Version 2.0 to give the user a single 
  1933. interface to manage multiple types of objects, including devices (printer and 
  1934. drives), files, and programs. Each defined printer or attached drive is a 
  1935. separate icon. These objects are arranged at will on the desktop or in specific 
  1936. shell windows.  The user interacts with the objects using a well-defined drag 
  1937. and drop environment and is able to manipulate files without needing to be 
  1938. concerned about the file directory hierarchy.  However, if the user wishes, 
  1939. multiple directory trees are accessible simultaneously.  Views, selection 
  1940. techniques, and actions are consistent throughout the shell. 
  1941.  
  1942. This chapter reviews the changes to Presentation Manager. Some of the 
  1943. information has been abstracted from articles written by the developers in the 
  1944. IBM Personal System Developer, Winter 1992. 
  1945.  
  1946.  
  1947. ΓòÉΓòÉΓòÉ 13.1. New Window Classes ΓòÉΓòÉΓòÉ
  1948.  
  1949. A number of new control window classes have been added to Presentation Manager 
  1950. under OS/2 Version 2.0.  These controls aid in the implementation of the 
  1951. Workplace Shell and provide enhanced function and flexibility for user dialogs 
  1952. in Presentation Manager  applications. 
  1953.  
  1954. This chapter describes these new controls and their interaction with the end 
  1955. user. More information on using these controls in applications can be found in 
  1956. OS/2 Version 2.0 - Volume 4:  Application Development. and the OS/2 Version 2.0 
  1957. Programmers Guide, Volume II. 
  1958.  
  1959.  
  1960. ΓòÉΓòÉΓòÉ 13.1.1. Container ΓòÉΓòÉΓòÉ
  1961.  
  1962. Folders are extensively used within the Workplace Shell to logically group 
  1963. objects (represented by their icons) on the desktop. A folder consists of a 
  1964. standard window frame plus a container control which occupies the whole of the 
  1965. client area. A folder can contain other folders, objects representing work 
  1966. items such as reports, or physical items such as printers. The objects 
  1967. displayed by a container control are determined by the application. 
  1968.  
  1969. Figure "Container Control Used in Folder Window" 
  1970.  
  1971. Various types of objects may be displayed within a container; these include 
  1972. objects representing printers and other physical devices, as well as those 
  1973. representing items such as files or documents. Information about these objects 
  1974. can be presented in a variety of views.  Each view describes the objects in a 
  1975. different format, some giving different and/or additional information. The 
  1976. container supports the following views of its data: 
  1977.  
  1978. Icon view      This view displays either icons or bitmaps, with accompanying 
  1979.                text beneath them, to represent the items in the container. This 
  1980.                is the default view for a container. 
  1981.  
  1982.                The user may group the objects as he chooses. He can overlap 
  1983.                them, in a "messy desktop" fashion, or can have them 
  1984.                automatically positioned. The default icon view is not 
  1985.                "gridded"; that is, it has free-form characteristics so data can 
  1986.                be placed in various relative positions and still have meaning. 
  1987.                However, if a gridded display format is preferred, the objects 
  1988.                can also be arranged in rows from left to right and from top to 
  1989.                bottom. 
  1990.  
  1991. The name view  This displays either icons or bitmaps with accompanying text to 
  1992.                the right of each icon or bitmap, representing the items in the 
  1993.                container. Items are arranged in a single column. A variant of 
  1994.                the name view is the flowed name view, where items are arranged 
  1995.                in multiple columns. 
  1996.  
  1997. Text view      This view is similar to the Presentation Manager list box in 
  1998.                OS/2. Text strings are displayed in columns. This view also 
  1999.                offers the option of flowing the text into multiple columns to 
  2000.                fit the windows when it is sized. 
  2001.  
  2002. Details view   This view allows the user to display detailed information about 
  2003.                items in an unlimited number of scrollable columns. The data 
  2004.                within each column may be icons, bitmaps, text strings, or 
  2005.                national language support (NLS) formatted date or time strings. 
  2006.                An optional splitbar may be used to divide the display area into 
  2007.                two windows which scroll independently horizontally and 
  2008.                dependently vertically. 
  2009.  
  2010. Tree view      This presents data in a hierarchical format, similar to the 
  2011.                directory layout used in the OS/2 Version 1.3 File Manager. The 
  2012.                leftmost items displayed in the tree view are at the root level. 
  2013.                Root level items can contain other items called children. These 
  2014.                can be displayed in the tree view. If the children are not 
  2015.                displayed, the parent item can be expanded to display them as a 
  2016.                new branch in the tree view. 
  2017.  
  2018. Each instance of text in the container can consist of unlimited lines with 
  2019. unlimited characters in each line. In addition, the container control does not 
  2020. limit the number of objects within a container. Objects are automatically 
  2021. arranged within the client area of the container. 
  2022.  
  2023. Direct manipulation is supported in all views of the container control. This 
  2024. allows the user to drag container items within a current window or from one 
  2025. window to another. 
  2026.  
  2027. Containers and their use by applications are further explored in OS/2 Version 
  2028. 2.0 - Volume 4:  Application Development. 
  2029.  
  2030. User Interaction 
  2031.  
  2032. The end user can alter any text field in the container, including the container 
  2033. title, column headings in details view and all container items, through direct 
  2034. editing. Text strings can also be individually set to a "read-only" state. 
  2035.  
  2036. Objects within a container may be selected through marquee, touch swipe, range 
  2037. swipe, and first letter selection techniques. The container control supports 
  2038. single, extended, and multiple selection types; these are described in the IBM 
  2039. Systems Application Architecture CUA Advanced Interface Design Reference. 
  2040.  
  2041.  
  2042. ΓòÉΓòÉΓòÉ 13.1.2. Notebook ΓòÉΓòÉΓòÉ
  2043.  
  2044. The notebook control is used to provide an easy and intuitive method for a user 
  2045. to navigate through a complex dialog, where multiple related dialog boxes are 
  2046. displayed.  The notebook control allows the programmer to assemble a collection 
  2047. of dialog boxes which relate to a single topic. It is designed to visually 
  2048. resemble a bound notebook with multiple pages. 
  2049.  
  2050. The notebook control provides an easy-to-use user interface component that is 
  2051. consistent across multiple products. In this way, it helps products to conform 
  2052. to the Common User Access user interface guidelines. 
  2053.  
  2054. The notebook used to provide the desktop setting is shown in Figure 
  2055. "Presentation Manager Notebook for Desktop Setting". 
  2056.  
  2057.  Data in the notebook is presented on pages bound together on one edge. Pages 
  2058. appear recessed on two edges of the book, thus providing a three-dimensional 
  2059. appearance. 
  2060.  
  2061. The notebook control supports the use of both a pointing device, such as a 
  2062. mouse, and the keyboard for displaying notebook pages and tabs, and for moving 
  2063. the selection cursor from the notebook tabs to the top page.  The end user can 
  2064. turn from page to page or may go quickly from one tab page to another. The 
  2065. following navigation components are provided: 
  2066.  
  2067. Section dividers Across from the notebook binding are the major section 
  2068.                 dividers (called major tabs). The section dividers provide a 
  2069.                 means of organizing the data within the book. Each section 
  2070.                 within the notebook may contain single or multiple pages. The 
  2071.                 notebook provides a method for the end user to turn the pages 
  2072.                 within a section and also to skip from one section to another 
  2073.                 easily. Just as dividers provide an indication of where the 
  2074.                 user is within the book, methods are supported to indicate 
  2075.                 where the user is within a section. 
  2076.  
  2077. Page buttons    In the bottom right corner of the notebook in Figure 
  2078.                 "Presentation Manager Notebook for Desktop Setting" are the 
  2079.                 page buttons. These buttons are used to view one page of the 
  2080.                 notebook at a time. Selecting the forward page button (the 
  2081.                 right-pointing arrow) causes the next page to be displayed, 
  2082.                 while selecting the backward page button (the left-pointing 
  2083.                 arrow) causes the previous page to be displayed. 
  2084.  
  2085. The visible area of the notebook is the top page. The application uses this top 
  2086. page to display information and facilitate user interaction. The top page may 
  2087. contain application-created windows or dialogs. Only one page is visible at any 
  2088. time. The notebook handles the hiding and showing of the topmost window or 
  2089. dialog when pages are turned. 
  2090.  
  2091. If all the tabs currently inserted cannot be displayed, scroll arrows are 
  2092. provided to scroll the tabs forward and backward. Figure "Presentation Manager 
  2093. Notebook used in Master Help Index" shows a notebook used by the Master Help 
  2094. Index. 
  2095.  
  2096. The notebook control is comprised of various regions which may be dynamically 
  2097. resized. Whenever the notebook window is resized or any of the notebook visual 
  2098. regions are resized the notebook dynamically recalculates the sizes of all 
  2099. affected regions for future display. 
  2100.  
  2101.  
  2102. ΓòÉΓòÉΓòÉ 13.1.3. Slider ΓòÉΓòÉΓòÉ
  2103.  
  2104. The slider control supports the setting of approximate values and properties in 
  2105. an analog rather than digital form.  It is designed to be used where settings 
  2106. are intuitively expressed in analog or relative form, rather than exact numeric 
  2107. values. 
  2108.  
  2109. Figure "Slider Control" 
  2110.  
  2111. The slider control consists of a slider shaft, within which is a slider arm. 
  2112. The arm is used to change the setting of the slider control. The arm can be 
  2113. moved by the user by dragging it with the mouse or by using the cursor arrow 
  2114. keys on the keyboard. 
  2115.  
  2116. An application may also change the setting of a slider control from within the 
  2117. application, independently of user action. The application creating the slider 
  2118. control must specify the range of available values or increments for the slider 
  2119. and may also specify the spacing for items in the rulers. 
  2120.  
  2121. In previous versions of OS/2, the scroll bar control was often used to provide 
  2122. the same effect as the slider; for example, setting colors in the control 
  2123. panel. The slider control is better than the scroll bar in such cases, since it 
  2124. is more flexible and typically easier to control within an application. 
  2125. Providing a slider control also means that the scroll bar can be used only for 
  2126. its intended purpose of scrolling information within a window, which results in 
  2127. a more consistent user interface. 
  2128.  
  2129.  
  2130. ΓòÉΓòÉΓòÉ 13.1.4. Value Set ΓòÉΓòÉΓòÉ
  2131.  
  2132. The value set control is similar to the existing radio button control since its 
  2133. purpose is to allow a user to select an item from an existing set.  However, 
  2134. unlike radio buttons, the value set provides a graphical set of selectable 
  2135. items. Suppose an application, like the one shown in Figure "Value Set 
  2136. Control", provides the ability to select a drawing tool. Using the value set, 
  2137. the application can provide a graphical image of the different tools so that 
  2138. the user can see all the available choices when he makes his selection. 
  2139.  
  2140. The value set control offers great flexibility to the interface designer 
  2141. because it can be extended as the application grows. The system drag protocol 
  2142. is supported by the value set control. This means that users could, for 
  2143. example, select a color from a value set and then drag that color to the target 
  2144. item. For example, he could drag the color to the client area of a window to 
  2145. change that window's background color. 
  2146.  
  2147. The items within a value set control may include: 
  2148.  
  2149.  Bitmaps 
  2150.  
  2151.  Icons 
  2152.  
  2153.  Text strings 
  2154.  
  2155.  Colors. 
  2156.  
  2157. Items of different types may be mixed in the same value set control. 
  2158.  
  2159. While a value set control may be used to display textual or numeric data, it is 
  2160. recommended that a radio button be used for this purpose, and that the use of 
  2161. the value set control be confined to the display of graphical data. 
  2162.  
  2163.  
  2164. ΓòÉΓòÉΓòÉ 13.1.5. Progress Indicator ΓòÉΓòÉΓòÉ
  2165.  
  2166. The progress indicator displays the progress of a long-running command to the 
  2167. user.  It is typically used for operations such as uploading or downloading 
  2168. files to or from a remote system, backing up a fixed disk etc.  The progress 
  2169. indicator provides an easy way for different applications to display such 
  2170. progress to the end user in a consistent manner. 
  2171.  
  2172. Figure "Progress Indicator Control" 
  2173.  
  2174. The progress indicator includes push buttons which allow the user to control 
  2175. the operation in progress. The user may pause or resume the operation; the 
  2176. operation may be cancelled when in the paused state. The progress indicator 
  2177. control passes messages to the application when the user selects any push 
  2178. button. 
  2179.  
  2180.  
  2181. ΓòÉΓòÉΓòÉ 13.2. Standard Dialogs ΓòÉΓòÉΓòÉ
  2182.  
  2183. OS/2 V2.0 provides a number of standard, CUA-conforming dialogs which may be 
  2184. used by applications to perform common operations such as file handling and 
  2185. font selection.  The provision of these dialogs within the operating system 
  2186. avoids the need for applications to individually develop dialog boxes and 
  2187. procedures for these functions. This delivers a high degree of consistency 
  2188. between similar operations in different applications. 
  2189.  
  2190. Both forms of the standard file dialog are accessed by an application using the 
  2191. WinFileDlg() function.  This function is explained further in OS/2 Version 2.0 
  2192. - Volume 4:  Application Development. 
  2193.  
  2194.  
  2195. ΓòÉΓòÉΓòÉ 13.2.1. File Dialogs ΓòÉΓòÉΓòÉ
  2196.  
  2197. There are two standard dialogs provided for file manipulation: the Open dialog 
  2198. and the Save as dialog.  Each provides similar function, but has slightly 
  2199. different behavior due to the different function being performed with the 
  2200. dialog. The use of these dialogs enables application developers to provide 
  2201. these functions in a consistent manner, without having to code such function 
  2202. into their application programs. 
  2203.  
  2204. The standard "Open" dialog box, used to select and open directories and files 
  2205. from within an application, is shown in Figure "Standard File Dialog for 
  2206. "Open"". 
  2207.  
  2208. The file dialogs are required by application-oriented programs wishing to 
  2209. conform to the 1991 CUA guidelines. By standardizing the commonly performed 
  2210. file manipulation tasks across different programs, they help to eliminate minor 
  2211. inconsistencies in dialog operation, which results in fewer user errors. 
  2212.  
  2213.  
  2214. ΓòÉΓòÉΓòÉ 13.2.2. Font Dialog ΓòÉΓòÉΓòÉ
  2215.  
  2216. The Workplace Shell also provides a standard font dialog. The font dialog is 
  2217. available to any application that wants to let a user view and select fonts. 
  2218. The basic functions of the font dialog provided include the ability to select 
  2219. from: 
  2220.  
  2221.  1. A list of font family facenames installed on the system 
  2222.  
  2223.  2. Styles for each font 
  2224.  
  2225.  3. Available sizes for each font 
  2226.  
  2227.  4. Emphasis styles available for each font. 
  2228.  
  2229. The font family facename is defined as the name of the typeface, for example, 
  2230. Courier, Times New Roman, and Helvetica. Type styles include normal, bold, 
  2231. italic, and bold italic. Size is defined as the point size, or vertical 
  2232. measurement of the type. Font emphasis styles include outline, underline, and 
  2233. strikeout. 
  2234.  
  2235. Figure "Standard Font Dialog" shows the appearance of the standard font dialog. 
  2236.  
  2237. The font dialog also has a viewing area that is updated dynamically when the 
  2238. user makes selections of fonts, styles, etc. This viewing area lets the user 
  2239. preview any font prior to applying it. 
  2240.  
  2241.  
  2242. ΓòÉΓòÉΓòÉ 13.3. Information Presentation Facility ΓòÉΓòÉΓòÉ
  2243.  
  2244. OS/2 Version 2.0 provides a number of enhancements to IPF in addition to the 
  2245. capabilities available under OS/2 Version 1.3.  This section briefly describes 
  2246. these enhancements; more complete information may be found in the IBM OS/2 
  2247. Version 2.0 Information Presentation Reference. 
  2248.  
  2249. The Information Presentation Facility (IPF) allows application developers to 
  2250. provide online, context-sensitive help information for Presentation Manager 
  2251. applications.  IPF also allows online manuals and documentation to be built and 
  2252. viewed independently of applications.  Automatic table of contents, searching 
  2253. and printing facilities are provided by IPF. 
  2254.  
  2255. The hypertext links have been extended to include bitmaps and metafiles, in 
  2256. addition to text phrases.  These hypergraphic links provide enhanced 
  2257. flexibility for the display of online documentation, particularly procedure 
  2258. manuals and tutorials.  Hypergraphic links may be used to display additional 
  2259. information, send a message to an application, or start a new process in a 
  2260. similar manner to hypertext links. 
  2261.  
  2262. Under OS/2 Version 2.0, links may be made between panels which reside in 
  2263. different source files; these files are concatenated and the resulting 
  2264. information may be viewed as a single entity.  Both hypertext and hypergraphic 
  2265. links are supported in this manner.  This enables larger amounts of information 
  2266. to be viewed, and allows the separation of volatile information into separate 
  2267. files for easier update. 
  2268.  
  2269. The split screen support provided by IPF under OS/2 Version 2.0 allows a window 
  2270. to be regarded as multiple viewports, each of which may be manipulated 
  2271. separately by the author and the user. 
  2272.  
  2273. Under OS/2 Version 2.0, all windows are composed of one or more viewports.  The 
  2274. default viewport is simply the entire window.  IPF Version 2.0 allows secondary 
  2275. viewports to be opened, to display related information which may be scrolled 
  2276. and manipulated separately from the parent information. 
  2277.  
  2278. IPF provides two different types of viewport within a window: 
  2279.  
  2280.  IPF-controlled (IC) viewports are created, controlled and manipulated by IPF 
  2281.   in a similar way to normal IPF windows. 
  2282.  
  2283.  Application-controlled (AC) viewports are controlled by the application, and 
  2284.   are typically used for the display of specialized information.  For example, 
  2285.   an AC viewport might be used to display animation or full-motion video. 
  2286.  
  2287. These different types of viewports may be mixed within the same parent window. 
  2288.  
  2289. Dynamic data formatting allows applications to place customized information in 
  2290. help windows or online documents at run time. For example, this facility could 
  2291. be used in a help window to display the data from a current transaction to the 
  2292. user, along with the required steps to complete that transaction.  The help 
  2293. information is thereby made more relevant to the immediate task. 
  2294.  
  2295. IPF allows items within help windows to be defined as hypertext. When the user 
  2296. selects such items, actions may be triggered (for example, opening another help 
  2297. window to display more detailed explanatory text, posting a message back to the 
  2298. application's window procedure to invoke an application event, or starting 
  2299. another process under OS/2). 
  2300.  
  2301. Under OS/2 Version 2.0, IPF supports the use of multiple fonts within help 
  2302. windows or online documentation, as well as multiple character sizes for each 
  2303. font.  By default, all help windows and online documentation windows appear in 
  2304. the system font.  The Courier, Helvetica (Helv), and Times Roman (Tms Rmn) 
  2305. fonts are available in all display adapters supported by Presentation Manager. 
  2306. Where the specified size is not available for the required font, the closest 
  2307. match is used. 
  2308.  
  2309.  
  2310. ΓòÉΓòÉΓòÉ 13.4. Summary ΓòÉΓòÉΓòÉ
  2311.  
  2312. The new control window classes provided under Presentation Manager in OS/2 
  2313. Version 2.0 help in the implementation of the Workplace Shell and enable 
  2314. application developers to create applications which more easily integrate with 
  2315. the 1991 SAA CUA Workplace Environment. 
  2316.  
  2317. Icons and containers are fundamental to the Workplace Shell, and their 
  2318. inclusion as control window classes provides the means for consistent behavior 
  2319. of such objects between all applications on the desktop.  The notebook control 
  2320. allows the display and navigation of complex user dialogs in an organized 
  2321. manner, within the context of the Workplace Shell. 
  2322.  
  2323. The slider, value set, and spin button control window classes provide 
  2324. additional flexibility for end-user dialogs, enabling applications to present 
  2325. properties to the user in a more meaningful and less confusing manner than was 
  2326. the case in previous versions of OS/2. 
  2327.  
  2328. The progress indicator control window class allows applications to display 
  2329. progress information for long-running operations, in a consistent manner.  The 
  2330. implementation of this capability as a control window eliminates the need for 
  2331. application developers to explicitly code such function into their programs. 
  2332.  
  2333. Functional enhancements have been made to IPF under OS/2 Version 2.0, resulting 
  2334. in greater functionality and flexibility in information panels produced for 
  2335. help files or online documentation.  This enhancements includes support for 
  2336. multiple viewports, support for multiple fonts and character sizes. 
  2337.  
  2338.  
  2339. ΓòÉΓòÉΓòÉ 14. Workplace Shell Components ΓòÉΓòÉΓòÉ
  2340.  
  2341. OS/2 Version 2.0 provides an improved user shell, that is, the component of the 
  2342. operating system which is responsible for the appearance and behavior of the 
  2343. user interface.  This shell is based upon the 1991 IBM Systems Application 
  2344. Architecture (SAA) Common User Access (CUA) Workplace Environment, and is known 
  2345. as the Workplace Shell. 
  2346.  
  2347. One of the historical drawbacks of the OS/2 environment has been the power and 
  2348. therefore the complexity of the operating system.  Much of this complexity has, 
  2349. in the past, been allowed to transfer itself to the user interface, thus often 
  2350. requiring a large amount of user effort to complete a task. 
  2351.  
  2352. The objective of the Workplace Shell is to simplify and facilitate the 
  2353. performance of work tasks by an end user through the use of graphics and the 
  2354. direct manipulation of icons on the screen.  The Workplace Shell aims to 
  2355. insulate the end user from the complexity of the OS/2 operating system, 
  2356. requiring less effort to complete a particular task, thereby reducing the level 
  2357. of knowledge and experience required for the user to successfully manipulate 
  2358. the system. 
  2359.  
  2360. Figure "Workplace Shell Desktop Appearance" 
  2361.  
  2362. In addition, the Workplace Shell provides a more consistent user interface by 
  2363. implementing the additional control window classes and standard CUA functions 
  2364. provided under OS/2 V2.0, thereby easing the task of working with multiple 
  2365. applications concurrently, and of learning new applications. 
  2366.  
  2367.  
  2368. ΓòÉΓòÉΓòÉ 14.1. CUA and the Workplace Shell ΓòÉΓòÉΓòÉ
  2369.  
  2370. In previous versions of OS/2, the user shell was designed to conform to the 
  2371. 1989 SAA CUA Graphical Model.  The Workplace Shell of OS/2 Version 2.0 now 
  2372. reflects the 1991 SAA CUA Workplace Environment. 
  2373.  
  2374. In May 1989 (as part of the OfficeVision* announcement) IBM announced an 
  2375. extended role for the programmable workstation in the SAA environments.  Part 
  2376. of this announcement, known as CUA 89, introduced the Workplace extension to 
  2377. CUA's graphical model.  This workplace environment defined a more 
  2378. object-oriented approach to interaction with the system through direct 
  2379. manipulation of objects. 
  2380.  
  2381. In September 1991 IBM announced extensions to the SAA architecture. Included in 
  2382. these extensions was CUA 91, an orderly growth from CUA 89.  CUA 91 enhances 
  2383. the object-based user interface defined in CUA 89.  Rather than interacting 
  2384. with applications, users interact with objects which represent the inputs and 
  2385. outputs of their jobs.  The Workplace Environment is based upon the metaphor of 
  2386. the  user's working environment, with objects such as forms, letters, an 
  2387. address book, printers etc., represented on an electronic desktop using 
  2388. graphical symbols known as icons. 
  2389.  
  2390. CUA 91 has an increased emphasis on direct manipulation; that is, the 
  2391. manipulation of workplace objects through their representative icons on the 
  2392. desktop.  This allows the user to concentrate more on the task at hand, and 
  2393. less on the mechanism that must be employed.  The user is presented with a 
  2394. number of icons, each of which is a pictorial representation of the real 
  2395. underlying object which in fact controls the data. 
  2396.  
  2397. CUA 91 also introduces a number of new controls.  Perhaps the most noticeable 
  2398. of these is the notebook control.  This control allows an application to 
  2399. present a multi-page dialog (for example, a pad of blank forms, a log or 
  2400. register, or a set of reference notes). The notebook control provides a more 
  2401. meaningful way of providing an electronic metaphor of complex objects than a 
  2402. series of dialog boxes or other secondary windows. 
  2403.  
  2404. Extensive documentation for CUA 91 exists in the form of the IBM Systems 
  2405. Application Architecture CUA Advanced Guide to User Interface Design and the 
  2406. IBM Systems Application Architecture CUA Advanced Interface Design Reference. 
  2407. However, the best way to appreciate the spirit behind CUA 91 is to view the 
  2408. demonstration "The CUA Vision - Bringing the Future into Focus."  This 
  2409. demonstration is based on a version of CUA beyond CUA 91.  It does, however, 
  2410. bring home very vividly the essence of CUA 91: pervasive interaction with 
  2411. workplace objects (represented by icons and other graphical controls) through 
  2412. direct selection and manipulation.  As will be seen in this demonstration, the 
  2413. user is not aware of applications as such. Business processes are completed as 
  2414. a result of a natural and meaningful interaction with objects. 
  2415.  
  2416.  
  2417. ΓòÉΓòÉΓòÉ 14.1.1. Icons ΓòÉΓòÉΓòÉ
  2418.  
  2419. Studies have shown that the human eye can identify and distinguish graphical 
  2420. information more easily and effectively than textual information, and that 
  2421. visual appeal is an important motivating factor in the workplace.  The 
  2422. Workplace  Environment makes extensive use of icons to represent objects 
  2423. related to user's work tasks.  Icons provide a very effective means of 
  2424. identifying a required object, particularly where many possibilities are 
  2425. displayed to the user.  Still it is advisable not to put too many icons into 
  2426. any workplace.  Depending on the user, more than 10 to 20 icons in a given area 
  2427. may be confusing.  A graphical environment encourages an orderly arrangement. 
  2428.  
  2429. The icon is a two-dimensional depiction of the object.  It should resemble the 
  2430. physical object it represents but it should also resemble what the user 
  2431. recognizes as an object of that type.  For example, if the user expects a 
  2432. printer to look like the one in Figure "Workplace Shell Desktop Appearance", 
  2433. then an accurate portrayal of an IBM 4029 Page Printer is not going to be easy 
  2434. for that user to recognize and find; the user will have to read the title below 
  2435. the icons to locate a printer. 
  2436.  
  2437. A detailed discussion of these issues can be found in the Icon Reference Book, 
  2438. SC34-4348. 
  2439.  
  2440. The icon editor is part of OS/2.  The user can change the icon of any object 
  2441. from its Settings view. The "General" page shows the current icon and offers 
  2442. the option to edit that icon.  When "Edit" is selected, the Icon Editor is 
  2443. invoked. 
  2444.  
  2445.  
  2446. ΓòÉΓòÉΓòÉ 14.2. An Introduction to the WPS ΓòÉΓòÉΓòÉ
  2447.  
  2448. The Workplace Shell is radically different from previous versions of OS/2.  At 
  2449. first, it can make users of former versions of OS/2 feel insecure and it takes 
  2450. some time to really appreciate the many advantages of the new interface. 
  2451.  
  2452. OS/2 comes with a tutorial program that can help both experienced and new users 
  2453. learn how to use the elements of the Workplace Shell. This is started 
  2454. automatically once after the installation but can be called later at any time. 
  2455.  
  2456. The shell consists of an electronic desktop, on which are placed various icons. 
  2457. These icons represent objects such as folders, data files, program references 
  2458. and physical devices.  The icon tells the user about the object it represents. 
  2459. Some icons look like folders, while others look like printers. Others may look 
  2460. like a book, a car or an order form. 
  2461.  
  2462. It is important to understand that the symbols on the screen are just that.  A 
  2463. symbol (or icon) may represent a real object or it may be a shadow copy of a 
  2464. real object. The icon provides no differentiation between an object and its 
  2465. shadow copy, although description text of the shadow is gray. 
  2466.  
  2467. Deleting a shadow copy does not delete the real object. Therefore many large 
  2468. customers may prefer that their users work with shadow copies to prevent them 
  2469. accidentally deleting the real objects. 
  2470.  
  2471.  
  2472. ΓòÉΓòÉΓòÉ 14.2.1. The Desktop ΓòÉΓòÉΓòÉ
  2473.  
  2474. Background 
  2475.  
  2476. The background is the total space on the desktop. It is a special form of a 
  2477. container but follows all basic rules for a folder.  It has a context menu 
  2478. which is activated using mouse button 2.  Not all of the background may be 
  2479. visible. 
  2480.  
  2481. Size 
  2482.  
  2483. The desktop allows you to organize (or disorganize) documents and files the way 
  2484. you would on a real desktop. It cannot be smaller than the physical screen. 
  2485. This desktop concept helps the user to organize things and thereby focus on 
  2486. specific groups of objects. 
  2487.  
  2488. Enlarging the Desktop 
  2489.  
  2490. The size of the desktop starts out as large as the screen.  When more objects 
  2491. are put on the desktop than the basic size can hold the desktop will be 
  2492. extended automatically.  Scroll bars are added to the desktop if objects are 
  2493. put beyond the edges of the screen. 
  2494.  
  2495. Changing the Background 
  2496.  
  2497. The Workplace Shell allows the user to specify a color or a bitmap to use for 
  2498. the desktop background.  Individual colors or bitmaps may also be chosen for 
  2499. any folder in the system. 
  2500.  
  2501. The desktop background is specified from the Background page of the desktop 
  2502. Settings view.  The user may specify one of the following: 
  2503.  
  2504.  An image uses a single bitmap to cover the entire desktop.  The user has the 
  2505.   option to display: 
  2506.  
  2507.    - A normal image, where the bitmap is displayed at its normal size, centered 
  2508.      on the desktop or folder 
  2509.  
  2510.    - A tiled image, where the bitmap is repeated many times to cover the entire 
  2511.      desktop or folder 
  2512.  
  2513.    - A scaled image, where the bitmap is stretched to cover the entire desktop 
  2514.      or folder. 
  2515.  
  2516.  A color simply sets the entire desktop background to the required color. 
  2517.  
  2518. A bitmap may be designed using various graphics packages, or may be standard 
  2519. bitmap-format files obtained from other sources.  A number of public bulletin 
  2520. board services contain repositories of such bitmaps. 
  2521.  
  2522.  
  2523. ΓòÉΓòÉΓòÉ 14.2.2. Objects On The Standard Desktop ΓòÉΓòÉΓòÉ
  2524.  
  2525. In previous versions of OS/2 the icons represented applications, but in the 
  2526. Workplace Shell they may represent both applications and objects. The 
  2527. appearance of an object can be either "general" or "personal". 
  2528.  
  2529. The general appearance is usually inherited from the class to which the object 
  2530. belongs. There is no way, short of programming, to change the class icons, such 
  2531. as folders and data files, which are shipped with the Workplace Shell. However, 
  2532. any icon can be individually changed, or "personalized", by the user. Icons 
  2533. which have been changed are stored in the Extended Attributes of the object. 
  2534.  
  2535. When the user starts OS/2 V2.0, the following objects are visible on the 
  2536. desktop: 
  2537.  
  2538. Printer        This is the default printer attached to LPT1. 
  2539.  
  2540. Shredder       This deletes any object (icon) dropped on it. 
  2541.  
  2542. Minimized Window Viewer All minimized window's icons will be put into this 
  2543.                folder for easy access. 
  2544.  
  2545. OS/2 System    This folder contains the objects which allow the user to tailor 
  2546.                certain properties of the operating system, such as mouse 
  2547.                characteristics, screen colors and fonts. 
  2548.  
  2549. Start Here     This provides the user with a quick overview of the system. 
  2550.                Details are found in the folder "Information". 
  2551.  
  2552. Information    Several objects containing information, like Tutorial and 
  2553.                Command Reference, are held in this folder. 
  2554.  
  2555. Master index   This object provides an index to all on-line documentation. 
  2556.  
  2557. Templates      The contents of this folder allow the user to create new files, 
  2558.                folders, programs and various other objects. 
  2559.  
  2560. Drive A:       This container contains a directory listing of the diskette in 
  2561.                drive A:. 
  2562.  
  2563. Most data objects are presented to the user in folders, which act as containers 
  2564. to logically group sets of objects.  The objects within a folder may be 
  2565. rearranged by the user, and objects may be moved or duplicated between folders, 
  2566. allowing users to customize the desktop to suit their own working style. A user 
  2567. may place commonly accessed objects onto the desktop itself to avoid having to 
  2568. open a folder to access the required object. A typical example of a desktop is 
  2569. shown in Figure "System Setup". 
  2570.  
  2571.  
  2572. ΓòÉΓòÉΓòÉ 14.2.3. Objects And Views ΓòÉΓòÉΓòÉ
  2573.  
  2574. An object may have several visual representations, depending upon the nature of 
  2575. the user's interaction with the object. These representations (or views) can be 
  2576. changed by the user in order to show a different view of the objects. Figure 
  2577. "Different Views of the Same Objects" shows three views of the objects on the 
  2578. desktop. 
  2579.  
  2580.  
  2581. ΓòÉΓòÉΓòÉ 14.2.4. Customizing The Workplace Shell Objects ΓòÉΓòÉΓòÉ
  2582.  
  2583. The user may want to place the most frequently used objects in a way that is 
  2584. most comfortable for him. Furthermore, the user may want to add or change 
  2585. colors. Some of these requirements are supported on a global scale, others on 
  2586. an individual object basis. 
  2587.  
  2588. There are a few settings that are general to all applications. They can be 
  2589. found within the OS2 System folder under System Setup 
  2590.  
  2591. Colors 
  2592.  
  2593. A Color Palette and a Scheme Palette can be set for later use in modifying the 
  2594. appearance of windows.  Included in the Color Palette is the setting for the 
  2595. border width.  The information is stored in OS2.INI and can be changed easily 
  2596. for the whole system. 
  2597.  
  2598. Font Palette 
  2599.  
  2600. The palette of fonts available in the system can be changed by adding or 
  2601. deleting fonts.  Certain display attributes like underlining and bold display 
  2602. can be set from here.  Items can be dragged from the palette and dropped on the 
  2603. desired object(s). 
  2604.  
  2605. Mouse 
  2606.  
  2607. Quite a number of settings are available to control the behavior of the mouse 
  2608. buttons.  Changing them, however, may cause trouble if more than one person is 
  2609. using the system. 
  2610.  
  2611. Keyboard 
  2612.  
  2613. Timing, special needs (see Figure "Keyboard Settings Notebook") like sticky 
  2614. keys, and the mapping of the function keys are defined in this selection. 
  2615.  
  2616. Sound 
  2617.  
  2618. This variable can be used by an application to find out if beeps are generally 
  2619. wanted.  It does not stop an application from generating sound output. Clock 
  2620.  
  2621. The system clock can be displayed and various settings can be altered. 
  2622.  
  2623. Country 
  2624.  
  2625. The installation determines the settings like language group, keyboard, date 
  2626. and time formats. They can be changed at any time. 
  2627.  
  2628.  
  2629. ΓòÉΓòÉΓòÉ 14.2.5. Arranging Folders and Objects According to Tasks ΓòÉΓòÉΓòÉ
  2630.  
  2631. The user is free to create folders for all kinds of purposes.  The major reason 
  2632. for folders is the organization of tasks.  One folder may have all the objects 
  2633. in it which are needed for word processing, another one may be related to 
  2634. bookkeeping, and so on.  The user opens only the folder that is needed at the 
  2635. time  and therefore the desktop can be kept tidy. 
  2636.  
  2637. The user can "personalize" the folder for each task. For example, he can change 
  2638. the icon to help him find the folder more quickly. He can also make the folder 
  2639. into a work area; this tells the WPS to close any objects within the folder 
  2640. when the folder is closed and reopen them automatically when the folder is next 
  2641. opened. 
  2642.  
  2643. Figure "Workplace with Objects" 
  2644.  
  2645.  
  2646. ΓòÉΓòÉΓòÉ 14.3. Workplace Shell Objects ΓòÉΓòÉΓòÉ
  2647.  
  2648. There are three main classes of objects defined by CUA 91 and implemented in 
  2649. the Workplace Shell: 
  2650.  
  2651.  Device objects (such as printers and shredders) 
  2652.  
  2653.  Container objects (such as folders and work areas) 
  2654.  
  2655.  Data objects (such as files). 
  2656.  
  2657. Each object is represented on the desktop by an icon. 
  2658.  
  2659. Objects typically have a default action which is performed on other objects 
  2660. which are dropped on the object.  For example, a printer is a device from the 
  2661. user's perspective.  However, it also is a container since it can queue several 
  2662. files.  A shredder is a device which deletes the objects dropped on it.  A 
  2663. diskette is a container which stores the objects dropped on it. 
  2664.  
  2665. The objects found in the Workplace Shell are discussed in this section. 
  2666.  
  2667.  
  2668. ΓòÉΓòÉΓòÉ 14.3.1. Device Objects ΓòÉΓòÉΓòÉ
  2669.  
  2670. Device objects have certain common behaviors; they perform some physical action 
  2671. on an object dropped on them.  Objects such as containers and data also perform 
  2672. an action on the objects dropped on them, but the user does not normally 
  2673. perceive a physical connection between the icon and a "real-world" object. 
  2674.  
  2675.  
  2676. ΓòÉΓòÉΓòÉ 14.3.2. Container Objects ΓòÉΓòÉΓòÉ
  2677.  
  2678. As the name implies these objects are organizational helpers. As in an office, 
  2679. a container holds the objects you are dealing with. They can store any WPS 
  2680. object, including other containers. The standard container in the Workplace 
  2681. Shell is the folder. A folder icon looks, by default, like a manila (cardboard) 
  2682. folder. They are often "personalized" by the user or administrator for easier 
  2683. identification on a cluttered desktop. 
  2684.  
  2685. Container objects may be folders or work areas. Both types of containers appear 
  2686. and behave in a similar manner; the user can copy or move an object between any 
  2687. container, either folder or work area. 
  2688.  
  2689. Folders 
  2690.  
  2691. A folder can store and display any kind of Workplace Shell object, but it has a 
  2692. "passive" nature. Even while objects can be opened or started from within a 
  2693. folder, it just stores them and doesn't know anything about them. 
  2694.  
  2695. Work Areas 
  2696.  
  2697. In contrast to folders, a work area is not completely passive. If an object in 
  2698. a work area has been opened with a different view and the work area is being 
  2699. closed, all the "dependent" views will be closed too. 
  2700.  
  2701.  
  2702. ΓòÉΓòÉΓòÉ 14.3.3. Data Objects ΓòÉΓòÉΓòÉ
  2703.  
  2704. Data objects may be text files, drawings and spreadsheets. These are said to be 
  2705. of different "types". The object type can be set by the user and is used in a 
  2706. variety of operations such as sorting and assigning associations. Data objects 
  2707. are associated with an "object handler"; this is a generic term for a program 
  2708. that is used with the object. 
  2709.  
  2710. When the user double clicks the mouse on the icon, the contents of the object 
  2711. are displayed by the object handler in a window.  When the window is closed, 
  2712. the object handler saves its data and the location and state of the window for 
  2713. the next time it is opened. 
  2714.  
  2715. When an object is dragged to a container it is moved there.  When it is dragged 
  2716. to a device, the default action depends on the device; the contents are copied 
  2717. to a printer or diskette, but moved to a shredder. When an object is dragged to 
  2718. another data object, the result depends upon whether the target object knows 
  2719. what to do with the object being dragged.  To achieve this, there must be a 
  2720. communications protocol by which the objects may communicate with one another, 
  2721. and an agreement on which commands are understood. These considerations are 
  2722. discussed in Presentation Manager and Workplace Shell Application Development. 
  2723.  
  2724.  
  2725. ΓòÉΓòÉΓòÉ 14.3.4. Reference Books ΓòÉΓòÉΓòÉ
  2726.  
  2727. The Information folder contains the reference books that were selected during 
  2728. the installation of OS/2 V2.0 and any other materials added later. The 
  2729. installation process allows the user to select from: 
  2730.  
  2731.  Command Reference 
  2732.  
  2733.  REXX Reference 
  2734.  
  2735.  Glossary. 
  2736.  
  2737.  
  2738. ΓòÉΓòÉΓòÉ 14.3.5. Program References and Shadows ΓòÉΓòÉΓòÉ
  2739.  
  2740. Many of the items a user works with are program references and shadow copies of 
  2741. objects.  This arrangement allows him to have objects in many places and still 
  2742. use them as if the original was used.  The Workplace Shell supports this 
  2743. concept through various functions like drag and drop, menu selections and 
  2744. object settings.  The user has to make sure that this support system is not 
  2745. violated through copies and deletions from the command line or from a program. 
  2746.  
  2747.  
  2748. ΓòÉΓòÉΓòÉ 14.3.6. Drives ΓòÉΓòÉΓòÉ
  2749.  
  2750. The Drives icon opens to a view of all disk drives in the system; these are 
  2751. called Drive icons. After "login" to the LAN, any network drives assigned to 
  2752. the user will also be shown here. 
  2753.  
  2754. Drive icons are container objects which display the contents of the directories 
  2755. available to the user. A Drive object represents the "disk partition" and is, 
  2756. therefore, an abstract, non-copyable object. When a Drive icon is opened, the 
  2757. same Drive icon is seen within it; the difference is that the icon now 
  2758. represents the root directory of that partition and is copyable. Thus a root 
  2759. folder can be copied but a disk partition can't. 
  2760.  
  2761. Figure "Local Drives and LAN Drives" shows the drives folder after Login. 
  2762.  
  2763. Directories contain, as before, data, programs and so on.  Information 
  2764. pertaining to some of the files may, however, be stored in the OS2.INI file as 
  2765. described in Workplace Shell Implementation. Copying or deleting a file is 
  2766. therefore a non-trivial exercise for OS/2 V2.0 and should be done through the 
  2767. Workplace Shell to ensure integrity. The folder mechanism allows files to be 
  2768. moved and copied within the subdirectories of the main desktop directory. The 
  2769. Drive icons provide the equivalent mechanism for all the directories accessible 
  2770. to the user. 
  2771.  
  2772. More information can be seen through the Settings view. This makes it easy for 
  2773. the end user but harder for the administrator who now needs to understand much 
  2774. more about how the system works. 
  2775.  
  2776. The Drives folder is, partially, what the File Manager was in OS/2 Version 1.3. 
  2777. The main differences stem from the object-oriented view which is different from 
  2778. the hierarchical nature of the PM File Manager. The only hierarchy visible is 
  2779. in the tree view of a drive or a folder. 
  2780.  
  2781. "Sort" can be selected in both the details and icon views. The sort criteria 
  2782. here are different from the purely filename-oriented view of the File Manager 
  2783. because the extension of a filename has limited importance. The type of a file 
  2784. is determined by either OS/2 V2.0 or by the user. It can then be used to sort 
  2785. the folder contents. 
  2786.  
  2787. For example, when "sort by type" is selected, all executable files are in one 
  2788. group and are sorted by name within that group.  This block can thus include 
  2789. files with the extensions EXE, CMD and COM mixed within it. 
  2790.  
  2791. The drives folders do not display only the files contained in a directory. They 
  2792. also show any shadow copies or program references which may exist in the folder 
  2793. associated with that directory. Folders are linked to subdirectories of the 
  2794. main desktop directory. This information is stored in the OS2.INI file, as 
  2795. described in The OS2.INI File, and in the directory Extended Attributes (EAs). 
  2796. This applies to both local objects on the workstation and objects on the LAN 
  2797. drives used by the workstation. 
  2798.  
  2799.  
  2800. ΓòÉΓòÉΓòÉ 14.3.7. The Shredder Object ΓòÉΓòÉΓòÉ
  2801.  
  2802. The Workplace Shell includes a shredder object, which allows a user to easily 
  2803. delete an object from the system.  The shredder object is represented on the 
  2804. desktop by an icon resembling a paper shredder, as shown in Figure "Shredder 
  2805. Object With A Folder For Deletion".  An object can be deleted by dragging the 
  2806. object over the shredder icon and dropping it there. 
  2807.  
  2808. Objects may, of course, also be discarded by selecting the Delete option from 
  2809. any File or Object Class pull-down menu. 
  2810.  
  2811.  
  2812. ΓòÉΓòÉΓòÉ 14.3.8. Printer Objects ΓòÉΓòÉΓòÉ
  2813.  
  2814. Within the Workplace Shell, each possible print object is represented as a 
  2815. separate printer icon.  The print object is composed of the printer queue and 
  2816. the ports serviced by that queue.  However, the joint nature of the printer 
  2817. object is not apparent to the end user, who sees only the printer object, both 
  2818. when installing and when using a printer.  This removes a major source of 
  2819. confusion with previous versions of OS/2. 
  2820.  
  2821. Each printer object has an object name and is represented on the desktop by an 
  2822. icon.  A user may direct objects to be printed by dragging and dropping the 
  2823. required object over the printer object. 
  2824.  
  2825. A printer object may be opened, and displays a window containing the name and 
  2826. status of each print job currently in the queue, as shown in Figure "Job List 
  2827. View of Print Object".  The user may select any job and view information on 
  2828. that job, hold or release the job in the queue, or discard the job from the 
  2829. queue.  A printer object may be accessed for drag and drop operations when 
  2830. opened, as well as in its closed icon state. 
  2831.  
  2832. The printer object window includes a menu with items allowing the user to view 
  2833. and alter properties of the printer object.  Selecting an option from this menu 
  2834. causes a notebook control to be displayed, allowing the following items to be 
  2835. viewed or altered: 
  2836.  
  2837.  Printer port used by the print object 
  2838.  
  2839.  Name of the printer driver 
  2840.  
  2841.  Printer options 
  2842.  
  2843.  Queue options 
  2844.  
  2845.  Network options 
  2846.  
  2847.  Pooling options. 
  2848.  
  2849. In order to create a new printer object, a user may select the Copy option 
  2850. which creates a new printer object identical to the current printer object. 
  2851. The desired properties may then be altered and the new object renamed to 
  2852. reflect the changes.  For example,  the original may print "portrait," but the 
  2853. copy can be changed to print "landscape" on the same printer. 
  2854.  
  2855. For more information on printing, refer to OS/2 Version 2.0 - Volume 5:  Print 
  2856. Subsystem. 
  2857.  
  2858.  
  2859. ΓòÉΓòÉΓòÉ 14.3.9. Templates ΓòÉΓòÉΓòÉ
  2860.  
  2861. A very important part of the object-oriented philosophy is that the user does 
  2862. not load a program and subsequently create a file from the program.  Instead, 
  2863. the user works with objects he creates by "cloning" from an existing template. 
  2864. The Workplace Shell allows the user to create unique templates for the 
  2865. different file layouts and use them with the same application. This is 
  2866. discussed further in Setting up the Users Work Area. 
  2867.  
  2868. Contents after Installation of OS/2 
  2869.  
  2870. The templates folder contains several common templates like data files, bit 
  2871. maps, folders, and icons which can serve as models for the user's objects.  A 
  2872. template behaves like a pad of paper that you can drag a page off but the pad 
  2873. never ends. 
  2874.  
  2875. Figure "Templates After Full Installation" 
  2876.  
  2877. Changes a User Can Make 
  2878.  
  2879. Users can create an object from the template that comes closest to the type of 
  2880. object that is needed.  This object then can be modified to conform precisely 
  2881. to the users' needs and made into a new template. 
  2882.  
  2883. For example, a "data file" can be dragged from the data file template and put 
  2884. into a work area. The file is then modified to the company memo layout and the 
  2885. standard headings and text are entered. The modified object is then made into a 
  2886. template from which new company memos can be created. 
  2887.  
  2888. Figure "Example of a Folder With User Templates" 
  2889.  
  2890. The administrator has to make sure that the program that is intended to work 
  2891. with this template has the appropriate association.  Now, when an object has 
  2892. been created from the template and has been named properly, a double click on 
  2893. the object starts the program to work with that object.  Figure "Example of a 
  2894. Menu Showing the Association" shows an object derived from a user template with 
  2895. a cascaded menu showing the association with a program. 
  2896.  
  2897.  
  2898. ΓòÉΓòÉΓòÉ 14.4. The LAN Independent Shell ΓòÉΓòÉΓòÉ
  2899.  
  2900. The LAN Independent shell is part of OS/2 V2.0 and an integral part of the WPS. 
  2901. If you have one or more requesters started in your CONFIG.SYS, an icon appears 
  2902. on the desktop labelled Network. Opening the Network folder shows an icon for 
  2903. each network type, such as LAN Server or Novell Netware**. 
  2904.  
  2905. The objective of the LAN independent shell is make the use of LAN resources as 
  2906. simple as possible while still giving users the information they require. There 
  2907. is no longer any need for a user to switch to the full screen interface of the 
  2908. LAN Requester to use LAN resources, they are now integrated into the Workplace 
  2909. Shell 
  2910.  
  2911. Access to the LAN is provided by a series of folders: 
  2912.  
  2913.  Network folder on the desktop 
  2914.  
  2915.  LAN Server folder(s) controlling the access 
  2916.  
  2917.  LAN Server(s) structure within the network. 
  2918.  
  2919. The LAN independent shell is loaded into the Workplace Shell when the LAN 
  2920. Requester is installed. The system indicates to the user that the LAN resources 
  2921. are available by displaying the Network icon. Any folders that the user does 
  2922. not have access to are not displayed. 
  2923.  
  2924. The LAN Server folder settings show whether a server can be accessed with or 
  2925. without "login". Figure "Tree View of the LAN Server" shows the relationship of 
  2926. the Network and LAN Server folders to the LAN servers and the available folders 
  2927. within them. The LAN folder structure is similar to the structure on the user's 
  2928. own local disk. 
  2929.  
  2930.  
  2931. ΓòÉΓòÉΓòÉ 14.4.1. Using the LAN Independent Shell ΓòÉΓòÉΓòÉ
  2932.  
  2933. Opening the LAN Server domain icon shows all the servers you are connected to. 
  2934. However, you cannot open this folder until you are logged on. If you try to 
  2935. open it before being logged on, you are prompted for a "user ID" and password 
  2936. before this folder will be opened. Each server can then be opened to show the 
  2937. network resources of either disks or printers. The Public Applications folder 
  2938. is provided by the LAN Server and not the shell, hence it is just placed on the 
  2939. desktop. 
  2940.  
  2941. LAN disks behave just like local drives and the LAN printers behave like local 
  2942. printers. You can drag any network objects onto your desktop to be used later 
  2943. or the next time you start your machine; this saves going back to the network 
  2944. folder. Note that this process creates shadow copies of these objects, not real 
  2945. copies; these will be grayed out until the "login" is completed. 
  2946.  
  2947. Now you have folders, files and printers that behave just like local objects. 
  2948. All the standard shell operations of drag/drop, move, copy, shadow, opening and 
  2949. settings are available. For example, you can associate a program on the network 
  2950. with a data file on your local disk or network disk. The only restriction is 
  2951. that if you do operations on a network disk that affect the contents of that 
  2952. disk, then you need Read/Write (R/W) permission for that disk. 
  2953.  
  2954. There is one aspect of the LAN independent shell which may appear as an 
  2955. inconsistency to some users. While you can see any program and data files on 
  2956. remote servers, you cannot see program references or shadow copies within the 
  2957. server. This is due to the design of the Workplace Shell. The WPS only knows 
  2958. about shadows and program reference objects stored in its own OS2.INI file. The 
  2959. WPS on your system cannot read the OS2.INI file on another (remote) system. 
  2960. Therefore any shadows or program references defined within that remote system 
  2961. are rendered invisible to it. 
  2962.  
  2963. For example, if a user could access the root drive of an OS/2 V2.0 LAN Server, 
  2964. he could use Drives to view the desktop structure on that system. However, the 
  2965. System Setup folder would appear to be empty. This is because the objects 
  2966. stored in that folder are program references, that is, they are pointers to 
  2967. programs in the OS2.INI file on the server. 
  2968.  
  2969. See Workplace Shell Implementation for a detailed explanation of how Workplace 
  2970. Shell objects are implemented. 
  2971.  
  2972.  
  2973. ΓòÉΓòÉΓòÉ 14.4.2. Main Functions ΓòÉΓòÉΓòÉ
  2974.  
  2975. The LAN independent shell allows you to move or shadow the Network folder in 
  2976. any other folder. It has the following functions and features: 
  2977.  
  2978.  Ability to access multiple networks at the same time 
  2979.  
  2980.    - IBM LAN Server requester for 2.0 (requires a LAN Server Version 1.3 or 
  2981.      2.0) 
  2982.    - Novell Netware requester for 2.0 (requires a Novell Netware Version 2.2, 
  2983.      3.10 or 3.11 server). 
  2984.  
  2985.  Ability to login/logout to networks/servers or resources through the WPS 
  2986.  
  2987.    - The appropriate login dialog is displayed (if necessary) before a network 
  2988.      object can be accessed 
  2989.    - This is also available from the login/logout context menu items. 
  2990.  
  2991.  Ability to browse available servers and resources on the LAN 
  2992.  
  2993.    - Resources are either shared disks or shared printers 
  2994.    - To open a resource, double click on the network or server icons required. 
  2995.  
  2996.  Resources can be moved onto the desktop (or any folder) for easy, convenient 
  2997.   use both now and later. This information is not affected by the system 
  2998.   initial program load (IPL). 
  2999.  
  3000.    - Servers and shared disks can be shadowed into any folder including the 
  3001.      desktop 
  3002.    - Shared printers can be moved, copied or shadowed into any folder including 
  3003.      the desktop. 
  3004.  
  3005.  Seamless access to network folders and files 
  3006.  
  3007.    - Disk resources can be opened to show folders and files (which behave just 
  3008.      like those in the regular shell). The user can use programs or data files 
  3009.      from this network disk. 
  3010.    - Some applications may not be able to accept the universal naming 
  3011.      convention (UNC) filenames provided by the server, such as 
  3012.      \\SERVER\DISK\MYFILE.DAT. 
  3013.  
  3014.  Seamless access to network printers 
  3015.  
  3016.    - Printer resources can be opened to show queued jobs and job status 
  3017.    - Printer configuration automatically is set up on the requester's system 
  3018.      (the user only needs to install a printer driver as required) 
  3019.    - The user can only manipulate (hold, release or delete) his own jobs 
  3020.    - The administrator can manipulate all jobs and hold or release the printer. 
  3021.  
  3022.  Network printers can be defined to be the default printer 
  3023.  
  3024.    - No need for users to have local printers defined. If you use the COPY 
  3025.      command to print to a Novell server by assigning a port, you must ensure 
  3026.      you use the port name \DEV\LPT rather than just LPTn, where n takes a 
  3027.      value between 4 and 9. 
  3028.  
  3029.  A drive letter or port name can be assigned to a network disk or printer. 
  3030.  
  3031.    - Disks with assigned letters (for example X:) appear in the Drives folder 
  3032.    - Most applications are not network aware and cannot be run from a UNC path 
  3033.      (use the "assign drive" context menu item instead). 
  3034.  
  3035.  
  3036. ΓòÉΓòÉΓòÉ 14.4.3. LAN Server and Novell Netware Support ΓòÉΓòÉΓòÉ
  3037.  
  3038. In order to run both LAN Server and Netware requesters in the same machine the 
  3039. following configuration file changes are required: 
  3040.  
  3041. C:\CONFIG.SYS                     ensure DEVICE and RUN statements are in 
  3042.                                   correct order 
  3043.  
  3044. C:\NETWARE\NET.CFG                use the correct protocol bindings for Novell 
  3045.  
  3046. C:\IBMCOM\PROTOCOL.INI            use the correct protocol bindings for LAN 
  3047.                                   Server. 
  3048.  
  3049. The COEXIST.TXT file that is shipped with the Novell requester provides more 
  3050. information on this. 
  3051.  
  3052. APIs for the LAN Independent Shell 
  3053.  
  3054. The LAN Independent API is currently supported by Novell Netware and IBM LAN 
  3055. Server. 
  3056.  
  3057.  
  3058. ΓòÉΓòÉΓòÉ 14.5. Summary ΓòÉΓòÉΓòÉ
  3059.  
  3060. This chapter discussed many characteristics of the Workplace Shell, including 
  3061. the main WPS objects, the LAN independent shell objects and how they are 
  3062. combined to provide a comprehensive and consistent user interface. 
  3063.  
  3064. There are three main classes of objects within the Workplace Shell: devices, 
  3065. containers and data objects. Within each class there are many types or 
  3066. "subclasses" which have specific features to enable them to perform specialized 
  3067. functions. For example, both folders and work areas are a type of container but 
  3068. work areas have a unique characteristic of being able to close any programs 
  3069. which were started from them when the work area is closed. 
  3070.  
  3071. LAN integration in OS/2 V2.0 is now much easier, thanks to the LAN independent 
  3072. shell. Access to LAN resources is seamless, and objects can be accessed on the 
  3073. LAN, and then acted on, as if they were local objects. Several new icons, such 
  3074. as the Network folder, are placed on the desktop when LAN support is installed. 
  3075.  
  3076.  
  3077. ΓòÉΓòÉΓòÉ 15. Using the Workplace Shell ΓòÉΓòÉΓòÉ
  3078.  
  3079. To use the Workplace Shell (WPS) a user must understand the topics covered 
  3080. below. The user must know how to select an object, how to open a view (or 
  3081. window) of that object, and how to perform some basic actions on that object, 
  3082. such as printing, copying, creating, tailoring, and deleting. 
  3083.  
  3084. Most importantly, however, the user must start thinking about objects instead 
  3085. of applications.  The metaphor behind the Workplace Shell is data-centric 
  3086. rather than application-centric. Once the object/data is found, the operating 
  3087. system does the rest. Some of the navigation and operation can be done using 
  3088. the keyboard but it is almost impossible to work without a mouse. 
  3089.  
  3090.  
  3091. ΓòÉΓòÉΓòÉ 15.1. WPS Navigation and Techniques ΓòÉΓòÉΓòÉ
  3092.  
  3093. This section discusses the main techniques used to navigate around the 
  3094. Workplace Shell. The WPS supports user interaction through both mouse and 
  3095. keyboard although it should be stressed that the WPS focus on direct 
  3096. manipulation makes it much easier to use OS/2 V2.0 with a mouse than from the 
  3097. keyboard. 
  3098.  
  3099.  
  3100. ΓòÉΓòÉΓòÉ 15.1.1. Mouse ΓòÉΓòÉΓòÉ
  3101.  
  3102. Many actions can be performed upon an object simply by using the mouse. Table 
  3103. "Mouse Button Settings" provides a list of the main shell functions which can 
  3104. be activated using a mouse. 
  3105.  
  3106.  
  3107. ΓòÉΓòÉΓòÉ 15.1.2. Keyboard ΓòÉΓòÉΓòÉ
  3108.  
  3109. Though the graphical interface encourages the use of a mouse, the keyboard is 
  3110. still the main data entry device.  Once much of the work is done using the 
  3111. keyboard in applications like word processing the user may find the keyboard 
  3112. much faster and easier to use than the mouse. 
  3113.  
  3114. Besides the convenience aspect, some users may have a special need to operate 
  3115. OS/2 from the keyboard.  This may be helpful for handicapped people or in a 
  3116. certain environment where two or more keys cannot be depressed at the same 
  3117. time.  This is supported by the so-called sticky keys.  The sticky keys allow 
  3118. the use of several keys in a sequence instead of pressing them at the same 
  3119. time. 
  3120.  
  3121. Take, for example, a user who needs to press Alt+F5. With the sticky keys that 
  3122. can be done using one hand and pressing the keys sequentially within a time 
  3123. frame which can be set in the System Setup function. 
  3124.  
  3125.  
  3126. ΓòÉΓòÉΓòÉ 15.1.3. Accelerators ΓòÉΓòÉΓòÉ
  3127.  
  3128. CUA recommends that applications are written with both mouse and keyboard use 
  3129. in mind. To facilitate this, menus should be accessible through accelerators. 
  3130. Accelerators allow the user to access menus by depressing combinations of keys, 
  3131. usually Alt plus some letter. They also permit selection of a choice from a 
  3132. menu by a single letter. 
  3133.  
  3134. This does not necessarily work in applications that use those key combinations 
  3135. themselves. If, for instance, a menu provides "File" in a menu, then the 
  3136. capital F cannot be used within the application for a function like "Find". In 
  3137. those cases either the key combinations in the application have to be modified 
  3138. (often possible in a profile) or the mouse or function keys have to be used. 
  3139. Please note that uppercase and lowercase characters may be treated differently. 
  3140. This is one of the reasons why CUA demands that applications respect a number 
  3141. of definitions, for example F1=HELP. 
  3142.  
  3143.  
  3144. ΓòÉΓòÉΓòÉ 15.1.4. Object Manipulation Techniques ΓòÉΓòÉΓòÉ
  3145.  
  3146. Any movement of the mouse or any key causes some message that usually results 
  3147. in some selection or manipulation. Manipulation can be a copy, a change in 
  3148. appearance, an activation, or some other form of action. 
  3149.  
  3150. Traditional Approach 
  3151.  
  3152. Though the move from the command-line interface to the full-screen interface 
  3153. (with or without drop-down menus) changed the way of operation to an 
  3154. object-action sequence of work, the Workplace Shell is even more different. 
  3155.  
  3156. Let's take two examples. 
  3157.  
  3158.  1. Copy a file.  This involves: 
  3159.  
  3160.     Marking a file 
  3161.  
  3162.     Activating a menu or function key 
  3163.  
  3164.     Naming the destination 
  3165.  
  3166.     Performing the operation 
  3167.  
  3168.     Updating references, profiles, paths, and other related data. 
  3169.  
  3170.  2. Change colors.  This requires the user to: 
  3171.  
  3172.     Select a function from a menu 
  3173.  
  3174.     Define the appearance of the screen or window 
  3175.  
  3176.     Activate the changes for the whole application. 
  3177.  
  3178. Drag and Drop 
  3179.  
  3180. The most obvious way to act on an object is by dragging and dropping its icon 
  3181. using mouse button 2, sometimes called "direct manipulation". The user presses 
  3182. mouse button 1 to select objects and mouse button 2 to drag and drop them. The 
  3183. user simply moves the cursor to the object to be manipulated, depresses mouse 
  3184. button 2 to start the drag, holds the mouse button down while moving the cursor 
  3185. to the target, then releases mouse button 2 to drop the object. 
  3186.  
  3187. Using drag and drop to perform the same actions described above takes just a 
  3188. few simple steps in OS/2 V2.0: 
  3189.  
  3190.  1. Copy a file: 
  3191.  
  3192.     Make the file to be copied visible 
  3193.  
  3194.     Make the destination visible 
  3195.  
  3196.     Point with the mouse at the file object, depress mouse button 2 and drag 
  3197.      the object to the destination 
  3198.  
  3199.     Drop the object. 
  3200.  
  3201.     OS/2 does almost all changes to related data for you, such as changing 
  3202.     information about a shadow copy.  Some information, like a changed path, 
  3203.     has to be updated manually. 
  3204.  
  3205.  2. Change colors 
  3206.  
  3207.     Display the color palette or the scheme palette 
  3208.  
  3209.     Display the object to be colored 
  3210.  
  3211.     Drag the color icon or the scheme icon to the object and drop it. 
  3212.  
  3213.     The coloring can be done on an object basis or on an application basis. 
  3214.  
  3215. If an icon is dragged to a printer, the contents of the object are printed.  If 
  3216. the object is a file, then the file's contents are printed; if it is a folder, 
  3217. then a list of the folder's contents is produced.  In the same way, dropping an 
  3218. icon on the shredder deletes the object, while dropping it on a folder, 
  3219. workplace or diskette moves it into that object. 
  3220.  
  3221. The concept of direct manipulation implies that certain types of objects may be 
  3222. dropped in certain locations.  For example, a printer object cannot be dropped 
  3223. over another printer object, since it is logically impossible to print a 
  3224. printer.  It is therefore necessary to provide some form of indication as to 
  3225. whether a "drop" is allowed on a particular object. 
  3226.  
  3227. This is done visually, by altering the appearance of the icon representing the 
  3228. object being dragged, whenever a drop operation is not permitted.  When the 
  3229. icon is moved over an object or location where a drop is permitted, the 
  3230. destination object shows a box around it. However, this does not mean that the 
  3231. target object will actually be able to correctly handle the object to be 
  3232. dropped. 
  3233.  
  3234. As some of the functions cannot be done with just the two mouse buttons it may 
  3235. be necessary to use the Alt-, the Ctrl- or the Shift-key as a modifier.  For 
  3236. example, depressing the Ctrl-key when dragging an object causes a copy instead 
  3237. of a move operation. 
  3238.  
  3239. This is discussed in more detail in Presentation Manager and Workplace Shell 
  3240. Application Development and Workplace Shell Implementation. 
  3241.  
  3242.  
  3243. ΓòÉΓòÉΓòÉ 15.2. Basic Operation of the Workplace Shell ΓòÉΓòÉΓòÉ
  3244.  
  3245. This section describes how to perform some of the basic tasks available to 
  3246. Workplace Shell users. 
  3247.  
  3248.  
  3249. ΓòÉΓòÉΓòÉ 15.2.1. Accessing a Context Menu ΓòÉΓòÉΓòÉ
  3250.  
  3251. All objects have a context menu which is activated by pointing at the object 
  3252. and depressing mouse button 2 (this is also known as "popping up" a menu). 
  3253. These menus are contextual because the content depends on the capabilities of 
  3254. the individual object. They can often be extended by the user so new functions 
  3255. can be added to the object. 
  3256.  
  3257. Usually these context menus reflect the capabilities of a single object.  One 
  3258. has to be careful when selecting several objects and then activating the 
  3259. context menu of one of the objects.  This menu then shows only those choices 
  3260. which pertain to all of the selected objects. 
  3261.  
  3262.  
  3263. ΓòÉΓòÉΓòÉ 15.2.2. Opening a Window ΓòÉΓòÉΓòÉ
  3264.  
  3265. The user may view the contents of an object by double-clicking on the icon. 
  3266. Two things then happen: the icon background changes to inform the user that it 
  3267. is open, and a window appears with the contents displayed.  Most objects also 
  3268. support different views; for example, a folder may have a Details view, an Icon 
  3269. view and a Settings view where the user may customize certain features. 
  3270.  
  3271. A window in OS/2 V2.0 looks almost like any window in OS/2 Version 1.3, except 
  3272. that there is a different icon (called the small icon, mini-icon or title-bar 
  3273. icon) instead of the system menu icon.  This aids visual association of the 
  3274. icon with the object on the part of the end user. This icon does not, however, 
  3275. support the same drag and drop actions that can be performed by using the icon 
  3276. on the desktop.  The "old" minimize button has been replaced with a choice of a 
  3277. new minimize button (a small square) or a "hide" button.  The maximize button 
  3278. is now a large square. 
  3279.  
  3280. The user may also open a window by using its context menu; this menu is 
  3281. triggered by clicking mouse button 2.  The user may then select the Open choice 
  3282. from the menu. 
  3283.  
  3284. Figure "Different Objects - Different Functions" 
  3285.  
  3286. This results in a cascaded menu being displayed.  In the case of a folder the 
  3287. user can typically choose to look at the Settings, Details or Contents view of 
  3288. the object. This is an important characteristic of the Workplace Shell; the 
  3289. ability to work with different views of the same object helps the user to look 
  3290. beyond the windows and icons on the desktop to see the underlying objects and 
  3291. their relationships to real-world objects. 
  3292.  
  3293. The Details view looks similar to the OS/2 Version 1.3 File Managers list 
  3294. style.  The Icon view is used by folders to show the objects inside them.  All 
  3295. objects have a Settings view which is used to change the objects' properties. 
  3296.  
  3297.  
  3298. ΓòÉΓòÉΓòÉ 15.2.3. Finding Open Windows ΓòÉΓòÉΓòÉ
  3299.  
  3300. With Presentation Manager under previous versions of OS/2, when a window was 
  3301. minimized it would be shrunk to an icon and placed on the desktop.  The user 
  3302. could restore the window either by double-clicking mouse button 1 on its icon, 
  3303. or by using the Task List.  When the window was restored, the icon disappeared 
  3304. from the desktop and was replaced by the window. 
  3305.  
  3306. Under the Workplace Shell, when the user opens an object its icon remains on 
  3307. the desktop, but its background changes to show that it is open. When the user 
  3308. closes a window, the icon background changes to show that there is no longer an 
  3309. open window. 
  3310.  
  3311. If the window is minimized, the window disappears but the icon background does 
  3312. not change; this shows that the window is still open but has simply been 
  3313. "hidden." The system settings allow the user to choose between "hiding" and 
  3314. "minimizing" a window. There are a further two options for the minimize 
  3315. function. 
  3316.  
  3317. The first minimize option puts a Minimized Window folder on the desktop so that 
  3318. users can access any minimized windows from it, while the second puts the 
  3319. minimized windows directly on the desktop. This latter approach is more 
  3320. compatible with OS/2 Version 1.3 but may prove confusing to users. 
  3321.  
  3322. The Workplace Shell has replaced the Presentation Manager Task List with a 
  3323. Window List. The Window List represents all objects which are currently open or 
  3324. active, and allows the user to find and restore windows which are open but 
  3325. hidden.  The Window List can be accessed at any time by chording the mouse 
  3326. buttons over the desktop.  Subsequent selection of a single line with mouse 
  3327. button 1 and opening of the context menu with mouse button 2 offers various 
  3328. choices to select the desired view of the object. 
  3329.  
  3330.  
  3331. ΓòÉΓòÉΓòÉ 15.2.4. Creating A New Object ΓòÉΓòÉΓòÉ
  3332.  
  3333. To create a new object, the user can either use a template or simply make a 
  3334. copy of an existing object and change it.  Templates may be regarded as pads of 
  3335. blank forms; the user simply "peels off" a new instance of an object such as a 
  3336. folder.  The Workplace Shell creates a new icon of the requested type, which 
  3337. the user can then customize using the Settings view. 
  3338.  
  3339. To make a copy of an existing object, the user may either bring up a context 
  3340. menu and select the Copy choice from it, or use the Create-on-drag function by 
  3341. holding down the control key while dragging the icon to the required 
  3342. destination. 
  3343.  
  3344.  
  3345. ΓòÉΓòÉΓòÉ 15.2.5. Creating a Shadow Object ΓòÉΓòÉΓòÉ
  3346.  
  3347. An interesting new feature is the ability to make shadow copies of existing 
  3348. objects which can be placed in different folders or locations.  These shadow 
  3349. copies are linked to the original so that no matter which copy is changed, all 
  3350. copies are automatically updated.  Links between shadow objects are 
  3351. automatically maintained by the Workplace Shell.  These links are sometimes 
  3352. referred to as reference links. 
  3353.  
  3354. The user may create a shadow copy from the icon's context menu or by holding 
  3355. down the Ctrl and Shift keys while dragging the icon to the required 
  3356. destination.  If a shadow is created in this way, the system draws a line 
  3357. between the original and the shadow until the icon is released, so that the 
  3358. user knows that a shadow copy, rather than a "normal" copy, is being created. 
  3359.  
  3360. Program files should not be "shadowed" to a folder on the desktop. Instead, a 
  3361. new reference for that program should be created within that folder. This is 
  3362. done by opening the Templates folder and dragging a program object to the 
  3363. folder you wish to run the application from. This is described in the online 
  3364. reference documentation. 
  3365.  
  3366. Using a program reference to the executable (.EXE) file means that, when the 
  3367. user direct edits (Alt-mouse button 1) the icon description, he will not change 
  3368. the name of the executable file. Changing the filename could significantly 
  3369. confuse the Workplace Shell. This is also described in Shadow Copies of 
  3370. Programs. 
  3371.  
  3372.  
  3373. ΓòÉΓòÉΓòÉ 15.2.6. Deleting and Undeleting an Object ΓòÉΓòÉΓòÉ
  3374.  
  3375. Almost any object can be deleted by either dropping it on the shredder or by 
  3376. selecting Delete...  from the object's context menu. As in previous versions of 
  3377. OS/2, files and directories can be deleted from a command line. 
  3378.  
  3379. To help the user recover from accidentally deleting files from a command 
  3380. prompt, OS/2 can set up a special Delete directory on each logical drive. Each 
  3381. deleted file will be put into this directory until a user-specified size is 
  3382. reached.  Only then will the files really be deleted from the disk.  This will 
  3383. be done in a FIFO (First In, First Out) sequence. 
  3384.  
  3385. Files can be recovered easily if they are still in the DELETE directory by just 
  3386. copying them back to where they were.  If a file is already erased from the 
  3387. DELETE directory it may still be recoverable with the UNDELETE command. 
  3388.  
  3389.  
  3390. ΓòÉΓòÉΓòÉ 15.2.7. Printing ΓòÉΓòÉΓòÉ
  3391.  
  3392. The user wants to print specific types of output in an appropriate manner on 
  3393. the right paper.  So it should not matter to him how the system gets this done. 
  3394. All that is important is that the output is directed to some object that 
  3395. subsequently produces the desired printout. Therefore the concept of logical 
  3396. printers in a print manager was changed to the concept of printer objects. 
  3397.  
  3398. A printer object represents a certain arrangement of hardware, software, and 
  3399. specifications that are made to simplify the printing for the user. So, if 
  3400. printing is needed on three different sizes or types of paper then there will 
  3401. be three different printer objects, each for one specific type of output. 
  3402.  
  3403. Local OS/2 Printing 
  3404.  
  3405. For local printing everything is installed on the individual workstation and 
  3406. therefore it is simple to install a printer and the driver for it.  Other 
  3407. printer objects directing different output to the same printer can be quickly 
  3408. created using the Workplace Shell. 
  3409.  
  3410. Printing from DOS Programs 
  3411.  
  3412. The term DOS Printing refers to two different types of printing: 
  3413.  
  3414.  1. Printing from an OS/2 session with DOS-like commands (that is, PRINT, TYPE, 
  3415.     PrtScrn) 
  3416.  
  3417.  2. Printing from DOS applications using DOS device drivers. 
  3418.  
  3419. As DOS printing does not happen from the Workplace Shell there are also no 
  3420. icons to represent any destinations.  This also means that these functions are 
  3421. done in the traditional way by setting up a printer from within applications. 
  3422.  
  3423. DOS Programs are discussed in detail in OS/2 Version 2.0 - Volume 2:  DOS and 
  3424. Windows Environment. 
  3425.  
  3426. Remote Printing 
  3427.  
  3428. The process of remote printing can become a little bit more complicated because 
  3429. the setup for the destination printer is done on the print server.  For the 
  3430. local user, printer objects have to be created that reflect the functions on 
  3431. the server.  In addition, the local printer object has to indicate the status 
  3432. of the remote printer. 
  3433.  
  3434. Printing is described in more detail in OS/2 Version 2.0 - Volume 5:  Print 
  3435. Subsystem. 
  3436.  
  3437.  
  3438. ΓòÉΓòÉΓòÉ 15.2.8. Creating a Startup Environment ΓòÉΓòÉΓòÉ
  3439.  
  3440. In many cases a special setup for users is required. This setup can be created 
  3441. easily by putting shadows of programs to be run (for instance Communications 
  3442. Manager) into the Startup folder. This folder is opened when the operating 
  3443. system is initially loaded (known as "initial program load" - IPL - or "boot") 
  3444. and the applications in it are then started. 
  3445.  
  3446. Though a shutdown remembers the running applications and restarts them after 
  3447. booting the system there is still a need for the Startup folder. Shutdown only 
  3448. remembers what was running at the time, whereas the Startup folder has a fixed 
  3449. set of applications to start no matter if they were running at shutdown or not. 
  3450.  
  3451. Startup Folder Sequence 
  3452.  
  3453. It is also possible to order items in the Startup folder. First, display the 
  3454. folder using an ordered view (that is, anything except icon view non-grid). 
  3455. Then drag items into the folder in the required order. This can be useful for 
  3456. programs which are dependent on others being started before they are started. 
  3457.  
  3458.  
  3459. ΓòÉΓòÉΓòÉ 15.3. Advanced Operation of the Workplace Shell ΓòÉΓòÉΓòÉ
  3460.  
  3461. This section describes how to perform more advanced tasks for Workplace Shell 
  3462. users. 
  3463.  
  3464.  
  3465. ΓòÉΓòÉΓòÉ 15.3.1. Changing the Characteristics of an Object ΓòÉΓòÉΓòÉ
  3466.  
  3467. The Settings view for an object can be used to change characteristics such as 
  3468. color, font and icon bitmap, as well as other application-specific properties 
  3469. such as use of a menu bar or a context menu. 
  3470.  
  3471. The user may also change some attributes such as color and font by opening the 
  3472. color and font dialogs in the OS/2 System folder and dragging the desired color 
  3473. or font to the object.  If the color or font is dragged to the Templates 
  3474. folder, then the default settings are altered for all new objects created from 
  3475. the templates. 
  3476.  
  3477. As well as allowing the user to change the attributes of an object to be 
  3478. different from its parent, it also allows him to undo this so that the object 
  3479. inherits from its parent again. For example, if a color scheme is dropped on a 
  3480. folder, that folder will differ from the desktop. If a different scheme is then 
  3481. dropped onto the desktop via Alt-drag, that folder's attributes do not change. 
  3482.  
  3483. To get the folder to forget its color settings and inherit the desktop color 
  3484. scheme again, just drag the same scheme that was used for the desktop onto the 
  3485. folder with Alt-drag, that is, the same mechanism that was used to set the 
  3486. desktop colors. The folder will release its presentation parameters and accept 
  3487. the system default parameters which have been dragged to it. Any future changes 
  3488. to the desktop color settings will now be inherited by that folder. 
  3489.  
  3490.  
  3491. ΓòÉΓòÉΓòÉ 15.3.2. Modifying the Context Menu of an Object ΓòÉΓòÉΓòÉ
  3492.  
  3493. The experienced user may be able to add items to the context menus of selected 
  3494. objects.  The procedure is basically the same for any kind of object.  It is 
  3495. described here using the desktop menu. Figure "Expanded Desktop Menu" shows how 
  3496. the menu looks after the modification: 
  3497.  
  3498. All the modifications are made through the Settings view of the object.  For 
  3499. the desktop, this is accessed by clicking mouse button 2 on the desktop 
  3500. background. 
  3501.  
  3502. The following sequence will add "OS/2 Window" to the context menu of the 
  3503. desktop. When this choice is selected, an OS/2 Window Session will be started. 
  3504.  
  3505.  1. In the upper part of the notebook page ("Available menus") select "Primary 
  3506.     pop-up menu". 
  3507.  
  3508.  2. In the lower part  of the page ("Actions on menu"), select the "Create 
  3509.     another..." option. This will bring up the window shown in Figure "Setup of 
  3510.     an Expanded Menu". 
  3511.  
  3512.  3. Enter "OS/2 Window" in the "Menu item name" entry field. 
  3513.  
  3514.  4. Enter CMD.EXE in the "Program name" entry field. 
  3515.  
  3516.  5. Close the "Settings" menu. 
  3517.  
  3518.  6. Activate the menu and the newly added entry to verify that it was 
  3519.     successful. 
  3520.  
  3521. If the "Create another" choice under "Available menus" is selected then a 
  3522. further choice of "Cascade" or "Conditional cascade" is used to determine 
  3523. whether a secondary menu will be displayed. 
  3524.  
  3525.  1. Cascade means that the new entry will have a cascaded menu.  This is 
  3526.     indicated by an arrow. 
  3527.  
  3528.  2. Conditional cascade means that there will be a cascaded menu with a default 
  3529.     selection. This is indicated by a button with an arrow. 
  3530.  
  3531.  
  3532. ΓòÉΓòÉΓòÉ 15.3.3. Changing the Default View on "Open" ΓòÉΓòÉΓòÉ
  3533.  
  3534. The Workplace Shell allows users to change the default view of an object (that 
  3535. is, the view that opens when it is double clicked on). The "Open" entry in a 
  3536. primary menu is usually the only one that allows additions because it is 
  3537. application-oriented.  Once "Open" or one of the added entries is selected, the 
  3538. cascaded menu of this entry is addressed by the lower part of the notebook 
  3539. page.  Here the actual program names have to be entered under "Actions on 
  3540. menu".  After entries have been made here it is recommended that an existing 
  3541. choice be selected as the default option. 
  3542.  
  3543. For example, a user might want to change the Drive folder and objects so that 
  3544. the default view is "Details" instead of "Icons".  The following steps are 
  3545. used: 
  3546.  
  3547.  1. Open the Settings view and go to the "Menu" page. This page contains 
  3548.     "Primary pop-up menu" and "Open" headings. 
  3549.  
  3550.  2. Select "Open", then press the adjacent "Settings" button. 
  3551.  
  3552.  3. Select the cascade arrow next to "Default action", then pick the new 
  3553.     default view you want to use when you subsequently double click on the 
  3554.     icon. 
  3555.  
  3556.  4. Click on the "OK" push button. 
  3557.  
  3558.  5. Close the Settings view. 
  3559.  
  3560.  
  3561. ΓòÉΓòÉΓòÉ 15.3.4. Changing the Icon for an Object ΓòÉΓòÉΓòÉ
  3562.  
  3563. The Workplace Shell makes it easy to customize the appearance of the objects 
  3564. the user needs to use. The icon description can be changed by selecting it with 
  3565. "Alt-mouse button 1" or the icon and its text can both be changed from its 
  3566. Settings view. 
  3567.  
  3568. The "General" page of the objects Settings view gives you two ways to change 
  3569. the icon: Find and Edit. Find lets the user choose a new icon from those 
  3570. already created. Edit starts the icon editor to let you work with the icon; 
  3571. this can be used to modify the existing icon or to work with a different one. 
  3572.  
  3573. Please note that you must take care to edit the icon belonging to your 
  3574. particular "device"; that is, 32x32 and 16x16 icons for VGA/EGA, 40x40 and 
  3575. 20x20 for higher resolutions. The "Device" pull-down in the menu bar of the 
  3576. icon editor will let you do this. 
  3577.  
  3578. The Icon Editor is very flexible.  A user can: 
  3579.  
  3580.  Paste in a new icon from the clipboard, providing it was placed on the 
  3581.   clipboard before the Edit action was started 
  3582.  
  3583.  Use the icon editor menu bar to: 
  3584.  
  3585.     1. Select "Open..." to choose a new icon 
  3586.     2. Select "Save as..." to save it under the original filename for the old 
  3587.        icon that was first loaded into the icon editor (this is usually 
  3588.        x:\OS2\WP!n.ICO, where n is a number). 
  3589.  
  3590. When you have finished, close the window and respond "yes" to the prompt to 
  3591. save the changes. 
  3592.  
  3593.  
  3594. ΓòÉΓòÉΓòÉ 15.3.5. Associating an Object with a Program ΓòÉΓòÉΓòÉ
  3595.  
  3596. There are three ways to set up a data file object so that a program is started 
  3597. when the user double clicks on the data file icon.  These are: 
  3598.  
  3599.  1. Create a Filename association in the program settings 
  3600.  2. Create a Type association in the data file settings 
  3601.  3. Make the program name the default setting in the "Open" cascade menu for 
  3602.     the data file. 
  3603.  
  3604. An association is a special link which can be assigned to a program object. 
  3605. This link allows the user to specify which program will be invoked when the 
  3606. user double clicks on specified types of files, individual files, or files 
  3607. described by a global file name. 
  3608.  
  3609. Filename Association in a Program 
  3610.  
  3611. The major disadvantages of this approach are that it provides little 
  3612. flexibility to the user and it is not very robust. Any association is easily 
  3613. destroyed by changing the file extension and it is therefore only recommended 
  3614. for programs which do not support associations by "Type". 
  3615.  
  3616. The inflexibility of this method can be seen when a user subsequently wants to 
  3617. use a different program with his data file. To do this, he will have to either 
  3618. change the filename or add a new program to the "Open" menu and make it the 
  3619. default. Neither approach is suitable for the inexperienced user. 
  3620.  
  3621. A text editor may, for example, have associations for plain text files (that 
  3622. is, a type of file), the individual file CONFIG.SYS, and all files described 
  3623. with the global name READ*.*.  Whenever a file object that meets these criteria 
  3624. is selected with a double click, OS/2 will start the appropriate program 
  3625. object. The workings of the association mechanism are described in Workplace 
  3626. Shell Implementation. 
  3627.  
  3628. There are some editing strings for filenames and extensions that can be used 
  3629. with associations to allow parameters to be passed without having to fully 
  3630. specify the qualified filename (or parts of it): 
  3631.  
  3632. %*        Fully qualified path 
  3633.  
  3634. %%*P      Path with last backslash 
  3635.  
  3636. %%*D      Drive with  : or UNC name 
  3637.  
  3638. %%*N      Name without extension 
  3639.  
  3640. %%*F      Name with extension 
  3641.  
  3642. %%*E      Extension without period. 
  3643.  
  3644. Type Association in a Data File 
  3645.  
  3646. This is the preferred approach. It is described in more detail in Presentation 
  3647. Manager and Workplace Shell Application Development and Workplace Shell 
  3648. Implementation. The advantage of this approach is that it is easy for a user to 
  3649. use a different program with his object, simply by choosing a new "Type" in the 
  3650. Settings view. The process is simple: 
  3651.  
  3652.  1. Open the Settings view for the object 
  3653.  
  3654.  2. Select the "Type" page of the notebook 
  3655.  
  3656.  3. Select from the list of "Available types" 
  3657.  
  3658.  4. Press the "Add" button 
  3659.  
  3660.  5. Close the Settings window. 
  3661.  
  3662. Each program can be associated with a "Type" but, in practice, not all are. DOS 
  3663. programs are very unlikely to support the concept of file type associations. It 
  3664. will, therefore, probably be necessary to use the filename association 
  3665. technique for such files. 
  3666.  
  3667. If a program does not set a file type, the user can create a new one. This is 
  3668. described in Adding New File Types. 
  3669.  
  3670. Add a Default Program to the File Menu 
  3671.  
  3672. The process to do this is described in Modifying the Context Menu of an Object 
  3673. and Changing the Default View on "Open". This approach is limited to users who 
  3674. understand the workings of the Workplace Shell in some detail. Its main 
  3675. disadvantage is found when many existing files must be set up to use a 
  3676. particular program; each one must be modified separately. Under these 
  3677. circumstances the filename association would be preferred. 
  3678.  
  3679. If you are setting up a system for a new user, however, you can create one data 
  3680. file with the program set as the default on "Open" in the context menu, then 
  3681. make that file into a template so all new files subsequently created from it 
  3682. will inherit this attribute. 
  3683.  
  3684.  
  3685. ΓòÉΓòÉΓòÉ 15.4. Giving OS/2 V2.0 the Look and Feel of OS/2 Version 1.3 ΓòÉΓòÉΓòÉ
  3686.  
  3687. Users of earlier versions of OS/2 or of Microsoft Windows may not feel entirely 
  3688. at home when they first start the system. The graphical user interface (GUI) 
  3689. they are familiar with has been replaced by an object-oriented user interface 
  3690. (OOUI) which, while providing a clear, logical layout is very different. In 
  3691. general, if a user thinks about objects rather than programs, he will find it 
  3692. much easier to learn to use the WPS interface to its full extent. 
  3693.  
  3694. One of the big differences is that previously a user could start a new 
  3695. application, browse through the menus and scan the possible choices. This way 
  3696. it was fast and fairly easy to grasp the various functions of a program.  With 
  3697. the Workplace Shell, however, many functions are not program-specific functions 
  3698. any more but general capabilities of almost all objects.  It also means that 
  3699. certain functions are not needed any more in menus; they just exist as OS/2 
  3700. functions.  For example, the choice of a color or a font does not need to be in 
  3701. the menus of each program, the System Setup folder provide all the choices the 
  3702. user needs. 
  3703.  
  3704. If a user prefers the style of OS/2 Version 1.3 he can customize the system 
  3705. through the use of the .RC files that come with the installation diskettes. 
  3706. The procedure is fairly simple and can be done after the completion of a normal 
  3707. installation: 
  3708.  
  3709.  1. Boot the system from the "Installation" diskette 
  3710.  
  3711.  2. Use diskette 1 as directed 
  3712.  
  3713.  3. Exit from the "Welcome" screen 
  3714.  
  3715.  4. Change drive and current directory to C:\OS2 
  3716.  
  3717.  5. Modify OS2.INI with the command: 
  3718.  
  3719.         MAKEINI OS2.INI OS2_13.RC
  3720.  
  3721.  6. Restart the system. 
  3722.  
  3723. If you want to change back just follow the same procedure but make the OS2.INI 
  3724. modification with the command: 
  3725.  
  3726. MAKEINI OS2.INI OS2_20.RC
  3727.  
  3728. You should note, however, that the MAKEINI command generates a new OS2.INI file 
  3729. from the resource files which were shipped with the system. This means that the 
  3730. OS2.INI file is restored to the same state as when OS/2 V2.0 was first 
  3731. installed and any customization performed by the user, either to the Workplace 
  3732. Shell or the PM 1.3 shell, will be lost. 
  3733.  
  3734.  
  3735. ΓòÉΓòÉΓòÉ 15.5. Summary ΓòÉΓòÉΓòÉ
  3736.  
  3737. This chapter discussed many of the techniques supported by the Workplace Shell. 
  3738.  
  3739. The primary navigation techniques which let the user work with those objects 
  3740. are slightly different from those used by Presentation Manager V1.3, but are at 
  3741. the same time more consistent. The emphasis on direct manipulation helps 
  3742. provide much of this enhanced consistency but enforces the need for a user to 
  3743. have a mouse if he is to perform many basic tasks. 
  3744.  
  3745. The new WPS objects and techniques offer greatly increased flexibility for 
  3746. organizing work to suit the user. These objects can be rearranged to provide 
  3747. new ways of doing the kinds of activities most users are familiar with. In 
  3748. particular, direct manipulation allows users to perform activities with greater 
  3749. ease, and better feedback, than before. 
  3750.  
  3751. The Workplace Shell makes OS/2 V2.0 much easier to "personalize" than previous 
  3752. versions of OS/2. Users can easily change one object, the whole system and even 
  3753. the menus of individual items. The shell can even be made to look like OS/2 
  3754. Version 1.3 to suit the preferences of those users who are not yet ready to 
  3755. tackle an object-oriented user interface. 
  3756.  
  3757.  
  3758. ΓòÉΓòÉΓòÉ 16. Installing and Supporting the Workplace Shell ΓòÉΓòÉΓòÉ
  3759.  
  3760. This chapter discusses the issues associated with installing a system as 
  3761. complex and flexible as OS/2 V2.0. This is not a trivial topic; we must balance 
  3762. the needs of the user for a productive work environment with those of the 
  3763. administrator to be able to support him if problems arise. This requires 
  3764. careful management. 
  3765.  
  3766. Among the many things an administrator must consider are: 
  3767.  
  3768.  Allocating disk space 
  3769.  
  3770.  Setting up programs and files 
  3771.  
  3772.  Problem determination and resolution 
  3773.  
  3774.  Backup procedures 
  3775.  
  3776.  Use of a LAN from the Workplace Shell 
  3777.  
  3778.  System performance 
  3779.  
  3780.  Installing application programs. 
  3781.  
  3782. This chapter offers some guidance on these and other matters related to the 
  3783. installation, configuration and management of systems which include the 
  3784. Workplace Shell. It also includes an illustration of how the system might be 
  3785. set up for a particular user on his specific hardware configuration. 
  3786.  
  3787.  
  3788. ΓòÉΓòÉΓòÉ 16.1. Allocating Disk Space ΓòÉΓòÉΓòÉ
  3789.  
  3790. In this section we discuss how the effectiveness of the Workplace Shell may be 
  3791. affected by such considerations as: 
  3792.  
  3793.  Disk partitions 
  3794.  
  3795.  Choice of file system (HPFS versus FAT) 
  3796.  
  3797.  Location of the OS/2 desktop directory 
  3798.  
  3799.  Program set up 
  3800.  
  3801.  Placement of data and program files 
  3802.  
  3803.  DOS programs. 
  3804.  
  3805.  
  3806. ΓòÉΓòÉΓòÉ 16.1.1. Partitioning the Disk for OS/2 with the Workplace Shell ΓòÉΓòÉΓòÉ
  3807.  
  3808. A commonly asked question is "Is it more convenient to have one large disk 
  3809. partition than several smaller ones?" We do not believe that single disk 
  3810. partitions are the correct approach for OS/2 V2.0 workstations. 
  3811.  
  3812. Single partitions have certain advantages. They optimize the use of available 
  3813. disk space because both the operating system and applications can use what they 
  3814. need while not leaving unused space in the respective partitions. 
  3815.  
  3816. They are also simpler to set up. There can be logistical problems with multiple 
  3817. partitions, such as allocating enough space for dynamic system files such as 
  3818. the desktop, the SWAPPER.DAT and print spooler. 
  3819.  
  3820. On the other hand, there are several disadvantages to the single partition 
  3821. approach. 
  3822.  
  3823.  Multiple partitions let you keep system and user files separate so that the 
  3824.   system partition can be re-formatted if necessary. This can be very important 
  3825.   when planning to install a CSD or a new version of the operating system. 
  3826.  
  3827.  Performance can be impaired when a partition contains lots of directories. 
  3828.   For example, opening a tree view can take a long time on a large disk. 
  3829.  
  3830.  Support for multiple operating systems or versions of the same operating 
  3831.   system requires multiple partitions to be manageable. 
  3832.  
  3833.  
  3834. ΓòÉΓòÉΓòÉ 16.1.2. HPFS or FAT Format? ΓòÉΓòÉΓòÉ
  3835.  
  3836. The Workplace Shell introduces several new reasons for choosing the High 
  3837. Performance File System (HPFS) instead of the File Allocation Table (FAT) 
  3838. format for your most heavily used disks and partitions. The main ones are: 
  3839.  
  3840. Performance 
  3841.  
  3842. Although the FAT file system is much faster in OS/2 V2.0 than it was in OS/2 
  3843. Version 1.3, there are still areas where HPFS is faster. One major advantage is 
  3844. the reduction of disk fragmentation, discussed below. Another is the 
  3845. performance when reading large files; the "EA_DATA. SF" file on a FAT file 
  3846. system can exceed 600 KB, which could impair the performance of instantiating 
  3847. WPFileSystem objects. 
  3848.  
  3849. Fragmentation 
  3850.  
  3851. Since the WPS encourages users to move files around and create new folders 
  3852. (directories), the file system is more heavily used than it would be under DOS. 
  3853. Past experiences with heavily used DOS workstations and LAN Servers leads us to 
  3854. feel there is a distinct possibility that fragmentation will cause performance 
  3855. problems on FAT-based disks. 
  3856.  
  3857. Use of Extended Attributes 
  3858.  
  3859. Since Extended Attributes (EAs) are used extensively by all directories and 
  3860. files within the desktop structure, there are important considerations for file 
  3861. transfer between the different file systems. These EAs store settings 
  3862. information, such as file type, without which the system cannot function 
  3863. properly. In general, we recommend installing a common file system on all 
  3864. machines to prevent potential problems with lost EAs. EAs are discussed more 
  3865. fully in Extended Attributes and Extended Attributes. 
  3866.  
  3867. Long Filenames 
  3868.  
  3869. The WPS allows a user to rename a file by editing the icon description. On 
  3870. HPFS, this name will be stored as it is typed, including spaces. On FAT, 
  3871. however, the name is truncated by removing vowels. Not only might this cause 
  3872. problems with duplicate filenames, it also introduces an inconsistency between 
  3873. what the user sees in a folder and in drives which would not otherwise occur 
  3874. with HPFS. 
  3875.  
  3876. Support for Multiple Operating Systems 
  3877.  
  3878. Multiple operating systems may be required by some users. This would lead to 
  3879. the user installing different file systems on the various partitions to support 
  3880. the different operating systems. For example, a user might need to be able to 
  3881. boot from DOS occasionally, to run programs that don't work in a VDM. To do 
  3882. this he could format the C: partition as HPFS, for OS/2 V2.0, and the D: 
  3883. partition as FAT, for DOS. 
  3884.  
  3885.  
  3886. ΓòÉΓòÉΓòÉ 16.1.3. Keeping the Desktop Separate from the System ΓòÉΓòÉΓòÉ
  3887.  
  3888. When OS/2 is installed it sets up a directory called OS!2 2.0 Desktop on the 
  3889. boot drive, corresponding to the desktop work area. In this directory it 
  3890. installs some default objects for the user which the user can work with to 
  3891. subsequently create new folders and other objects for himself. 
  3892.  
  3893. The result is that user files are created on the same partition as the 
  3894. operating system. Many users would prefer to keep their data and programs in a 
  3895. separate partition from the operating systems, in case they have to format 
  3896. their partition to install a new release of the operating system. 
  3897.  
  3898. Fortunately, it is possible to move the desktop to another drive or partition, 
  3899. though this can only be done after installation - the OS/2 install program 
  3900. always puts it on the boot partition. The process to do this is simply: 
  3901.  
  3902.  1. Open the Drives object 
  3903.  
  3904.  2. Open a view of the drive on which the desktop currently resides 
  3905.  
  3906.  3. Drag the "OS!2 2.0 Desktop" directory object to the drive you want it to be 
  3907.     on. 
  3908.  
  3909. This will result in the desktop structure, with all its subdirectories, being 
  3910. physically moved to the new drive or partition. All references in OS2.INI to 
  3911. objects within the corresponding folders will be updated to reflect the change. 
  3912.  
  3913. If the user does have to reinstall his operating system, however, this approach 
  3914. may cause other problems in rebuilding the desktop. Among the factors to be 
  3915. considered are: 
  3916.  
  3917.  The WPS will install the desktop into the operating system by default, so the 
  3918.   user will now have two desktops 
  3919.  
  3920.  Any folders created by the user will not be in the new desktop 
  3921.  
  3922.  Any programs created by the user will not be in the new OS2.INI file 
  3923.  
  3924.  Programs may be given new HOBJECTs by the WPS as it installs them, so the 
  3925.   HOBJECTs in the users directories will now be different from those in the 
  3926.   OS2.INI file. 
  3927.  
  3928. The implementation of the Workplace Shell is discussed in Workplace Shell 
  3929. Implementation; an understanding of the way in which WPS objects are created 
  3930. and stored will help the user to decide how to structure his system. 
  3931.  
  3932.  
  3933. ΓòÉΓòÉΓòÉ 16.1.4. Moving the Print Spooler ΓòÉΓòÉΓòÉ
  3934.  
  3935. Moving the spooler can be done at any time. The process is very 
  3936. straightforward: 
  3937.  
  3938.  1. Open the OS/2 System folder 
  3939.  
  3940.  2. Find the System Setup folder and open it 
  3941.  
  3942.  3. Find the Spooler folder and open it 
  3943.  
  3944.  4. Specify the spool path in the dialog and close it 
  3945.  
  3946.  5. Reboot and your spooler will be moved. 
  3947.  
  3948. Remember to check that OS/2 V2.0 deleted the old SPOOL directory when it 
  3949. created the new one you specified. 
  3950.  
  3951.  
  3952. ΓòÉΓòÉΓòÉ 16.2. Setting Up Programs and Files ΓòÉΓòÉΓòÉ
  3953.  
  3954. There are several issues associated with setting up programs and files. Some of 
  3955. these issues, such as the physical location of programs and data, are also 
  3956. discussed in Using the Workplace Shell in a LAN Environment. This section 
  3957. discusses only those issues which affect all programs and files across local 
  3958. and remote disks, such as the use of Extended Attributes (EAs) and file 
  3959. associations. 
  3960.  
  3961.  
  3962. ΓòÉΓòÉΓòÉ 16.2.1. Extended Attributes ΓòÉΓòÉΓòÉ
  3963.  
  3964. Extended Attributes (EAs) are used extensively by the Workplace Shell. The 
  3965. settings data for any object are stored in EAs. File settings are stored in 
  3966. file EAs while folder settings and some content attributes are stored in 
  3967. directory EA files. 
  3968.  
  3969. On an HPFS partition, Extended Attributes are stored in a special, hidden area 
  3970. close to the files themselves. On a FAT file system, Extended Attributes are 
  3971. stored in a hidden file in the root directory of each FAT partition; this file 
  3972. is named "EA_DATA. SF" 
  3973.  
  3974. Not all file systems support EAs and this can cause problems when transferring 
  3975. files around a LAN or to diskette. For example, using files from a server using 
  3976. Novell Netware before Version 3.11, or using AIX*, would lead to the EAs being 
  3977. lost. This is also a problem for DOS programs, which do not understand EAs and 
  3978. therefore cannot write them when they replace a file. 
  3979.  
  3980. For a more complete discussion of how EAs are used in the Workplace Shell, 
  3981. refer to Extended Attributes. 
  3982.  
  3983.  
  3984. ΓòÉΓòÉΓòÉ 16.2.2. EAs for Files Used by DOS Programs ΓòÉΓòÉΓòÉ
  3985.  
  3986. While the Workplace Shell uses file EAs extensively to store settings 
  3987. information for File System objects, no DOS programs know how to handle them. 
  3988. This can cause problems when a DOS program does not write the EA back to the 
  3989. disk along with the file. Without its settings information, the file will lose 
  3990. information such as a modified icon or the file type. 
  3991.  
  3992. The problem occurs because many applications do not write back to the same file 
  3993. they read from. Instead, the applications typically perform the following 
  3994. actions: 
  3995.  
  3996.  When the user selects "Open", the program: 
  3997.  
  3998.     1. Opens the original file and reads it into memory 
  3999.  
  4000.     2. Closes the original file 
  4001.  
  4002.     3. Opens a new, temporary file 
  4003.  
  4004.     4. Lets the user edit, working with the copy in memory. 
  4005.  
  4006.  When the user selects "Save", or "Autosave" is invoked, the program: 
  4007.  
  4008.     1. Writes from memory to the temporary file. 
  4009.  
  4010.  When the user selects "Exit", the program: 
  4011.  
  4012.     1. Closes the temporary file 
  4013.  
  4014.     2. Erases the original file 
  4015.  
  4016.     3. Renames the new file to the original filename. 
  4017.  
  4018. Programs do this to reduce the likelihood of the original file being corrupted 
  4019. if the system crashes. The problem is that if the application does not know 
  4020. about EAs, then the above sequence will lose the EAs. All DOS and Windows 
  4021. applications are affected by this, although the problem is more likely to 
  4022. affect programs, such as word processors, which work with files rather than 
  4023. those which work with records within a file, like data base programs. 
  4024.  
  4025. To get around this, you could create a command file that would use EAUTIL to 
  4026. split the EAs from the file, invoke the DOS application and then, when the DOS 
  4027. application has finished, use EAUTIL to join the EAs back to the file. 
  4028.  
  4029. An alternative, though long-term, approach is replace DOS versions of these 
  4030. programs with OS/2 versions, which will not have this problem. 
  4031.  
  4032.  
  4033. ΓòÉΓòÉΓòÉ 16.2.3. Using Files Outside the WPS Directory Structure ΓòÉΓòÉΓòÉ
  4034.  
  4035. Setting up files to be used by the WPS where those files reside outside the 
  4036. "OS!2 2.0 Desktop" directory structure may cause some problems. This could 
  4037. apply, for example, to DOS programs which only look for files in a specific 
  4038. directory. These files can still be placed on the desktop, however. This is 
  4039. done by dragging a shadow copy of the file from the application directory to 
  4040. the desktop, using the Drives folder. 
  4041.  
  4042. However, the WPS does not receive every message from the file system concerning 
  4043. files which lay outside its workplace directory structure (that is, not under 
  4044. "OS!2 2.0 Desktop"). Notification is received if a new file is created or if an 
  4045. existing file is deleted or renamed, but not if an existing file is changed 
  4046. outside of the workplace. This lack of notification also applies to file EAs 
  4047. created or modified for files in a non-workplace directory. 
  4048.  
  4049. It is therefore always advisable to place all data files within the workplace 
  4050. directory structure, where possible. 
  4051.  
  4052.  
  4053. ΓòÉΓòÉΓòÉ 16.2.4. Setting Up Programs in the Workplace Shell ΓòÉΓòÉΓòÉ
  4054.  
  4055. Installing programs in OS/2 V2.0 is no more difficult than under OS/2 Version 
  4056. 1.3. The difference only becomes apparent after the program has been installed 
  4057. and the user or administrator is trying execute it. Programs can continue to be 
  4058. run, as in OS/2 Version 1.3, by double-clicking on their program icon. Taking 
  4059. full advantage of the WPS, however, means setting up folders with data files 
  4060. and linking these files to the programs so that they are automatically started 
  4061. when the data file is double clicked on. 
  4062.  
  4063. There are three main ways of making these links: 
  4064.  
  4065.  Associate the program with a file type and set the "Type" in the data files 
  4066.  
  4067.  Associate the program with some or all of a filename and extension to be used 
  4068.   by all the data files 
  4069.  
  4070.  Add the program name to the data files and make it the default program to be 
  4071.   used when the user double clicks on the file. 
  4072.  
  4073. All three approaches have advantages and disadvantages, which are briefly 
  4074. outlined in Using the Workplace Shell. 
  4075.  
  4076. File Type Association 
  4077.  
  4078. Associating programs with files can be done in the programs Settings view, by 
  4079. filenames, or through setting the file type in the data file settings. OS/2 
  4080. provides a default table of available file types to which programs written for 
  4081. the Workplace Shell can add their entries. 
  4082.  
  4083. So far very few programs take advantage of this feature, even though they could 
  4084. very effectively be started by association if they did (that is, they are 
  4085. written to expect a filename as their first command line parameter). 
  4086.  
  4087. Where such a program is written by the user, it is a very simple matter to add 
  4088. the required ASSOCTABLE to add the new type. See Migrating Existing 
  4089. Applications (Using an ASSOCTABLE to Add New File Types) for details of how to 
  4090. do this. In the case of any other program, however, you may want to add a file 
  4091. type to the system, without having access to the source code of the program 
  4092. concerned. A REXX program to do this can be found in Adding New File Types. 
  4093.  
  4094. Some users have noted the format in which the table of available types is 
  4095. stored in OS2.INI and have written REXX programs to add new types directly. 
  4096. This approach is not recommended; it is unsupported and is dependent on the way 
  4097. OS/2 stores this data, which may change in some future release. 
  4098.  
  4099. Filename Association 
  4100.  
  4101. The answer for programs over which you do not have control is to use 
  4102. association by file extension rather than file type. This is simple and easily 
  4103. understood by administrators but has some serious flaws and is not recommended 
  4104. as the default solution. 
  4105.  
  4106. Consider the PMSPREAD spreadsheet program that is provided as one of the 
  4107. productivity "applets" with OS/2 Version 2.0. If you invoke this program with 
  4108. the name of one its saved spreadsheets as the first parameter, it will 
  4109. automatically load the data as the program starts. 
  4110.  
  4111. If you open a Settings view of the program object in the Productivity folder, 
  4112. you will see that no type associations are defined for it. So, if we want to 
  4113. start this program by opening one of its data files, then we will have either 
  4114. to add a new file type to the system and associate the program with that, or 
  4115. else associate the program with a filename and/or extension. This particular 
  4116. program uses the distinctive extension .$$S for its files, so association by 
  4117. file extension is probably the best approach in this case. 
  4118.  
  4119. The major restriction with using filename association is, as noted above, that 
  4120. HPFS filenames can be changed by editing the icon descriptions. Unless users 
  4121. remember to add the correct file extension when they edit a filename (and this 
  4122. is not a natural way of working with the WPS) then the program associations 
  4123. will be lost. Some measure of protection is afforded by the "Confirm on rename 
  4124. of files with extensions" option in the System Settings folder (it is "on" by 
  4125. default) but this may not always prevent the user from renaming the file. 
  4126.  
  4127. Adding a Program to a Data File Menu 
  4128.  
  4129. An alternative approach to linking data files to programs is to add the program 
  4130. name to the data files context menu and make it the default "Open" setting. 
  4131. This is a useful workaround to the problem of losing a linkage when the 
  4132. filename is changed by the user, which is the main drawback to the filename 
  4133. association, but other factors may make even this approach unworkable in 
  4134. practice. 
  4135.  
  4136. Since most of those programs which don't support file types also don't have any 
  4137. mechanism to accept a filename as a parameter, starting the program from the 
  4138. file is going to provide no extra benefit to the user. If anything, adopting 
  4139. this approach could be counter-productive, since the user would be using the 
  4140. same technique for starting both OS/2 and DOS programs but would get completely 
  4141. different results. 
  4142.  
  4143.  
  4144. ΓòÉΓòÉΓòÉ 16.3. Problem Determination and Resolution ΓòÉΓòÉΓòÉ
  4145.  
  4146. Perhaps the most common source of problems associated with OS/2 V2.0 is the 
  4147. failure to run the "shutdown" program before powering off the machine. 
  4148. "Shutdown" closes the system down methodically, giving all running programs an 
  4149. opportunity to save their data. It also writes the contents of the disk cache 
  4150. to disk if the lazy write option was set in HPFS. 
  4151.  
  4152. Therefore, not shutting the system down methodically can result in system and 
  4153. application data being corrupted on the disk. This is especially troubling if 
  4154. the OS2.INI file becomes corrupted, since this file contains pointers to all 
  4155. the objects used by the WPS. 
  4156.  
  4157.  
  4158. ΓòÉΓòÉΓòÉ 16.3.1. Error Symptoms of a Malfunctioning Desktop ΓòÉΓòÉΓòÉ
  4159.  
  4160. The following symptoms may help in diagnosing when something has gone wrong 
  4161. with the system configuration files: 
  4162.  
  4163.  Extra printers/queues have been defined in the INI file, but there is no 
  4164.   printer object on the desktop; printing doesn't work properly 
  4165.  
  4166.  Multiple instances of the same object(s) 
  4167.  
  4168.  Impossible to use mouse button 2 to get the desktop's context menu 
  4169.  
  4170.  OS/2 won't fully boot; the initial OS/2 sign-on is displayed but, when the 
  4171.   Presentation Manager is supposed to start, the system hangs 
  4172.  
  4173.  LAN login hangs the system. 
  4174.  
  4175.  
  4176. ΓòÉΓòÉΓòÉ 16.3.2. Shadow Copies of Programs ΓòÉΓòÉΓòÉ
  4177.  
  4178. Program files should not be "shadowed" to a folder on the desktop. Instead, a 
  4179. new reference for that program should be created within that folder. This 
  4180. prevents the user from writing over the name of the executable file if he 
  4181. directly edits (Alt-MB1) the icon description. Consistently applying this 
  4182. technique will also reduce the number of cross references within the OS2.INI 
  4183. file and enhance the reliability of the WPS. 
  4184.  
  4185.  
  4186. ΓòÉΓòÉΓòÉ 16.4. Backup and Restore with the Workplace Shell ΓòÉΓòÉΓòÉ
  4187.  
  4188. The Workplace Shell stores a great deal of critical data in the OS/2 
  4189. initialization file OS2.INI and in Extended Attributes associated with data 
  4190. files and directories. The OS2.INI file contains system details such as the 
  4191. pointers for all the abstract objects -  shadows, program references, etc. A 
  4192. fuller discussion of what the Workplace Shell stores in OS2.INI may be found in 
  4193. Workplace Shell Implementation. 
  4194.  
  4195. If this information is lost or corrupted for any reason, the effect on the 
  4196. system can be very serious. Backing up only the contents of data files is, 
  4197. therefore, no longer sufficient while backing up OS2.INI has gained critical 
  4198. importance. 
  4199.  
  4200. This section discusses approaches to back up and restore that will allow a user 
  4201. to recover from system failures in such a way that his desktop environment is 
  4202. not disrupted too badly. It also discusses some of the more popular back up 
  4203. utilities in terms of their suitability for backing up a system using the 
  4204. Workplace Shell. 
  4205.  
  4206.  
  4207. ΓòÉΓòÉΓòÉ 16.4.1. Critical System Files ΓòÉΓòÉΓòÉ
  4208.  
  4209. OS/2 V2.0 has a built-in mechanism for copying and restoring the three critical 
  4210. system files: CONFIG.SYS, OS2.INI and OS2SYS.INI. 
  4211.  
  4212. During boot, if you press Alt-F1 before the CONFIG.SYS file is read (the best 
  4213. time is when disk access begins), the system will use neither the CONFIG.SYS 
  4214. file found in the root nor the OS2.INI and OS2SYS.INI files found in the \OS2 
  4215. directory. These versions of the CONFIG.SYS and .INI files are renamed with a 
  4216. numeric extension such as CONFIG.003 or OS2.015. 
  4217.  
  4218. The system then replaces these files with versions of the CONFIG.SYS and the 
  4219. .INI files that are stored in the \OS2\INSTALL subdirectory. A message informs 
  4220. the user of what occurred and the system continues its IPL. 
  4221.  
  4222. This mechanism works well for replacing existing copies of these files while 
  4223. preserving the old version in case the new one generates system errors. We have 
  4224. also discussed other approaches, below, which may offer additional flexibility. 
  4225.  
  4226.  
  4227. ΓòÉΓòÉΓòÉ 16.4.2. How to Back Up OS2.INI ΓòÉΓòÉΓòÉ
  4228.  
  4229. The OS2.INI file is kept open by the WPS at all times, so normal backup 
  4230. techniques cannot be used - the back up programs concerned will be denied 
  4231. access to the file as it is already open. One solution that we have found 
  4232. useful is to copy this file during the operating system boot before the 
  4233. Workplace Shell has started. 
  4234.  
  4235. It is not sufficient to make only one copy; if you do that, and corrupt 
  4236. OS2.INI, the next time you boot the system your corrupted file will overwrite 
  4237. the backed up copy. It may even be that you do not know you have a problem 
  4238. until after the re-boot, by which time you will already have lost your backed 
  4239. up copy. 
  4240.  
  4241. The solution to this is to make a series of generation backups of OS2.INI, by 
  4242. using XCOPY from within CONFIG.SYS and some COPYs from within STARTUP.CMD. 
  4243. Since these backup files are not used by the system they may be backed up to 
  4244. tape or another disk just like any other data files. Although the critical WPS 
  4245. data is held in OS2.INI, it is worth backing up OS2SYS.INI in the same way. 
  4246.  
  4247. This is illustrated in Figure "Starting XCOPY From the First Line in CONFIG.SYS 
  4248. to Back Up the INI Files" and Figure "Building Back Up History of the INI Files 
  4249. from STARTUP.CMD". 
  4250.  
  4251. This scheme keeps five versions of the INI files on disk, .OLD being the 
  4252. oldest. If something happens to an INI file you still have a chance of 
  4253. reverting to a previous version. The space occupied by the backups depends on 
  4254. the size of your INI files and the number of cascaded copies you make; from 500 
  4255. KB to several MB of disk space can be used up. You must make your own judgement 
  4256. as to the number of generations to keep, based on the size of the files 
  4257. concerned and the available disk space. 
  4258.  
  4259.  
  4260. ΓòÉΓòÉΓòÉ 16.4.3. Restoring a Backup Version of OS2.INI ΓòÉΓòÉΓòÉ
  4261.  
  4262. If you should be so unfortunate as to lose or corrupt the OS2.INI file, you 
  4263. will want to restore it from the most recent, clean, backup copy you have. This 
  4264. will normally be the one that was copied when you last booted the system. 
  4265.  
  4266. Since OS2.INI is kept open at all times by the Workplace Shell, you cannot 
  4267. simply copy the backup over the current file. The two approaches to resolving 
  4268. this are outlined below. 
  4269.  
  4270. Reboot from Diskette 
  4271.  
  4272. This procedure will only recover your system to the point at which it was 
  4273. previously saved. Any objects and folders that you added since that point will 
  4274. be lost, as will any colors and desktop settings which you altered. 
  4275.  
  4276. Booting from diskette to restore the OS2.INI file requires the following steps: 
  4277.  
  4278.  1. Obtain the OS/2 V2.0 "Installation" diskette and diskette 1 
  4279.  
  4280.  2. Insert the OS/2 V2.0 "Installation" diskette and reboot 
  4281.  
  4282.  3. When prompted, insert diskette 1 and press enter.  Wait for the first 
  4283.     Install panel and press Escape for an OS/2 command prompt 
  4284.  
  4285.  4. Copy your saved INI files into the bootup drive and directory: 
  4286.  
  4287.         COPY  A:\*.INI  C:\OS2
  4288.  
  4289.  5. Remove the diskette and reboot. 
  4290.  
  4291. System Install from Alt-F1 
  4292.  
  4293. The Alt-F1 keystroke combination, described in Critical System Files will copy 
  4294. the CONFIG.SYS, OS2.INI and OS2SYS.INI files from the OS2\INSTALL directory 
  4295. into the appropriate directories before reading those files. A fuller 
  4296. discussion of this technique may be found in OS/2 Version 2.0 - Volume 1: 
  4297. Control Program. 
  4298.  
  4299. What is the Effect of Restoring a Back-level OS2.INI? 
  4300.  
  4301. If you have to restore an old OS2.INI to an otherwise intact system, there may 
  4302. be conflicts between the contents of OS2.INI and the files, directories and EAs 
  4303. on the disks. The relationships between these are discussed more fully in 
  4304. Workplace Shell Implementation. 
  4305.  
  4306. The degree of problems caused will depend on how many program files have been 
  4307. copied and how many shadow copies have been made since the date that the 
  4308. OS2.INI file was copied. This is because these objects are stored in the 
  4309. OS2.INI file and so will be lost when it is replaced. 
  4310.  
  4311. The usual problem that ensues is that a folder will have a pointer to that 
  4312. program or copy in its directory EA, but now the pointer no longer exists. The 
  4313. solution is easy; perform a refresh on the folder, then copy the program or 
  4314. file shadow again. 
  4315.  
  4316.  
  4317. ΓòÉΓòÉΓòÉ 16.4.4. Backup Programs ΓòÉΓòÉΓòÉ
  4318.  
  4319. The backup programs PMTAPE and SY-TOS Plus** for OS/2 are capable of backing up 
  4320. the main system files (CONFIG.SYS, OS2.INI and OS2SYS.INI) as well as the 
  4321. directories, files and their associated EAs. 
  4322.  
  4323.  
  4324. ΓòÉΓòÉΓòÉ 16.5. Using the Workplace Shell in a LAN Environment ΓòÉΓòÉΓòÉ
  4325.  
  4326. The LAN independent shell in OS/2 V2.0 is an integral part of the WPS. If you 
  4327. have one or more requesters started in your CONFIG.SYS file, an icon labelled 
  4328. Network appears on the desktop. Opening the Network folder shows an icon for 
  4329. each network type. A user can move or shadow the Network folder to any other 
  4330. folder. 
  4331.  
  4332.  
  4333. ΓòÉΓòÉΓòÉ 16.5.1. Organization of a LAN Workplace ΓòÉΓòÉΓòÉ
  4334.  
  4335. The distribution of task-oriented resources between server and workstation is 
  4336. largely a matter of security, licensing, performance and the hardware 
  4337. capabilities. The planning and set up of a user environment should also 
  4338. consider issues such as LAN availability. 
  4339.  
  4340. In a stable environment with file mirroring almost all data and programs could 
  4341. be stored on, and accessed from, a LAN server. The integration of the Workplace 
  4342. Shell and LAN permits the following combinations: 
  4343.  
  4344.  Common programs and data can be stored on the LAN server 
  4345.  
  4346.  Programs and data limited to certain users can be placed in dedicated folders 
  4347.   on the LAN server 
  4348.  
  4349.  Highly important programs, which must be available to a user even if the LAN 
  4350.   is not running, may reside on the workstation 
  4351.  
  4352.  Shadow copies of LAN data files can be set up in local folders within the 
  4353.   desktop structure. 
  4354.  
  4355. As a network is hierarchically organized it may seem to make sense to focus on 
  4356. the LAN servers for the placement of folders and data objects. However, using 
  4357. the Network and LAN Server folders as the standard way of providing access to 
  4358. programs and data would be inconsistent with the way the user accesses local 
  4359. resources. 
  4360.  
  4361. This would mean that he would have to work his way through the hierarchy each 
  4362. time he needed access to LAN-resident resources. For this reason, a better 
  4363. approach would be to use shadow copies of the resources he wants to use from 
  4364. the network directories. 
  4365.  
  4366. Several different approaches to arranging local and remote folders are 
  4367. possible.  The possible combinations of folders and files are: 
  4368.  
  4369.  Shadow folder with shadow files 
  4370.  Shadow folder with local files 
  4371.  Shadow folder with local and shadow files 
  4372.  Local folder with local files 
  4373.  Local folder with shadow files 
  4374.  Local folder with local and shadow files. 
  4375.  
  4376. In all cases, we assume that programs are stored remotely on the LAN server and 
  4377. that only files are displayed in folders, not programs. 
  4378.  
  4379. Shadow Folders 
  4380.  
  4381. The shadow folder is a pointer to the real folder (and associated directory) on 
  4382. the LAN Server. Any objects in the LAN folder will also be shadow copied into 
  4383. the shadow LAN folder. This approach allows the directory to be maintained by 
  4384. an administrator so the user can concentrate on the tasks he is paid to 
  4385. perform. It ensures that sensitive data can be secured and backed up at a 
  4386. central point. 
  4387.  
  4388. The shadow LAN folder has some unique behaviors. It will not open if all the 
  4389. real objects reside on the LAN and the user has not logged on to the server. 
  4390. This is because the logical drive on the LAN cannot be accessed by the folder; 
  4391. this can be seen in the File page of the folder Settings view. 
  4392.  
  4393. However, this situation is modified where local objects have been placed in the 
  4394. shadow LAN folder. In this case the folder can be opened but if the user then 
  4395. tries to access a shadow object before "login", the Workplace Shell issues a 
  4396. warning. 
  4397.  
  4398. The following sequence is used to set up a shadow LAN folder: 
  4399.  
  4400.  1. Create a shadow copy for the user's "home" folder from the LAN 
  4401.  
  4402.  2. Put any local, real objects in the shadow LAN folder 
  4403.  
  4404.  3. Create shadow copies of the local data file objects in the shadow LAN 
  4405.     folder 
  4406.  
  4407.  4. Create new program references for local programs in the shadow LAN folder 
  4408.  
  4409.  5. Create new program references for remote programs in the shadow LAN folder. 
  4410.  
  4411. Program files should not be "shadowed" to the local folder. Instead, a new 
  4412. program reference for the program should be created within that folder.  See 
  4413. Shadow Copies of Programs for more information. 
  4414.  
  4415. There are some differences in the usage of a shadow LAN folder and a local 
  4416. folder which may seem confusing to the inexperienced user. For example, if the 
  4417. user has a shadow copy of a LAN folder and then tries to make a shadow copy of 
  4418. a file from the LAN folder into that shadow folder, the WPS will, correctly, 
  4419. not allow it. 
  4420.  
  4421. Another example would be where the user wants to "logout" but one of the 
  4422. objects in the shadow folder or the LAN Server folder is still in use. In this 
  4423. event, the Workplace Shell will report an active connection and refuse to 
  4424. close. 
  4425.  
  4426. There are also disadvantages to using shadow copies of either a local or a LAN 
  4427. folder. For instance, the act of renaming a shadow folder by "direct editing" 
  4428. the icon description will result in the physical name being changed. This can 
  4429. cause problems on a shared directory where many users have Read/Write (RW) 
  4430. access. Under such circumstances it would be better to set up local folders 
  4431. with shadow copies of files, as described below. 
  4432.  
  4433. Local Folder 
  4434.  
  4435. Instead of a shadow copy of the LAN folder, a better approach is to use a local 
  4436. folder (or work area). All types of objects, both real (local) and shadow 
  4437. (local and remote), can be stored in a local folder. The advantage of this 
  4438. approach is added security against loss of data and more consistency in 
  4439. organizing the WPS by task. 
  4440.  
  4441. The set up is completely transparent to the user and the behavior of shadow 
  4442. copies of LAN data files does not differ from Shadow Folders above. 
  4443.  
  4444. The local folder resides in the local desktop structure. It therefore has a 
  4445. real name and the disk space needed depends on the number and type of objects 
  4446. stored in it. 
  4447.  
  4448. To set up a local folder with LAN objects requires the following steps: 
  4449.  
  4450.  1. Create a local folder 
  4451.  
  4452.  2. Create shadow copies of the LAN data file objects in the local folder 
  4453.  
  4454.  3. Create shadow copies of local data file objects in the local folder 
  4455.  
  4456.  4. Create new program references for local programs in the local folder 
  4457.  
  4458.  5. Create new program references for remote programs in the local folder. 
  4459.  
  4460. Program files should not be "shadowed" to the local folder. Instead, a new 
  4461. program reference for the program should be created within that folder.  See 
  4462. Shadow Copies of Programs for more information. 
  4463.  
  4464.  
  4465. ΓòÉΓòÉΓòÉ 16.6. Workplace Shell Performance ΓòÉΓòÉΓòÉ
  4466.  
  4467. Since users can open as many programs as they like, this is a potential cause 
  4468. of performance problems. In addition, since the WPS will restart any programs 
  4469. which were left running at "shutdown", we can conceive of a situation where 
  4470. performance would slowly degenerate over some time, with the operating system 
  4471. starting more and more programs each day, even if the user didn't need them 
  4472. all. 
  4473.  
  4474. There are two techniques which can help prevent these problems. The first one 
  4475. is to use work areas instead of folders, then encourage users to close a folder 
  4476. when they have finished with it instead of minimizing it. When a work area is 
  4477. closed, all the programs in it are also closed, so this helps free resources 
  4478. for the next program(s) the user has to run. 
  4479.  
  4480. The second technique is described in Prevent Programs Restarting at IPL, where 
  4481. any previously running programs are prevented from restarting when the system 
  4482. is restarted. A REXX program is described which performs this. 
  4483.  
  4484. In addition, some WPS functions are inherently slower than others. For example, 
  4485. opening a folder with a tree view is slower than opening it with an icon view. 
  4486. Users quickly learn to use the WPS functions in the most appropriate way. 
  4487.  
  4488.  
  4489. ΓòÉΓòÉΓòÉ 16.7. Training Users to Use the Workplace Shell ΓòÉΓòÉΓòÉ
  4490.  
  4491. A good understanding of the basic concepts behind the workplace environment 
  4492. will lead to greater user satisfaction and should help reduce their need for 
  4493. support. 
  4494.  
  4495. It is important that users understand not just the techniques used to interact 
  4496. with the Workplace Shell, but also the objects that the WPS uses. They may 
  4497. think that, since they make a copy of a file using Ctrl-drag but a shadow copy 
  4498. using Ctrl-Shift-drag, then Ctrl-dragging a file will always make a real copy, 
  4499. no matter what kind of object the source is. Of course, that's not how the WPS 
  4500. works; if you copy a shadow, you get another shadow. 
  4501.  
  4502. Shadows can cause other problems for the inexperienced user. For example, if 
  4503. you have a user who wants to copy a file to a diskette, they will not 
  4504. differentiate between the real file and a shadow, and will therefore fail to 
  4505. understand why the WPS won't let them drag that shadow onto the diskette icon. 
  4506. In general, it might be better to remove the diskette icon from the desktop and 
  4507. let users work with the Drives folder for all their file system interactions. 
  4508.  
  4509.  
  4510. ΓòÉΓòÉΓòÉ 16.7.1. Training and Desktop Configuration ΓòÉΓòÉΓòÉ
  4511.  
  4512. An important point to note here is that training for the WPS depends on what 
  4513. objects are put onto their desktop; the greater the variety of objects, the 
  4514. more the user has to know. Approaches to configuring the desktop are discussed 
  4515. in Utilities for the Workplace Shell. 
  4516.  
  4517. Restricting the range of objects to devices, such as printers and shredders, 
  4518. folders and data files is probably the best approach; it is very consistent and 
  4519. requires the user to learn the least number of techniques. This is described in 
  4520. User Requirements. 
  4521.  
  4522. Users with previous experience of using DOS or OS/2 will wish to continue to 
  4523. use programs since that is how they already know how to work with a computer. 
  4524. While the WPS is more logical, consistent and simpler than its "program menu" 
  4525. predecessors, it is often difficult for some users to adjust to its new style 
  4526. of interaction. Under these circumstances, modifying the shell to look more 
  4527. like the PM shell in OS/2 Version 1.3 might be a better approach. Giving OS/2 
  4528. V2.0 the Look and Feel of OS/2 Version 1.3 provides more information on this 
  4529. topic. 
  4530.  
  4531.  
  4532. ΓòÉΓòÉΓòÉ 16.8. Utilities for the Workplace Shell ΓòÉΓòÉΓòÉ
  4533.  
  4534. This section discusses various techniques that may be applied to the WPS to 
  4535. tailor it to the needs of specific users or groups of users. In general, REXX 
  4536. programs are used here to illustrate the points, although for security and 
  4537. performance these might be rewritten as C programs before widespread 
  4538. distribution. 
  4539.  
  4540. These procedures assume that SysLoadFuncs has already been loaded, as shown 
  4541. below: 
  4542.  
  4543.    /* Rexx program that uses RexxUtil functions */
  4544.    call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  4545.    call SysLoadFuncs
  4546.  
  4547. Refer to Using REXX in OS/2 V2.0 for more details. 
  4548.  
  4549.  
  4550. ΓòÉΓòÉΓòÉ 16.8.1. Prevent Programs Restarting at IPL ΓòÉΓòÉΓòÉ
  4551.  
  4552. On shutdown, a number of programs may be active which will be reactivated at 
  4553. the next system IPL. A standard technique is available to override this. It is 
  4554. described in the "README" file in the root directory. Press and hold the left 
  4555. Ctrl, left Shift and F1 keys while the operating system is IPLing. This 
  4556. disables the automatic program startup feature of the desktop. 
  4557.  
  4558. This may not be appropriate for certain classes of user, for example where 
  4559. several people share the system. These people would rather find the system in a 
  4560. standard state each morning, regardless of what the previous user had been 
  4561. running the day before. It is unlikely that an adminstrator in a corporate 
  4562. environment would want his users to have to learn the Ctrl-Shift-F1 sequence. 
  4563.  
  4564. A simple way to automatically prevent programs being restarted after an IPL is 
  4565. to use a small REXX program to clear the Startup folder before the Workplace 
  4566. Shell is activated. If this program is invoked from the STARTUP.CMD file, it 
  4567. will run before the Workplace Shell is initialized to prevent previously 
  4568. running programs from being started. 
  4569.  
  4570. This is illustrated in Figure "A REXX Procedure To Prevent Programs 
  4571. Restarting." 
  4572.  
  4573.  
  4574. ΓòÉΓòÉΓòÉ 16.8.2. File Transfer to a Host Session ΓòÉΓòÉΓòÉ
  4575.  
  4576. The following procedure is useful for uploading files from the PS/2 to a host 
  4577. system. Both methods hide file transfer programs from the user and thus helps 
  4578. him maintain a consistent way of working with the WPS. 
  4579.  
  4580. Two alternative approaches are used; the first creates an icon onto which the 
  4581. user can drop the file to be transferred, the second simply adds a file 
  4582. transfer command to the pop-up menu. 
  4583.  
  4584. File Transfer Icon 
  4585.  
  4586.  1. Create a folder to hold the files that are to be uploaded 
  4587.  
  4588.  2. Copy the CMD file in Figure "REXX Procedure for Host Upload" into that 
  4589.     folder 
  4590.  
  4591.  3. Create a program reference by pulling a program template into your folder 
  4592.  
  4593.  4. Open a Settingsview for the program reference 
  4594.  
  4595.  5. Put your CMD file path and filename in the Physical Name field 
  4596.  
  4597.  6. Put  %*  in the Parameters field 
  4598.  
  4599.  7. Close the Settings view. 
  4600.  
  4601. The following REXX procedure is called when an object is dropped on the program 
  4602. reference icon that was created above. The name of the object is passed to the 
  4603. procedure which then eliminates the path information from the object. A target 
  4604. file type is set up and an appropriate send option (ASCII or binary) is 
  4605. determined.  Then the Communications Manager SEND command is used to transfer 
  4606. the file. 
  4607.  
  4608. This REXX procedure does not take care of all possible problems.  For instance, 
  4609. if the folder is on the desktop, a filename is created with the desktop folder 
  4610. name.  As that name contains blanks, it needs to be enclosed in quotes, which 
  4611. is not done here.  Therefore the upload folder needs to be in some other 
  4612. folder.  However, the procedure shows how a simple REXX procedure can help 
  4613. create an object-oriented environment for a user. 
  4614.  
  4615. File Transfer from a Pop-up Menu 
  4616.  
  4617. For an alternative to the file upload icon, you can: 
  4618.  
  4619.  1. Create a folder to hold program references 
  4620.  
  4621.  2. Peel a program icon off the program template in Templates and drag it to 
  4622.     this new folder 
  4623.  
  4624.  3. Enter the path and filename of your file upload utility 
  4625.  
  4626.  4. Enter the following for parameters: %* h[Enter host session letter 
  4627.     (a,b,c,d)>]: 
  4628.  
  4629.  5. Set the working directory to the path where your file upload utility 
  4630.     resides 
  4631.  
  4632.  6. Click on the General tab and change the name to "Upload to Host" 
  4633.  
  4634.  7. Click on Associations and type an asterisk in the Names field, then click 
  4635.     on the "Add" push button 
  4636.  
  4637.  8. Close the Settings window. 
  4638.  
  4639. Now, when you click on any file in your system with the right mouse button, you 
  4640. can click on the arrow to the right of "Open" and you will be offered "Upload 
  4641. to Host" as one of the programs that may be executed against it. 
  4642.  
  4643.  
  4644. ΓòÉΓòÉΓòÉ 16.8.3. Limiting a User's Access to Settings ΓòÉΓòÉΓòÉ
  4645.  
  4646. This requires a Workplace Shell program to be written. OS/2 Version 2.0 - 
  4647. Volume 4:  Application Development provides some information on subclassing WPS 
  4648. objects which will be needed to accomplish this. The general approach is to 
  4649. subclass the object class and create a new one which doesn't allow access to 
  4650. settings, then remove the "Settings" choice from the context menu. 
  4651.  
  4652.  
  4653. ΓòÉΓòÉΓòÉ 16.8.4. Creating and Populating Folders ΓòÉΓòÉΓòÉ
  4654.  
  4655. One of the things an administrator will commonly wish to do is to to create and 
  4656. populate new folders for a user. The process is straightforward and can be 
  4657. automated using REXX programs.  Several examples are provided below. The REXX 
  4658. commands used are explained in Using REXX in OS/2 V2.0. 
  4659.  
  4660. The process involves: 
  4661.  
  4662.  1. Creating a folder, which in turn will create a directory within the desktop 
  4663.     structure 
  4664.  
  4665.  2. Copying data files into it (optional) 
  4666.  
  4667.  3. Creating new program objects within it. 
  4668.  
  4669. For example, if you wanted to create a new folder on the desktop and call it 
  4670. MyFolder, use the procedure in Figure "REXX Procedure to Create a New Folder." 
  4671.  
  4672. To add an editor to the folder, MyFolder, that was just created, use the 
  4673. procedure in Figure "REXX Procedure to Add a Program to a Folder." 
  4674.  
  4675. The above examples show how to add instances of existing classes (Folder and 
  4676. Program), but you may also want to add new classes which you have created. You 
  4677. must first register a class with WPS before you can create an instance of it. 
  4678.  
  4679. The example below shows how to register a Password folder. The design and 
  4680. coding of this folder is described in OS/2 Version 2.0 - Volume 4:  Application 
  4681. Development. To register this new folder class, use the procedure in Figure 
  4682. "REXX Procedure to Register a New WPS Class." 
  4683.  
  4684. To "deregister" the class when you want to remove it from the WPS classes, use 
  4685. the procedure in Figure "REXX Procedure to Deregister a WPS Class." 
  4686.  
  4687.  
  4688. ΓòÉΓòÉΓòÉ 16.8.5. Adding New File Types ΓòÉΓòÉΓòÉ
  4689.  
  4690. The following REXX batch file presents a fully supported method of adding 
  4691. types. It creates a new program reference plus the types associated with that 
  4692. program reference. If the specified types don't exist then they are added to 
  4693. OS2.INI. Afterwards, delete the program reference and the types will remain. 
  4694.  
  4695. /* */
  4696. call RxFuncAdd "SysLoadFuncs", "RexxUtil", "SysLoadFuncs"
  4697. call SysLoadFuncs
  4698. call SysCreateObject "WPProgram", "Title", "<WP_DESKTOP>",
  4699.                      "EXENAME=EPM.EXE;ASSOCTYPE=Type 1, Type 2, Type 3,,"
  4700.  
  4701. Note that the call to SysCreateObject should only exist on one line in the 
  4702. batch file, not on 2 lines as shown above. The two commas after the "Type 3" 
  4703. are intentional. 
  4704.  
  4705.  
  4706. ΓòÉΓòÉΓòÉ 16.8.6. Removing WPS Objects ΓòÉΓòÉΓòÉ
  4707.  
  4708. In many cases, administrators will not want users to have access to all the 
  4709. objects provided with the Workplace Shell. One permanent way to remove objects 
  4710. is to create a custom OS2.INI file. 
  4711.  
  4712. For example, to remove the shredder from the desktop, edit the "INI.RC" file in 
  4713. the "\OS2" directory and remove the shredder line: 
  4714.  
  4715. "PM_InstallObject" "Shredder;WPShredder;<WP_DESKTOP>" "ICONPOS=908;OBJECTID=<WP_SHRED>"
  4716.  
  4717. Then make a new OS2.INI file by typing: 
  4718.  
  4719. MAKINI NEW.INI INI.RC.
  4720.  
  4721. Replace OS2.INI with the contents of NEW.INI using the techniques described in 
  4722. Restoring a Backup Version of OS2.INI. 
  4723.  
  4724.  
  4725. ΓòÉΓòÉΓòÉ 16.9. Customizing OS/2 V2.0 for the Inexperienced User ΓòÉΓòÉΓòÉ
  4726.  
  4727. The WPS presents a range of objects that must cater to the requirements of a 
  4728. wide variety of users. For many of these users this choice can be confusing and 
  4729. can, in some cases, reduce the usability of the WPS. 
  4730.  
  4731. There is, therefore, a real need to provide a restricted range of objects which 
  4732. meet the exact needs of the user. While the user may have many objects, he will 
  4733. only want to use a small number of object types. The WPS allows him to complete 
  4734. any task by using only three types of objects: 
  4735.  
  4736.  Containers (folders and work areas) 
  4737.  Data files 
  4738.  Devices (shredder and printers). 
  4739.  
  4740. The user need not see, or understand, the concept of a "program" to be able to 
  4741. work with a file, thanks to the associations between data files and programs. 
  4742. See Running Programs and Associating an Object with a Program for more 
  4743. information on this topic. 
  4744.  
  4745. Note that placing program icons directly in folders on the desktop can cause 
  4746. problems for the Workplace Shell as well as being inconsistent with the 
  4747. object-oriented approach we are trying to adopt. If the user makes a shadow 
  4748. copy of the program icon to another folder, then direct edits (Alt-MB1) the 
  4749. icon description, he can change the program executable name. The correct 
  4750. technique is described in Shadow Copies of Programs. However, since this 
  4751. technique requires the user to know a lot more about the way the system works, 
  4752. it is probably better to simply eliminate this potential source of error by 
  4753. only using data file objects. 
  4754.  
  4755. OS/2 Version 2.0 also provides new ways to pass information between programs 
  4756. running in different environments to provide as completely integrated a work 
  4757. space as possible. This saves time and prevents the user from introducing 
  4758. errors through rekeying data. 
  4759.  
  4760. In addition, by removing extraneous objects, the user gains improved 
  4761. consistency of operation and thus enhanced usability. For example, double 
  4762. clicking on any object now opens a window which presents the contents of that 
  4763. object. This perspective is valid for data files, folders and devices, but not 
  4764. for programs. 
  4765.  
  4766. This kind of consistency makes the system easier to learn for inexperienced 
  4767. users and encourages them to explore the capabilities of the system. An example 
  4768. of how to set up such a system is given in User Requirements. 
  4769.  
  4770.  
  4771. ΓòÉΓòÉΓòÉ 16.9.1. User Requirements ΓòÉΓòÉΓòÉ
  4772.  
  4773. This section describes the process of defining the OS/2 Version 2.0 
  4774. requirements for a typical, inexperienced user, selecting the components and 
  4775. setting up the system. In this case, our user will be running on a stand-alone 
  4776. system. LAN considerations are discussed in Using the Workplace Shell in a LAN 
  4777. Environment. 
  4778.  
  4779. For instance, a user has a range of tasks to complete as part of his normal 
  4780. job. These include: 
  4781.  
  4782.  Preparing quotations 
  4783.  
  4784.  Entering orders 
  4785.  
  4786.  Creating invoices 
  4787.  
  4788.  Book-keeping 
  4789.  
  4790.  General correspondence. 
  4791.  
  4792. We will examine the task of creating customer quotations in some detail to 
  4793. illustrate how we would set up the system for any task. 
  4794.  
  4795. Creating quotations involves: 
  4796.  
  4797.  1. Calculating a price for the goods or services requested 
  4798.  
  4799.  2. Filling these into a quotations document 
  4800.  
  4801.  3. Creating a cover letter 
  4802.  
  4803.  4. Printing the documents 
  4804.  
  4805.  5. Filing the documents. 
  4806.  
  4807. Each task is represented by a work area. The reason we use a work area is that 
  4808. when it is closed it closes all the programs which have been opened from within 
  4809. it. Since memory and disk space may be restricted on our system, leaving 
  4810. programs open could cause us performance problems. Closing them when we finish 
  4811. one task and switch to another should help prevent that problem. 
  4812.  
  4813. Each task involves other subtasks.  For example, calculating the price might 
  4814. involve looking back at the outcome of previous quotations or checking to see 
  4815. whether the customer was traditionally a late payer (in which case a penalty 
  4816. charge might be levied within the price quoted). 
  4817.  
  4818. When we look at the information required we see that we need the same 
  4819. information in several of the subtasks. The customer name and address would be 
  4820. needed in both the quotation document (which includes the terms and conditions 
  4821. which apply to the quotation) and the covering letter. 
  4822.  
  4823. From the activities above, we can see that we need the following programs: 
  4824.  
  4825.  A spreadsheet to calculate prices 
  4826.  
  4827.  A word processor to produce and print the documents 
  4828.  
  4829.  A database to store names and addresses 
  4830.  
  4831.  A folder to store the completed files in. 
  4832.  
  4833. We decided to use the following programs to illustrate a possible mix of 
  4834. operating systems and show what degree of interaction is possible under OS/2 
  4835. Version 2.0. 
  4836.  
  4837.  LOTUS** 1-2-3** /G for OS/2 
  4838.  
  4839.  WordPerfect** for Windows** 
  4840.  
  4841.  dBase IV** for DOS. 
  4842.  
  4843.  
  4844. ΓòÉΓòÉΓòÉ 16.9.2. Operating System Set Up ΓòÉΓòÉΓòÉ
  4845.  
  4846. Our objective was to provide a working system on an IBM PS/2* model 55-060 with 
  4847. 8 MB of memory. For performance and cost-effectiveness, we replaced the 
  4848. standard planar memory with 4 MB Single In line Memory Modules (SIMMs). The 
  4849. system is partitioned as follows: 
  4850.  
  4851. C:  Operating system partition - 23MB available 
  4852.  
  4853. D:  Applications partition - 35MB available. 
  4854.  
  4855. The partition size for the operating system was chosen on the basis of 
  4856. requiring approximately 18 MB of disk storage for our operating system, plus 5 
  4857. MB to allow us to add new features in the future. This will let us install new 
  4858. versions of the operating system, which might require reformatting the 
  4859. partition, without impacting our applications and data. 
  4860.  
  4861. The desktop, spooler and swapper files were moved to drive D:.  This was done 
  4862. as follows: 
  4863.  
  4864. Swapper     This was changed after the base installation, before completing the 
  4865.             selective install. 
  4866.  
  4867. Desktop     This was performed after the installation.  We used the Drives 
  4868.             folder to move the entire desktop structure from the C: drive to 
  4869.             the D: drive. 
  4870.  
  4871. Spooler     This was performed after the installation. We opened a "Settings" 
  4872.             view of the Spooler folder and changed the path there. 
  4873.  
  4874. For this user, we performed a selective install of the following OS/2 Version 
  4875. 2.0 components: 
  4876.  
  4877. CD-ROM Device Support              Not installed 
  4878.  
  4879. Documentation                      We chose not to install REXX or Tutorial 
  4880.                                    Documentation 
  4881.  
  4882. Fonts                              We installed the three outline fonts plus 
  4883.                                    System Monospaced 
  4884.  
  4885. Optional System Utilities          We installed Backup, Restore, Recover Files 
  4886.                                    and Picture Viewer 
  4887.  
  4888. Tools and Games                    Not installed 
  4889.  
  4890. OS/2 DOS and Windows               Installed 
  4891.  
  4892. HPFS                               Installed 
  4893.  
  4894. REXX                               Not installed 
  4895.  
  4896. Serial Device Support              Installed 
  4897.  
  4898. Serviceability Aids                Not installed 
  4899.  
  4900. Optional Bit Maps                  Not installed. 
  4901.  
  4902.  
  4903. ΓòÉΓòÉΓòÉ 16.9.3. Setting up the Users Work Area ΓòÉΓòÉΓòÉ
  4904.  
  4905. We created the Quotations work area by dragging a new folder from the folder 
  4906. template onto the desktop. We then renamed it, opened the settings view and 
  4907. checked the work area checkbox in the file page. 
  4908.  
  4909. Figure "Workplace Shell Quotations Work Area" 
  4910.  
  4911. Within the work area we have the following templates: 
  4912.  
  4913.  Quote.doc 
  4914.  
  4915.  Letter.doc 
  4916.  
  4917.  Prices.wg2. 
  4918.  
  4919. Quote.doc and Letter.doc are WordPerfect documents, Prices.wg2 is a Lotus 
  4920. spreadsheet. They are all created in the following way: 
  4921.  
  4922.  1. Start the program, from the command prompt or by double clicking on its 
  4923.     icon 
  4924.  
  4925.  2. Lay out the document or spreadsheet the way you want it 
  4926.  
  4927.  3. Save the file 
  4928.  
  4929.  4. Copy the file to the Quotations directory using Drives 
  4930.  
  4931.  5. Open the files Settings view and check the template checkbox on the "File" 
  4932.     page 
  4933.  
  4934.  6. Close the Settings view. 
  4935.  
  4936. The data file can be linked to the program in any of the ways described in 
  4937. Setting Up Programs in the Workplace Shell. Since the DOS programs do not 
  4938. support the concept of file types, an association based on file extension was 
  4939. set up in each program. 
  4940.  
  4941. The Quotations folder was created in the same way as the work area, that is, a 
  4942. new one was created by dragging it from the folder template and dropping it 
  4943. into the Quotations work area. 
  4944.  
  4945. The user can now tear off a new "Prices" spreadsheet, rename it using some 
  4946. combination of the customer name and date, open it to fill in the necessary 
  4947. details, print it, then file it by dropping it in the Quotations folder. 
  4948.  
  4949. When the user needs to switch to another task, such as creating invoices, he 
  4950. closes the Quotations folder. This stops any running programs, freeing the 
  4951. system memory and SWAPPER.DAT file. He then starts the next task by opening its 
  4952. folder. 
  4953.  
  4954.  
  4955. ΓòÉΓòÉΓòÉ 16.10. Summary ΓòÉΓòÉΓòÉ
  4956.  
  4957. The structure of the WPS is heavily dependent on the critical system files: 
  4958. CONFIG.SYS, OS2.INI and OS2SYS.INI. This chapter described several approaches 
  4959. to backing up and recovering these files. 
  4960.  
  4961. The Workplace Shell is capable of being tailored to meet a variety of user 
  4962. environments. Restricting the functions provided to the inexperienced user 
  4963. results in a logical, consistent interface that is simple to learn and to use. 
  4964. The installation of such a user environment was described, together with some 
  4965. notes on the OS/2 V2.0 functions needed to support that user. 
  4966.  
  4967. For the advanced user, OS/2 V2.0 provides a wealth of new techniques to help 
  4968. him become more productive. Several techniques are available to let the 
  4969. advanced user modify his environment, including adding programs to object 
  4970. menus. In addition, some REXX utilities have been provided to help the advanced 
  4971. user or administrator to modify the default operating characteristics of the 
  4972. WPS. 
  4973.  
  4974. Installing and customizing stand-alone workstations is only part of the 
  4975. administrator's brief.  Many factors must be considered, including disk 
  4976. partitioning, problem determination and overall system performance. LAN 
  4977. integration is a major enhancement to OS/2 V2.0 but this, too, must be 
  4978. carefully planned to ensure that the environment created really does meet the 
  4979. needs of the users. 
  4980.  
  4981.  
  4982. ΓòÉΓòÉΓòÉ 17. Presentation Manager and Workplace Shell Application Development ΓòÉΓòÉΓòÉ
  4983.  
  4984. OS/2 Version 2.0 introduces a new choice for application developers: whether to 
  4985. develop their applications using traditional PM programming techniques or to 
  4986. use the System Object Model (SOM) interfaces and the Workplace Shell class 
  4987. hierarchy to develop fully-integrated applications. 
  4988.  
  4989. This chapter provides an overview of the two programming models, and discusses 
  4990. the extent to which it is possible to integrate a PM program into the Workplace 
  4991. Shell environment. 
  4992.  
  4993. For more detailed information on programming for Presentation Manager and for 
  4994. the Workplace Shell, see OS/2 Version 2.0 - Volume 4:  Application Development. 
  4995.  
  4996.  
  4997. ΓòÉΓòÉΓòÉ 17.1. The Presentation Manager Application Model ΓòÉΓòÉΓòÉ
  4998.  
  4999. The conceptual model upon which a Presentation Manager application is based 
  5000. differs somewhat from "conventional" application models.  The components of a 
  5001. conventional application communicate with one another via function calls and 
  5002. pass information in the form of parameters.  The components of a Presentation 
  5003. Manager application are called windows, and communicate using messages which 
  5004. are transmitted between windows by Presentation Manager on the application's 
  5005. behalf. 
  5006.  
  5007. This section will examine the conceptual application model implemented by 
  5008. Presentation Manager.  The intent of this section is to provide the reader with 
  5009. an introduction only.  A more detailed examination of the application model 
  5010. from a programmer's viewpoint is given in OS/2 Version 2.0 - Volume 4: 
  5011. Application Development. 
  5012.  
  5013.  
  5014. ΓòÉΓòÉΓòÉ 17.1.1. Windows ΓòÉΓòÉΓòÉ
  5015.  
  5016. Presentation Manager applications are based upon the concept of windows.  A 
  5017. window typically represents some object, such as a file or document, a device 
  5018. or a data record, upon which the application will operate.  The user interacts 
  5019. with the window to manipulate the object. 
  5020.  
  5021. A window appears to the user as a rectangular area on the screen, which may be 
  5022. moved and re-sized by the user with either the keyboard or mouse.  From an 
  5023. application viewpoint, however, the concept of a window is far more powerful 
  5024. than this.  Windows may be of two basic types: 
  5025.  
  5026.  Display windows have a visual manifestation represented by a rectangular area 
  5027.   on the screen; in this case, the window represents a view of a conceptual 
  5028.   display surface known as a presentation space, which is the object upon which 
  5029.   the window operates.  This view may be full or partial, depending upon the 
  5030.   current size of the window, and the size of the presentation space.  See 
  5031.   Presentation Spaces and Device Contexts for more information on presentation 
  5032.   spaces. 
  5033.  
  5034.  Object windows have no visual manifestation, and are merely addresses or 
  5035.   "handles" to which messages may be directed.  An object window is typically 
  5036.   associated with an object such as a file or database, and is used to access 
  5037.   this object and perform actions upon it. 
  5038.  
  5039. Windows respond to events which are communicated to them by way of messages. 
  5040. Messages may originate from Presentation Manager as a result of user 
  5041. interaction, or from other windows in the system.  Messages may be of many 
  5042. different types; Presentation Manager defines a number of message classes, and 
  5043. an application may define its own message classes for communication between its 
  5044. own windows.  Messages are routed between windows by Presentation Manager on 
  5045. behalf of the applications, and are discussed in greater detail in Messages. 
  5046.  
  5047. The basic structure of a Presentation Manager application is therefore that of 
  5048. a group of windows, communicating with one another by way of messages.  This is 
  5049. illustrated in Figure "Presentation Manager Application Structure". 
  5050.  
  5051. The behavior of a window in response to messages directed to it is determined 
  5052. by its window procedure, which determines the processing performed by the 
  5053. window in response to each message it receives.  Windows with similar 
  5054. characteristics are grouped into a window class, and share a window procedure. 
  5055.  
  5056. Note that windows are a finite operating system resource.  Under OS/2 Version 
  5057. 1.1 and Version 1.2, the maximum number of windows which could be created in 
  5058. the system was approximately 1200.  Under OS/2 Version 1.3 this limit was 
  5059. increased to approximately 10000; this increased limit also applies to OS/2 
  5060. Version 2.0. 
  5061.  
  5062. Other Presentation Manager objects such as presentation spaces and device 
  5063. contexts also consume storage for control information.  Under OS/2 Version 2.0, 
  5064. the total limit for all graphics resources used by Presentation Manager is 
  5065. approximately 64000. 
  5066.  
  5067. Note also that when large numbers of windows are created in the system, 
  5068. Presentation Manager uses significant processor resource to handle message 
  5069. routing, clipping etc. Some degradation in overall system performance may 
  5070. therefore be experienced when running with an extremely large number of windows 
  5071. open. 
  5072.  
  5073. Window Classes 
  5074.  
  5075. Each window belongs to a window class.  The window class determines a number of 
  5076. properties of the window, including its window procedure, which in turn 
  5077. determines the behavior of the window in response to the messages it receives. 
  5078. A window class is registered with Presentation Manager, and may be defined in 
  5079. one of two ways: 
  5080.  
  5081.  Public, in which case the window class is registered automatically at system 
  5082.   initialization, and may be used by any application in the system. 
  5083.  
  5084.   A number of window classes, such as the frame window and control windows, are 
  5085.   publicly defined by Presentation Manager, and are hence available for use by 
  5086.   applications. 
  5087.  
  5088.  Private, in which case an application must register the window class 
  5089.   explicitly during its own initialization.  Windows of this class may then be 
  5090.   used only by that application. 
  5091.  
  5092. Each window within a class is said to be an instance of that class. Multiple 
  5093. windows of the same class may exist in the system at the same time, controlled 
  5094. by the same or different applications. 
  5095.  
  5096. Window Procedures 
  5097.  
  5098. Each window in the system has a window procedure, which defines the processing 
  5099. performed by the window for each message it receives.  Such processing may 
  5100. include general application logic, I/O operations or communication with other 
  5101. windows.  The window procedure is associated with an entire window class rather 
  5102. than an individual instance of the class, and is defined when the class is 
  5103. registered to Presentation Manager. 
  5104.  
  5105. The window procedure must be provided by the application which registers the 
  5106. window class.  Presentation Manager provides its own window procedures for its 
  5107. publicly defined window classes.  Applications which register their own window 
  5108. classes must provide a window procedure for each class. 
  5109.  
  5110. The window procedure is invoked by Presentation Manager on the application's 
  5111. behalf, in response to any message directed to that window, either from 
  5112. Presentation Manager itself or from another window in the system.  The window 
  5113. procedure determines the class of the message, and takes appropriate action. 
  5114. Since there are an extremely large number of messages which may be passed to a 
  5115. window, the window procedure need only process those messages which are 
  5116. required to carry out the window's functions; Presentation Manager  provides 
  5117. default processing for all system-defined message classes, and 
  5118. application-defined message classes not processed by the window procedure are 
  5119. simply ignored. 
  5120.  
  5121. Window procedures are re-entrant, and multiple instances of the same window 
  5122. class share the same memory-resident copy of the window procedure.  Hence any 
  5123. local data defined by the window procedure is also shared by each window in the 
  5124. class.  To allow each window to keep its own separate data areas, Presentation 
  5125. Manager allows an application to define an area known as the window words, 
  5126. which is unique to each individual window, and is maintained with Presentation 
  5127. Manager's own control block for that window.  Window words are normally used to 
  5128. store a pointer to a memory object which is dynamically allocated when the 
  5129. window is created, and used to store instance-specific data. 
  5130.  
  5131.  
  5132. ΓòÉΓòÉΓòÉ 17.1.2. Messages ΓòÉΓòÉΓòÉ
  5133.  
  5134. Messages are the mechanism by which windows communicate with one another and 
  5135. are notified of system- or user-initiated events by Presentation Manager.  In a 
  5136. typical Presentation Manager application, all interaction between the user and 
  5137. windows, or between one window and another, takes place by way of messages. 
  5138. Messages may be of three types: 
  5139.  
  5140. User-initiated             The message is generated as the direct result of the 
  5141.                            user selecting a menu bar item, pressing a key on 
  5142.                            the keyboard, etc. 
  5143.  
  5144. Application-initiated      The message is generated by one window within the 
  5145.                            application for the communication of an event to 
  5146.                            another window. 
  5147.  
  5148. System-initiated           The message is generated by Presentation Manager as 
  5149.                            the indirect result of user action such as the 
  5150.                            window being re-sized or moved, or as the result of 
  5151.                            a system event such as window being created or 
  5152.                            destroyed. 
  5153.  
  5154. Since almost every event which occurs within the system results in a message 
  5155. being generated, a Presentation Manager application has great freedom in the 
  5156. way in which it processes such events. 
  5157.  
  5158. Message Queues 
  5159.  
  5160. Whenever an event occurs within the system, such as the user pressing a key or 
  5161. selecting an item from a menu, a window being created or destroyed, or one 
  5162. window communicating with another, a message is generated and placed on a 
  5163. system message queue. Such messages are placed on the queue in the order they 
  5164. originated. 
  5165.  
  5166. Each application has its own message queue, and each thread within a 
  5167. multi-threaded application may also possess its own message queue. This queue 
  5168. is explicitly created by the thread, via a function call to Presentation 
  5169. Manager, at the time the thread is initialized. (The term "thread" will be used 
  5170. herein, since message queues are always created on a per-thread basis; the 
  5171. application's initial message queue is created by its primary thread.) 
  5172.  
  5173. Note that a secondary thread in a multi-threaded application need only create a 
  5174. message queue if it will create one or more windows.  A secondary thread which 
  5175. does not create windows does not require a message queue. 
  5176.  
  5177. Figure "Message Queues" 
  5178.  
  5179. Presentation Manager periodically interrogates the system queue, removes each 
  5180. message and determines the window for which it is destined.  It then places the 
  5181. message on the message queue belonging to the thread which created the window. 
  5182.  
  5183. The thread's main routine, once initialization is complete, consists entirely 
  5184. of a message processing loop.  The thread simply retrieves a message from the 
  5185. message queue via a function call to Presentation Manager, and requests 
  5186. Presentation Manager to pass the message to the appropriate window procedure, 
  5187. which is already known to Presentation Manager through the window class 
  5188. definition. 
  5189.  
  5190. Presentation Manager then invokes the window procedure to process the message. 
  5191. When the processing is complete, the window procedure passes control back to 
  5192. Presentation Manager, which then returns control to the thread's main routine 
  5193. to obtain the next message. 
  5194.  
  5195. If the thread's own message queue is empty when it requests the next message, 
  5196. Presentation Manager checks the system queue.  Note that this is the only time 
  5197. at which the system queue is accessed; hence no other window in the system can 
  5198. receive a message until the currently executing window procedure returns 
  5199. control to Presentation Manager. 
  5200.  
  5201. If a window procedure does not return from processing a message within a 
  5202. reasonable period of time, the user is effectively "locked out" of the system. 
  5203. In order to avoid such situations, applications which perform lengthy 
  5204. operations such as document formatting or remote system access, should be 
  5205. implemented using multiple threads, thereby allowing the application's primary 
  5206. thread to continue execution and return control to Presentation Manager.  This 
  5207. technique is discussed in OS/2 Version 2.0 - Volume 4:  Application 
  5208. Development. 
  5209.  
  5210. Message Classes 
  5211.  
  5212. Messages are defined and identified using message classes.  A message class is 
  5213. simply an integer used to identify the event which caused the message. 
  5214.  
  5215. Message classes may be of two types: 
  5216.  
  5217.  System-defined message classes are defined by Presentation Manager, and are 
  5218.   used to indicate standard events such as a window being created or destroyed, 
  5219.   sized or moved, or a key being pressed. 
  5220.  
  5221.  Application-defined message classes are defined by an individual application, 
  5222.   and are used to indicate events for communication between windows in that 
  5223.   application. 
  5224.  
  5225. Message classes are usually defined as integer constants.  All system-defined 
  5226. message classes are defined in the header files which are shipped with the IBM 
  5227. Developer's Toolkit for OS/2 2.0.  Application-defined message classes are 
  5228. usually defined in the application's own header files. 
  5229.  
  5230. The structure of a message also includes two message parameters, which are 
  5231. 32-bit fields passed to the window procedure along with the message.  These 
  5232. fields may contain additional information to aid in the window procedure's 
  5233. processing, or may contain pointers to memory objects which in turn contain 
  5234. such information. 
  5235.  
  5236. Message Processing 
  5237.  
  5238. Through its window procedures, a Presentation Manager application has the 
  5239. ability to process messages of any type or class, in the following ways: 
  5240.  
  5241.  The window procedure may ignore the message, and simply leave it for 
  5242.   Presentation Manager's own default window procedure, which will provide 
  5243.   default processing for system-defined messages classes. 
  5244.  
  5245.  The window procedure may explicitly process the message, using its own logic, 
  5246.   calling subroutines and/or passing messages to other windows as necessary. 
  5247.   This allows processing of application-defined message classes, and 
  5248.   application-specific, "non-standard" processing of system-defined message 
  5249.   classes. 
  5250.  
  5251.  The window procedure may explicitly process the message and then pass the 
  5252.   message on to Presentation Manager's default window procedure.  This allows 
  5253.   application-specific processing to be performed on system-defined message 
  5254.   classes, in addition to the default processing. 
  5255.  
  5256. Messages may also be processed in either of two modes: 
  5257.  
  5258.  Synchronous processing occurs where the routine which passes the message 
  5259.   (typically a window procedure or a subroutine invoked by a window procedure) 
  5260.   waits until the message is passed to the target window and processed by its 
  5261.   window procedure.  Presentation Manager does not return control to the 
  5262.   calling routine until the window procedure has completed its processing. 
  5263.  
  5264.  Asynchronous processing occurs where the routine which passes the message 
  5265.   waits only until the message is placed in the thread's message queue. 
  5266.   Presentation Manager then returns control to the calling routine. 
  5267.  
  5268. Presentation Manager also provides facilities which allow an application to 
  5269. broadcast messages to multiple windows with a single function call. 
  5270.  
  5271.  
  5272. ΓòÉΓòÉΓòÉ 17.1.3. Presentation Spaces and Device Contexts ΓòÉΓòÉΓòÉ
  5273.  
  5274. A display window provides a view into a conceptual display surface known as a 
  5275. presentation space. In terms of the above definition of a window, the 
  5276. presentation space is actually the object upon which the window and its window 
  5277. procedure operate. The contents of the presentation space represent application 
  5278. data such as a document or graphical image. The application places text and 
  5279. graphical items such as lines, arcs, and colors, in the presentation space by 
  5280. means of PM API functions (the GPI functions). 
  5281.  
  5282. The window therefore provides the user with a view of the presentation space, 
  5283. using the screen.  This view may show the entire presentation space or only a 
  5284. portion, depending on the size of the window and that of the presentation 
  5285. space.  The size of the window is controlled by the user, although it is 
  5286. limited by the physical size and resolution of the screen. The size of the 
  5287. presentation space is controlled by the application and is limited by the 
  5288. amount of available memory which may be used to contain the presentation space. 
  5289.  
  5290. A presentation space is usually created by a window procedure when a window is 
  5291. created, and is associated with a device context at that time. 
  5292.  
  5293. A device context relates a presentation space to a physical device such as the 
  5294. screen or a printer, by converting the device-independent information stored in 
  5295. the presentation space to a device-dependent form that can be displayed on a 
  5296. particular device. If the contents of the presentation space must later be 
  5297. drawn on a device other than that for which the presentation space was 
  5298. initially created, the presentation space may simply be re-associated with a 
  5299. different device context.  This may, for example, be done when a graphical 
  5300. picture in a window on the screen needs to be printed.  The presentation space 
  5301. that was originally associated with a screen device context is re-associated 
  5302. with a printer device context. 
  5303.  
  5304.  
  5305. ΓòÉΓòÉΓòÉ 17.1.4. Presentation Manager API Enhancements in OS/2 V2.0 ΓòÉΓòÉΓòÉ
  5306.  
  5307. The 32-bit Presentation Manager API remains largely unchanged in OS/2 V2.0, 
  5308. though there are a number of new functions, mostly to help the programmer 
  5309. rather than adding significant new function.  For a complete review of the 
  5310. changes and enhancements, see IBM OS/2 Version 2.0 Application Design Guide, 
  5311. which includes a chapter comparing 16-bit and 32-bit OS/2 functions, including 
  5312. a section covering Presentation Manager.  The following section is a summary of 
  5313. that information. 
  5314.  
  5315. Functions Removed 
  5316.  
  5317. A number of 16-bit PM functions are not included in the 32-bit set.  In most 
  5318. cases these have been replaced by new 32-bit functions, or are no longer 
  5319. appropriate with the new shell.  Areas affected are: 
  5320.  
  5321.  Heap management functions 
  5322.  
  5323.  Program list (group windows) 
  5324.  
  5325.  Initialization file functions 
  5326.  
  5327.  Window locking 
  5328.  
  5329.  Window management. 
  5330.  
  5331. Printing 
  5332.  
  5333. All the printing functions, which previously had names with the prefix 
  5334. DosPrint, have been renamed to use the prefix Spl. 
  5335.  
  5336. Workplace Shell 
  5337.  
  5338. A number of new functions have been introduced giving PM programs an interface 
  5339. to the shell. These include, for example, the WinRegisterObjectClass() and 
  5340. WinCreateObject() functions, which allow a program to register and create 
  5341. Workplace Shell objects. The self-explanatory WinShutDownSystem() function 
  5342. provides a capability that was missing in previous releases. 
  5343.  
  5344. Dynamic Data Facility 
  5345.  
  5346. These new functions, which have the function name prefix Ddf, are intended to 
  5347. be used by programs that provide IPF text dynamically at run time. Such 
  5348. programs receive messages from IPF when they are to display their information, 
  5349. at which time they must build and display the text requested. 
  5350.  
  5351. The DDF functions enable the program to format the text into paragraphs, lists 
  5352. and headings in such a way that it can easily be reformatted when the window is 
  5353. resized.  Functions are provided to allow the creation of hypertext links, 
  5354. references to bitmap data, and to specify what sort of text formatting is 
  5355. required (left or right justification, for example). 
  5356.  
  5357. Standard Font and File Dialogs 
  5358.  
  5359. Many applications offer their users the option of loading and saving files from 
  5360. and to disk, and CUA defines the dialog that should be presented to the user so 
  5361. that he can select the appropriate disk, directory and file to use.  The 
  5362. standard file dialog function, WinFileDlg(), implements this dialog with very 
  5363. little programming effort. 
  5364.  
  5365. The standard font dialog, invoked by means of the WinFontDlg() function, does 
  5366. the same for those applications that allow font selection. 
  5367.  
  5368. These dialogs, which are also discussed in New Presentation Manager Features, 
  5369. significantly improve programmer productivity when file or font selection 
  5370. facilities are required.  They also ensure that the dialogs used by different 
  5371. applications present a totally consistent user interface. 
  5372.  
  5373. New Window Classes 
  5374.  
  5375. OS/2 V2.0 introduces several new control window classes, which are described in 
  5376. New Presentation Manager Features, along with some corresponding new messages. 
  5377.  
  5378. Graphics Functions 
  5379.  
  5380. A number of new GPI functions are provided, mostly related to the use of fonts 
  5381. and characters. 
  5382.  
  5383. PM Helper Macros 
  5384.  
  5385. A set of helper macros is provided that simplify interaction with some of the 
  5386. more commonly used  control window classes. The use of the macros can reduce 
  5387. the need explicitly to send messages to such windows for simple tasks such as 
  5388. inserting an entry into a list box, or querying the state of a checkbox. 
  5389.  
  5390. Being macros, these functions are expanded by the C pre-compiler into PM calls 
  5391. to send the relevant messages so, although they are coded as functions, no 
  5392. type-checking will be applied by the compiler to the arguments. 
  5393.  
  5394.  
  5395. ΓòÉΓòÉΓòÉ 17.2. The Workplace Shell Application Model ΓòÉΓòÉΓòÉ
  5396.  
  5397. The Workplace Shell provides an environment in which applications may be 
  5398. developed along fully object-oriented lines, integrating themselves seamlessly 
  5399. into the desktop environment. The techniques for developing such applications 
  5400. are discussed in this section; for more detailed information on this subject 
  5401. see OS/2 Version 2.0 - Volume 4:  Application Development. 
  5402.  
  5403.  
  5404. ΓòÉΓòÉΓòÉ 17.2.1. Workplace Shell Objects and Applications ΓòÉΓòÉΓòÉ
  5405.  
  5406. The Workplace Shell provides a number of standard object classes such as 
  5407. folders and data files. The user performs his work by interacting with these 
  5408. objects using their context menus or direct manipulation. 
  5409.  
  5410. In order to extend the range of tasks that a user can perform using the 
  5411. Workplace Shell, it is necessary to add new object classes to his desktop; 
  5412. typically these may be related to specific productivity tools, such as a 
  5413. Spreadsheet object, or to the user's own business, such as Order Form, Parts 
  5414. Catalog, or Customer. 
  5415.  
  5416. In the ideal, purely object-oriented, user interface, there would no longer be 
  5417. anything that a user would recognize as a program -  there would only be 
  5418. objects, all with their own unique behaviors and uses.  As long as the user is 
  5419. provided with suitable tools (that is, object classes), he can work out how to 
  5420. accomplish any particular task without having to learn to use an application 
  5421. program specifically designed for that task. What we might loosely call a 
  5422. Workplace Shell application is really no more than a collection of Workplace 
  5423. Shell object classes. 
  5424.  
  5425. In order for a newly developed object class to be used, it must be registered 
  5426. to the Workplace Shell. The classes are implemented in such a way that each 
  5427. class, or possibly several classes, is contained in a dynamic link library 
  5428. (DLL). Being in a DLL means that an object's methods can be called by Workplace 
  5429. Shell whenever necessary, and also that the code can be shared between multiple 
  5430. instances of the class.  Registering a new class informs the Workplace Shell of 
  5431. the existence of the new class, and gives it the name of the DLL containing its 
  5432. methods. 
  5433.  
  5434. The Workplace Shell itself, and all its classes including any that a user may 
  5435. develop, are written using the System Object Model, a language-independent 
  5436. environment for object-oriented programming. Anyone wishing to develop new 
  5437. Workplace Shell classes must therefore understand SOM, and also be familiar 
  5438. with the existing Workplace Shell classes, from which his new classes must 
  5439. inherit at least some of their behavior. 
  5440.  
  5441.  
  5442. ΓòÉΓòÉΓòÉ 17.2.2. System Object Model ΓòÉΓòÉΓòÉ
  5443.  
  5444. The System Object Model (SOM) is a language-independent specification for 
  5445. object-oriented programming (OOP). It consists of a set of utilities and 
  5446. interfaces for creating objects. This section provides a brief introduction to 
  5447. the System Object Model; for a more complete explanation, see OS/2 Version 2.0 
  5448. - Volume 4:  Application Development. That document also contains a fuller 
  5449. discussion of OOP concepts. 
  5450.  
  5451. SOM implements all the essentials of OOP, including inheritance, encapsulation 
  5452. and polymorphism. Objects are organized into classes in a hierarchical manner 
  5453. and subclasses may inherit behaviors and characteristics from their parent (or 
  5454. super) classes. 
  5455.  
  5456. SOM is language-independent. With suitable bindings any programming language 
  5457. may be used to implement the methods of an object class. For example, a class 
  5458. written in COBOL could then be used or even subclassed by another class written 
  5459. in Smalltalk/V**. However, so far the only language for which such bindings are 
  5460. available is C. 
  5461.  
  5462. One of the great benefits of  building WPS objects using SOM is that SOM 
  5463. implements the concept of inheritance.  All objects are grouped into classes, 
  5464. and characteristics and behavior common to more than one class can be defined 
  5465. as methods in a superclass which are then inherited by all child (or sub) 
  5466. classes. Many common methods such as these are defined at the system level, in 
  5467. object classes supplied with OS/2 V2.0, and may be inherited by 
  5468. application-specific object classes. 
  5469.  
  5470. An application developer may choose to enhance a system-supplied method: for 
  5471. example, providing a more advanced level of drag/drop functionality to a 
  5472. Workplace Shell object class. The developer may create a new object class as a 
  5473. subclass of the system-supplied object class.  The subclass need override only 
  5474. those methods that are invoked in drag/drop operations.  Other methods may 
  5475. simply be inherited from the super class. 
  5476.  
  5477. It is important to understand that SOM is a general-purpose implementation of 
  5478. object-oriented programming, and may be used for any OOP programming under 
  5479. OS/2.  On the other hand, the class hierarchy it provides is very limited, 
  5480. consisting as it does of only three classes, so a great deal of work would be 
  5481. required to implement classes if SOM were to be used for general-purpose 
  5482. object-oriented programming.  In practice the only use to which most 
  5483. programmers will put the SOM is in developing the Workplace Shell objects that 
  5484. will form part of their applications. 
  5485.  
  5486. OIDL and the SOM Compiler 
  5487.  
  5488. Non-OOP languages such as C lack the language constructs for defining the 
  5489. classes, methods, instance data and so on that are needed when developing OOP 
  5490. objects. Even OOP languages which are designed for this can only do so for 
  5491. applications that are implemented entirely in one language. For these reasons, 
  5492. SOM provides its own language for defining classes, called Object Interface 
  5493. Definition Language (OIDL).  The details of a class, its instance variables, 
  5494. methods and the name of its superclass, are all defined using OIDL, and are 
  5495. placed in a file known as the Class Definition File. 
  5496.  
  5497. The class definition file is used as input to the SOM compiler, which uses the 
  5498. information to generate several new files, such as C header files, a module 
  5499. definition file to be used when linking the object, and a skeleton C source 
  5500. file containing a prototype function for each method defined in the OIDL.  The 
  5501. programmer inserts the application function he requires into this source file 
  5502. to implement the methods he wants, and then compiles and links the program in 
  5503. the usual way to produce DLL containing the object class. 
  5504.  
  5505. A class definition file contains the following sections: 
  5506.  
  5507. Include Section              This section consists of a statement to include 
  5508.                              the class definition file of the parent class. 
  5509.  
  5510. Parent Class Section         This section defines certain basic information 
  5511.                              about a new class, such as its name and release 
  5512.                              level, and, by convention, comments that describe 
  5513.                              its position in the class hierarchy. 
  5514.  
  5515. Release Order Section        This section is used to allow a programmer to 
  5516.                              specify in which order the methods and public data 
  5517.                              of his class will be released.  This can be 
  5518.                              important if the class is subsequently subclassed; 
  5519.                              without the release order having been specified, 
  5520.                              it could prove necessary to recompile the parent 
  5521.                              class in that case. 
  5522.  
  5523. Metaclass Section            This optional section is used to give information 
  5524.                              about the class's metaclass (that is, the class of 
  5525.                              which the new class is itself to be an instance). 
  5526.  
  5527. Passthru Section             This section allows a programmer to include some 
  5528.                              programming language code that will be placed by 
  5529.                              the SOM compiler into the language source file it 
  5530.                              generates. It is typically used for such things as 
  5531.                              typdef and #define statements. 
  5532.  
  5533. Data Section                 This section specifies the instance variables to 
  5534.                              be used by the class. 
  5535.  
  5536. Methods Section              This section lists all the methods which are to be 
  5537.                              defined by the class, both those that are new to 
  5538.                              the class and those of its parent class that it 
  5539.                              will be overriding. 
  5540.  
  5541.  
  5542. ΓòÉΓòÉΓòÉ 17.2.3. Using Workplace Shell Classes ΓòÉΓòÉΓòÉ
  5543.  
  5544. The Workplace Shell introduces several new classes derived from the SOMObject 
  5545. class; for example, class definitions for a folder (WPFolder), a program 
  5546. reference (WPProgram) and a printer (WPPrinter).  The class hierarchy of the 
  5547. classes used in the Workplace Shell is illustrated in Figure "Workplace Shell 
  5548. Class Hierarchy". 
  5549.  
  5550. Notice that this hierarchy includes three so-called base classes from which all 
  5551. the remaining classes are derived;  these base classes are also known as base 
  5552. storage classes because the fundamental difference between them, and therefore 
  5553. between all their derived classes, lies in the way they store their control 
  5554. data. For a fuller discussion of this see Workplace Shell Implementation. 
  5555.  
  5556. If you want to implement a new WPS class, you must first decide which of the 
  5557. existing classes provides the most promising base from which to work -  you 
  5558. have to subclass one of them. Early experience suggests that subclassing the 
  5559. existing base classes or their derivatives is usually the more practicable 
  5560. approach - implementing a new base class by subclassing WPObject may be 
  5561. desirable but should be regarded as a very major piece of work. 
  5562.  
  5563.  
  5564. ΓòÉΓòÉΓòÉ 17.2.4. The Structure of a Workplace Shell Application ΓòÉΓòÉΓòÉ
  5565.  
  5566. The Workplace Shell has been implemented in such a way that the whole shell and 
  5567. all its objects, be they system supplied or user developed, run as a single 
  5568. OS/2 process. This has some very significant implications: 
  5569.  
  5570.  If an object abends for any reason, the whole shell and all its objects 
  5571.   crash, disrupting the user's work, and possibly resulting in lost data. 
  5572.  
  5573.  If a method of a Workplace Shell object takes too long to complete its 
  5574.   processing, the whole user interface will be locked up until it completes. 
  5575.  
  5576.   This is a problem familiar to PM programmers, and as with PM, the solution is 
  5577.   to start a second thread for the long-running code.  Typical situations where 
  5578.   this problem can arise include retrieving data from a database or 
  5579.   communicating with a host system. 
  5580.  
  5581.  There is potential for data integrity problems, as it is possible for all 
  5582.   objects to access each others' data;  this is probably more of a problem in 
  5583.   theory than in practice, since most accidental addressing errors will still 
  5584.   result in "Trap" errors. 
  5585.  
  5586. The recommended solution to these problems is to split an application into two 
  5587. parts: one part, consisting of one or more WPS objects running in the WPS 
  5588. process,  the other part containing most of the application logic running as a 
  5589. separate OS/2 process.  The two parts communicate using the interprocess 
  5590. communications (IPC) facilities of OS/2. 
  5591.  
  5592. To avoid the problems above, it is best to put as little of the application as 
  5593. possible into the WPS objects themselves.  Clearly some functions must be there 
  5594. - for example the code to create and handle an object's context menu, or to 
  5595. handle direct manipulation - and we have found it best also to code PM dialog 
  5596. and window creation and their dialog and window procedures within the WPS 
  5597. objects. Other application functions, such as database access, communications 
  5598. and calculation, should be put in a separate process. 
  5599.  
  5600. This structure approximates to the Model-View design approach favored by 
  5601. object-oriented programmers. Our recommendation effectively places the View in 
  5602. the WPS process and the Model in a separate process. 
  5603.  
  5604. The Workplace Shell documentation provides no guidance on good and bad ways of 
  5605. implementing an application using IPC between the shell process and the 
  5606. application processing thread.  OS/2 Version 2.0 - Volume 4:  Application 
  5607. Development includes a discussion of this and describes one approach that has 
  5608. been tried, along with programming examples. 
  5609.  
  5610.  
  5611. ΓòÉΓòÉΓòÉ 17.3. Writing PM Applications to Work with the Workplace Shell ΓòÉΓòÉΓòÉ
  5612.  
  5613. The Presentation Manager has been enhanced to include several new classes for 
  5614. use with the Workplace Shell, notably the Container and Notebook classes. The 
  5615. OS/2 V2.0 Presentation Manager would seem to have all the basic requirements 
  5616. for writing programs that have the capabilities of Workplace Shell 
  5617. applications, without programmers having to learn SOM or become familiar with 
  5618. the Workplace Shell class hierarchy. 
  5619.  
  5620. The question that arises therefore is this: how well can a straightforward PM 
  5621. program that uses the new classes and the drag/drop protocols integrate itself 
  5622. into the WPS environment?  This section helps to answer this. 
  5623.  
  5624.  
  5625. ΓòÉΓòÉΓòÉ 17.3.1. The Workplace Shell and PM ΓòÉΓòÉΓòÉ
  5626.  
  5627. The Workplace Shell along with all its registered classes, be they 
  5628. system-supplied or user-written, is itself just a Presentation Manager program. 
  5629. As such it should be able to cooperate quite well with other PM programs, as 
  5630. long as it conforms to the protocols laid down by PM, particularly for drag and 
  5631. drop. 
  5632.  
  5633. The technical term for the drag/drop protocols is Rendering Mechanisms; the 
  5634. standard ones are defined in the OS/2 2.0 Programming Guide Volume II. The 
  5635. Workplace Shell implements the Print and the OS/2 File rendering mechanisms. 
  5636. These make it possible for a PM application to provide direct manipulation 
  5637. printing capabilities and, if required, file drag/drop facilities similar to 
  5638. those provided in the OS/2 Version 1.3 File Manager. 
  5639.  
  5640.  
  5641. ΓòÉΓòÉΓòÉ 17.3.2. How Much Can You Do with PM? ΓòÉΓòÉΓòÉ
  5642.  
  5643. You can emulate many Workplace Shell characteristics in a straightforward PM 
  5644. program.  For example you can: 
  5645.  
  5646.  Display container windows, which look very much like WPS folders, and 
  5647.   populate them with icons that look superficially like WPS object icons. 
  5648.  
  5649.  Implement context menus for both icons and windows. 
  5650.  
  5651.  Provide drag/drop facilities for the items handled by the program.  When 
  5652.   these items represent files the standard OS/2 File rendering mechanism will 
  5653.   allow them to be dragged in and out of WPS folders.  When it makes sense to 
  5654.   print these items, they can support the standard Print rendering mechanism, 
  5655.   to allow printing by direct manipulation. 
  5656.  
  5657. Although a PM program can participate to some extent with the Workplace Shell, 
  5658. there are still things the user may want to do that cannot easily be 
  5659. implemented without developing the application using SOM and WPS. 
  5660.  
  5661. Consider a PM program that displays some icons in a container window 
  5662. representing customers of a particular branch of a company. The user sees these 
  5663. icons in a window that looks very much like a WPS folder. He may reasonably 
  5664. expect to be able to drag the icon of a customer in whom he is particularly 
  5665. interested onto the desktop or into another folder. 
  5666.  
  5667. How can a PM program handle this? The Workplace Shell supports the OS/2 File 
  5668. rendering mechanism, but that is not really suitable for customers, whose 
  5669. details are more likely to share a database table than to occupy a separate 
  5670. file each. The PM program may allow the drag to take place, but cannot support 
  5671. any rendering mechanism that a WPS folder will understand, so the user sees the 
  5672. "inhibited" pointer while the customer icon is over the desktop and is not 
  5673. allowed to drop it. 
  5674.  
  5675. This confuses the user, who expects to be able to put any object anywhere he 
  5676. chooses. 
  5677.  
  5678.  
  5679. ΓòÉΓòÉΓòÉ 17.3.3. Migrating Existing Applications ΓòÉΓòÉΓòÉ
  5680.  
  5681. Many OS/2 users will find themselves with existing PM applications that they 
  5682. have developed, and may wonder whether they can modify them to exploit the 
  5683. Workplace Shell environment.  Ideally, one would like every application to be 
  5684. built as a collection of WPS objects, interacting with one another and with the 
  5685. standard WPS objects, but many users will decide that converting existing PM 
  5686. programs to this application model is not justified. 
  5687.  
  5688. There are two approaches one may take to application migration:  one is simply 
  5689. to make a few minor modifications so that the application works better in the 
  5690. new environment,  the other is to convert the whole program to the WPS/SOM 
  5691. application model, carrying over as much code from the PM version as possible. 
  5692.  
  5693. Minimal Changes 
  5694.  
  5695. A particularly useful facility provided by the Workplace Shell is Association; 
  5696. this can be by file type, filename or extension. A program may be associated 
  5697. with one or more data files. The effect of this is that the program concerned 
  5698. automatically becomes one of the views available from the Open action on the 
  5699. context menu of any file with this type. Opening this view causes the 
  5700. associated program to be started with the filename as its first command line 
  5701. parameter. 
  5702.  
  5703. Many programs that operate on files are written to expect a filename as their 
  5704. first parameter, so these programs can be used in the Workplace Shell 
  5705. environment in a way that is consistent with the object-oriented user interface 
  5706. - the user chooses the object he wants to work on and opens it;  the window 
  5707. presented by the program can be thought of as a view of the object. 
  5708.  
  5709. Any program that does not accept a filename as a command-line parameter can 
  5710. easily be modified to do so. 
  5711.  
  5712. Other changes that could be considered: 
  5713.  
  5714.  Change the way the program ends, so that by default it saves its data back 
  5715.   into the file from which it read it.  This is more consistent with the way a 
  5716.   Workplace Shell object allows you to open a view, make changes, then close 
  5717.   the view, without having explicitly to save the data first. 
  5718.  
  5719.  Replace the menu bar with a context menu.  This may or may not be desirable - 
  5720.   menu bars are still a quite acceptable part of the user interface and are 
  5721.   required by CUA 91, but are little used within Workplace Shell itself. 
  5722.  
  5723.  Implement some simple direct manipulation - doing this for printing can be 
  5724.   very straightforward, and makes the program fit much better into the 
  5725.   Workplace Shell environment. 
  5726.  
  5727.   Supporting drag/drop for files, even in a limited way, can be very helpful. 
  5728.   As an illustration, consider the Enhanced Editor provided with OS/2. This is 
  5729.   a standard PM program but you can drag WPS data file objects from any folder 
  5730.   and drop them on the open editor - the result is that the file is added to 
  5731.   the edit ring (the list of files currently being edited). 
  5732.  
  5733.  If the program offers several tailoring options for the application, 
  5734.   implement a Settings view, similar to those provided by WPS objects. 
  5735.  
  5736.  If the application includes many large dialogs, currently using separate 
  5737.   dialog boxes invoked from the menu bar, consider replacing these with a 
  5738.   notebook control - it can make a complex application seem a lot simpler. 
  5739.  
  5740.  Add an ASSOCTABLE statement to the program's resource script file. This 
  5741.   statement sets up associations for the program so that the user is relieved 
  5742.   of the need to do it himself, and also provides the only way to add new file 
  5743.   types to those provided by the system.  For details of this see "Using an 
  5744.   ASSOCTABLE to Add New File Types" below. 
  5745.  
  5746.   This statement allows for associations based on file extension, but our 
  5747.   recommendation is to use file types as they provide greater flexibility for 
  5748.   the user. 
  5749.  
  5750.  If necessary, modify the program so that it behaves well when provided with 
  5751.   an empty input file.  For example, if the program normally expects the 
  5752.   contents of its files to have some pre-defined structure, make the program 
  5753.   set up this structure automatically if it reads an empty input file, rather 
  5754.   than issue a message complaining that the file is invalid. 
  5755.  
  5756.   The reason for this change is that we want the user to be able to start a new 
  5757.   file by first dragging a new object of an appropriate type from the Templates 
  5758.   folder, then opening it to start the application program.  Typically, the new 
  5759.   file will be empty at this stage, so the program must recognize and accept 
  5760.   that the user has chosen to start a new one.  Many existing PM programs 
  5761.   expect the user to start a new file by selecting New from the File menu and 
  5762.   will only load those files that already contain valid data. 
  5763.  
  5764. For PM programs that operate on whole files, like word processors and 
  5765. spreadsheets, very good results can be achieved with these simple techniques, 
  5766. without ever having to write any SOM code. With a template file available, and 
  5767. associations already set up, all the user need do to start working on a new 
  5768. file (document, spreadsheet, or whatever it is), is to drag a new one from the 
  5769. template and open it.  The program will start, presenting the user with a view 
  5770. of the data, and when he is finished working on it, he can close the view (that 
  5771. is, the program), and the data is saved automatically. 
  5772.  
  5773. An Illustration 
  5774.  
  5775. Let us illustrate this with a simple example.  We have an existing PM program 
  5776. that is an expenses calculator.  When it starts it presents an empty window 
  5777. with a menu bar that has two actions - File and Process.  With the File action 
  5778. the user can elect to start a new expenses form, load an existing one from 
  5779. disk, save the current one to disk, or to exit.  The Process pull-down menu 
  5780. includes actions to calculate totals, to print the current form, or to send it 
  5781. to the cashier for processing. 
  5782.  
  5783. Let us see how we might modify this application to work in a way that is 
  5784. consistent with the Workplace Shell user interface: 
  5785.  
  5786.  1. Add an ASSOCTABLE statement to the program's resource script file, 
  5787.     associating the program with the new type: Expense Form. 
  5788.  
  5789.  2. Modify the program so that it expects a filename as its first command line 
  5790.     parameter and automatically loads an expense form from the named file.  If 
  5791.     the program finds that the input file is empty it should start a new 
  5792.     expense form. 
  5793.  
  5794.  3. Modify the program so that when closed it automatically saves the current 
  5795.     data into the file it read in when started (after prompting the user to 
  5796.     confirm that this is what he wants). 
  5797.  
  5798.  4. Take the actions currently on the menu bar and implement them in a context 
  5799.     menu  displayed when the user presses Mouse Button 2.  Provide an option 
  5800.     for the user to turn off the menu bar, which is now redundant. 
  5801.  
  5802.  5. Provide the user with installation instructions that tell him to copy the 
  5803.     .EXE file onto his disk and create a Program object referring to it.  This 
  5804.     will ensure that the Expense form file type is added to his system, and 
  5805.     that an Expense form template file is created. 
  5806.  
  5807. Now the user can start a new expense form by dragging one from the template in 
  5808. the Templates folder and double-clicking on it to start working with it. The 
  5809. context menu will then let the user calculate totals, print the form or send 
  5810. the form off for processing. 
  5811.  
  5812. This is still not perfect; the user may well expect, as with real Workplace 
  5813. Shell objects, to be able to access the context menu from the object itself, 
  5814. not just from a view of it. This can be put right by making two copies of the 
  5815. program, and modifying them as follows: 
  5816.  
  5817.  The first should be modified so that it only prints forms 
  5818.  
  5819.  The second should be modified so that it only sends forms for processing. 
  5820.  
  5821. These programs will be easy to produce since they already contain all the 
  5822. required function.  All that needs to be changed is to make them perform their 
  5823. specific functions automatically when started, and to remove extraneous code. 
  5824.  
  5825. Since a large amount of code may now be duplicated between the three programs, 
  5826. it may be worth restructuring them so that common functions reside in a DLL 
  5827. accessible to all three. This provides significant benefits for run-time 
  5828. performance and program maintenance. 
  5829.  
  5830. The user working with an expense form file will now find its context menu 
  5831. contains actions to open a form (which will start the main program), to print a 
  5832. form (which will invoke the new print program), and to send the form off for 
  5833. processing (which will invoke the other new program).  These actions are also 
  5834. available from within the main program when the user is actually working on the 
  5835. form. 
  5836.  
  5837. The user may find it odd that all these actions appear under the Open action in 
  5838. the context menu.  This could be improved by removing the association from the 
  5839. Print and Send programs, and manually adding menu items to the template expense 
  5840. form file to invoke these programs. 
  5841.  
  5842. The user will also find that he cannot print by direct manipulation of the file 
  5843. itself. If the user drags the Expense Form object onto a printer, it will print 
  5844. as a text file. There is no way that our print program can be invoked 
  5845. automatically to format the data in this situation. The only solution to this 
  5846. would be to develop a new WPS class, derived from WPDataFile, that overrides 
  5847. the wpPrintObject message. Then, when the object is asked to print itself, 
  5848. (typically in response to having been dropped on a printer object), it will 
  5849. invoke the print program to provide the required formatting. Developing this 
  5850. class would not involve very much work, but would require the programmer to be 
  5851. familiar with WPS and SOM programming. 
  5852.  
  5853. With only minor exceptions the expense form file object now behaves almost 
  5854. exactly as it might if it had been implemented as a new Workplace Shell class 
  5855. derived from WPDataFile, when in fact it is simply an ordinary data file with 
  5856. some associated PM programs. 
  5857.  
  5858. Using an ASSOCTABLE to Add New File Types 
  5859.  
  5860. The scenario described above requires that a new file type be added to every 
  5861. user's system - in the example its name was Expense form. This section explains 
  5862. how to do this for your own program. An alternative approach that is suitable 
  5863. for users and administrators can be found in Adding New File Types. 
  5864.  
  5865. The standard programming technique to do this involves the ASSOCTABLE statement 
  5866. in a program's resource script file. (This is one of the source files that a 
  5867. programmer creates when developing a PM program - for more information about 
  5868. this see OS/2 Version 2.0 - Volume 4:  Application Development).  This 
  5869. statement defines associations for the program being developed, in terms of 
  5870. either file type, filename or extension. The file type can be anything you 
  5871. choose, regardless of whether it is one of the existing file types defined 
  5872. within OS2.INI. In the case of the example above, the Expense form file type 
  5873. may be used in the ASSOCTABLE statement, despite the fact that at that time it 
  5874. is not a type known to OS/2. 
  5875.  
  5876. An ASSOCTABLE suitable for this example is shown in Figure "An ASSOCTABLE 
  5877. Resource Script File Statement". The first quoted string gives a file type to 
  5878. be used for association with this program;  the second string allows for 
  5879. association by filename or extension (if you want to use only association by 
  5880. file type, an empty string may be specified here); the third parameter 
  5881. specifies that we want this program to be automatically associated with data 
  5882. files with this type; the last parameter specifies an icon to be used for 
  5883. representing data files that have this attribute. 
  5884.  
  5885. When the program has been built, the Settings view for the executable file 
  5886. shows, on its Associations page, that associations have been set up for the 
  5887. specified file type(s) - in our case Expense form. 
  5888.  
  5889. At this stage, however, there is no way you can create a data file with this 
  5890. file type - when you open the Type page of a data file's Settings view you find 
  5891. that Expense form is not one of the available types. 
  5892.  
  5893. To achieve this you must create a Program object that refers to the executable 
  5894. file that you just created.  (The usual way to do this is to drag a Program 
  5895. object from the Program template in the Templates folder, then insert the 
  5896. executable file's path and filename into the "Program" page of its Settings 
  5897. view). This registers the program to the Workplace Shell, which finds that the 
  5898. program includes a type for association, and adds this to its list of available 
  5899. file types. It also adds a template file for this type to the Templates folder. 
  5900.  
  5901. The new types are then available to be added to any data files on the system 
  5902. and new files of these types can be created by the user at any time simply by 
  5903. dragging from the corresponding templates. 
  5904.  
  5905. Converting a PM Program to WPS/SOM 
  5906.  
  5907. To convert an existing PM application to be a full SOM/WPS application may 
  5908. require a great deal of work, depending on how well structured the program is 
  5909. to begin with. 
  5910.  
  5911. Much of the code can probably be preserved - when a WPS object wants to display 
  5912. a window, it does so using normal PM facilities to create the window and has to 
  5913. provide a normal PM window procedure to support it;  most of this code may be 
  5914. transferred directly from the older program.  Similarly, any application 
  5915. processing code - for example for database access, communications, or 
  5916. calculation should be equally applicable to the new version. 
  5917.  
  5918. The steps necessary to make the conversion include: 
  5919.  
  5920.  Consider the split between function that will be implemented as WPS objects 
  5921.   (with all the drawbacks of running in the WPS process), and function that 
  5922.   will be implemented in separate processes. 
  5923.  
  5924.  Devise the interprocess communications (IPC) protocols to be used between the 
  5925.   two parts of the application. 
  5926.  
  5927.  Design the revised user interface.  Although much may be preserved, there 
  5928.   will inevitably be design changes needed to make the application work well 
  5929.   for the user in the new environment.  These may include: 
  5930.  
  5931.    - Increased emphasis on the use of icons to represent the data items 
  5932.      manipulated by the application 
  5933.  
  5934.    - Changes to terminology used (for example, "views" rather than "windows") 
  5935.  
  5936.    - Use of container windows where list boxes may previously have been used 
  5937.  
  5938.    - Replacing complex dialogs with notebook controls 
  5939.  
  5940.    - Adding context menus. 
  5941.  
  5942.  Add the capability for the program to save its state when closed so that, the 
  5943.   next time it is started, the program's options, settings, its window position 
  5944.   and so on are the same as the last time it was run. 
  5945.  
  5946.  Provide a way for the user to retrieve application windows that have been 
  5947.   minimized.  Since in OS/2 Version 2.0 windows are not necessarily minimized 
  5948.   onto the desktop, it is possible that application windows that the program 
  5949.   has not added to the window list may be hard to restore. Such designs need to 
  5950.   be revised for OS/2 Version 2.0. 
  5951.  
  5952.  
  5953. ΓòÉΓòÉΓòÉ 17.4. Summary ΓòÉΓòÉΓòÉ
  5954.  
  5955. Presentation Manager applications differ in structure from conventional 
  5956. applications. Presentation Manager applications are composed of a number of 
  5957. windows, which represent objects upon which the application operates.  Windows 
  5958. respond to events, communicated by way of messages passed to the windows from 
  5959. Presentation Manager or from other windows. 
  5960.  
  5961. Windows may be either display windows, which operate on objects known as 
  5962. presentation spaces, or object windows, which operate on other objects such as 
  5963. databases or remote systems.  Display windows have a visual manifestation on 
  5964. the screen, while object windows are typically hidden and act merely as 
  5965. addresses to which messages may be sent in order to initiate actions. 
  5966.  
  5967. Windows are grouped into classes.  Each class has similar characteristics and 
  5968. responds to messages in a similar way.  Window classes must be registered to 
  5969. Presentation Manager.  Some window classes are defined as public, and may be 
  5970. used by all applications in the system, while other window classes are defined 
  5971. privately by an application, and are available only to that application. 
  5972.  
  5973. The response of a window to the messages it receives is determined by its 
  5974. window procedure.  All windows of the same class share the same window 
  5975. procedure. 
  5976.  
  5977. Messages are also grouped into classes; Presentation Manager defines a number 
  5978. of message classes, and applications may define their own classes for 
  5979. communicating events between windows in the application.  Message classes are 
  5980. simply defined using integer constants, and are not required to be registered 
  5981. to Presentation Manager. 
  5982.  
  5983. The structure of a Presentation Manager application is therefore that of a 
  5984. number of windows which communicate by way of messages.  Since these messages 
  5985. normally constitute the only means of communication with a window and the 
  5986. objects upon which it acts, this application structure forms a good basis for 
  5987. the implementation of object-oriented software engineering principles. The use 
  5988. of such principles in Presentation Manager applications is discussed at length 
  5989. in OS/2 Version 2.0 - Volume 4:  Application Development. 
  5990.  
  5991. Workplace Shell applications are implemented using the System Object Model 
  5992. component of OS/2 V2.0. This is a language-independent environment for 
  5993. object-oriented programming, along with a set of utilities that enable the 
  5994. programmer to define object classes, and to implement them in non-OOP languages 
  5995. such as C. 
  5996.  
  5997. A Workplace Shell application will typically consist of one or more objects, 
  5998. which are defined by the programmer using the SOM, and inheriting 
  5999. characteristics from the Workplace Shell's own existing classes. 
  6000.  
  6001. The shell and all its objects run in OS/2 as a single process, which makes the 
  6002. shell and its objects vulnerable to a single object that is unresponsive or 
  6003. which abends. A well-designed Workplace Shell application should therefore be 
  6004. structured so that the bulk of its application logic runs in a separate 
  6005. process, communicating with the Workplace Shell objects that implements its 
  6006. user interface by means of OS/2 interprocess communication. 
  6007.  
  6008. It is possible to write PM programs that integrate to some extent with the 
  6009. Workplace Shell environment, for example by supporting printing by direct 
  6010. manipulation, but such programs will never behave quite like properly designed 
  6011. Workplace Shell applications.  Migrating existing PM applications to work 
  6012. better in the Workplace Shell environment is fairly straightforward, and good 
  6013. results can be obtained in many cases by exploiting the association facility of 
  6014. WPS. Fully migrating a PM program to become a SOM/WPS application may be 
  6015. possible in many cases, though this involves considerable redesign and 
  6016. programming. 
  6017.  
  6018. We cannot give a clear recommendation as to which programming model - PM or WPS 
  6019. - to adopt for new applications.  It will depend on many factors, such as the 
  6020. application itself, the needs and skills of the users, the skills of the 
  6021. programmers, and on any other applications that may be used at the same time. 
  6022. The decision must be made based on the nature of the application and the 
  6023. customer environment in which it is to be used. 
  6024.  
  6025.  
  6026. ΓòÉΓòÉΓòÉ 18. Workplace Shell Implementation ΓòÉΓòÉΓòÉ
  6027.  
  6028. This chapter looks at what happens "under the covers" of the Workplace Shell 
  6029. (WPS). We examine the shell from several viewpoints: 
  6030.  
  6031.  The implementation of the WPS as an OS/2 program 
  6032.  The different types of shell objects 
  6033.  The relationship of the shell to the file system 
  6034.  Persistence in WPS objects. 
  6035.  
  6036. This chapter will help you to understand how the Workplace Shell is 
  6037. implemented, know what kinds of objects it stores and where it stores 
  6038. information about them. If you wish to understand the System Object Model, 
  6039. object-oriented programming in OS/2 V2.0 and how to create your own WPS program 
  6040. you should read the appropriate sections of the companion volume, OS/2 Version 
  6041. 2.0 - Volume 4:  Application Development. 
  6042.  
  6043.  
  6044. ΓòÉΓòÉΓòÉ 18.1. The Workplace Shell as an OS/2 Program ΓòÉΓòÉΓòÉ
  6045.  
  6046. One of the biggest changes in OS/2 V2.0 is its support for installable 
  6047. interface shells. The installable feature concept was introduced in OS/2 
  6048. Version 1.3 with the HPFS file system; OS/2 V2.0 has now extended it to the 
  6049. user interface. The installable feature approach gives users the flexibility to 
  6050. set up their system to meet their precise needs. 
  6051.  
  6052. The Workplace Shell is called from the CONFIG.SYS file as follows: 
  6053.  
  6054.   PROTSHELL=C:\OS2\PMSHELL.EXE
  6055.  
  6056. Alternative shells can be implemented or, if desired, a single program, such as 
  6057. Lotus 1-2-3 /G, could be started directly without having to start the WPS at 
  6058. all. 
  6059.  
  6060. The Workplace Shell run in its own process, starting threads as needed.  For 
  6061. instance, the contents of a directory can be read while its associated folder 
  6062. window is being created. In addition, the WPS starts a second process to 
  6063. monitor the shell and restart it if it fails. 
  6064.  
  6065. This in turn means that the overall system is no longer as vulnerable to shell 
  6066. errors as was the case in all previous versions of OS/2. If it detects an 
  6067. error, the WPS is capable of restarting itself without having to shut down and 
  6068. restart all the other running programs. 
  6069.  
  6070. The WPS does this by saving all the window information in real time and 
  6071. restoring it when the shell process is restarted. 
  6072.  
  6073. Existing PM applications are unaffected. PM programs which are implemented with 
  6074. a Model/View structure, where the "view" part runs in the WPS process, will 
  6075. have to be restarted and reconnected to the "model" portion of the program 
  6076. running in its own process. 
  6077.  
  6078. The Workplace Shell also notes which programs are running at any time and can 
  6079. restart them when the operating system is re-IPLed. 
  6080.  
  6081.  
  6082. ΓòÉΓòÉΓòÉ 18.1.1. Workplace Shell and the System Object Model ΓòÉΓòÉΓòÉ
  6083.  
  6084. The other major new feature of the Workplace Shell is that it is built on an 
  6085. object-oriented platform, called the System Object Model (SOM). SOM enables the 
  6086. WPS to be written as classes which inherit attributes from their superclasses 
  6087. and provides a high degree of reusability and integrity to the WPS 
  6088. implementation. Object-oriented programming and SOM are described more fully in 
  6089. Presentation Manager and Workplace Shell Application Development. 
  6090.  
  6091.  
  6092. ΓòÉΓòÉΓòÉ 18.1.2. Workplace Shell Object Types ΓòÉΓòÉΓòÉ
  6093.  
  6094. There are three main classes in the WPS class hierarchy, descended from 
  6095. WPObject.  The WPS classes are shown in Figure "Workplace Shell Class 
  6096. Hierarchy" 
  6097.  
  6098. Classes are used to create the instances, or objects, that the user sees on the 
  6099. desktop. Each can be subclassed to create a new, derived class which inherits 
  6100. some of the properties and behaviors of the parent. Two useful terms to note 
  6101. here are base class, a class which is a direct subclass of WPObject, and 
  6102. persistence, which denotes that an object knows how to save its current state. 
  6103.  
  6104. The main WPS classes are: 
  6105.  
  6106. WPObject           The superclass from which all base classes are derived. 
  6107.  
  6108. WPAbstract         A base class that provides persistence via the OS2.INI file. 
  6109.                    These include programs, shadow copies and system objects 
  6110.                    such as the clock. They can be copied around the Workplace 
  6111.                    Shell but not to diskette. 
  6112.  
  6113. WPFileSystem       A base class that provides persistence via the .CLASSINFO 
  6114.                    extended attribute of the associated file or directory. 
  6115.                    Objects of this class are always stored on disk. They are 
  6116.                    typically folders and files and can be copied to any media. 
  6117.  
  6118. WPTransient        A base class that has no persistence. Examples of 
  6119.                    WPTransient objects are the window list and the printer 
  6120.                    drivers. 
  6121.  
  6122.  
  6123. ΓòÉΓòÉΓòÉ 18.1.3. Relationship of the Shell to the File System ΓòÉΓòÉΓòÉ
  6124.  
  6125. The WPS represents program and data files with icons and allows you to move and 
  6126. copy them around the system in a similar way to the OS/2 Version 1.3 File 
  6127. Manager. There are also new functions like "shadow copy" and new objects like 
  6128. the system clock which have behaviors completely unlike those previously seen 
  6129. in the File Manager. 
  6130.  
  6131. The implementation of the Workplace Shell in OS/2 Version 2.0 is not inherently 
  6132. file-oriented but the current implementation only supports files, not data 
  6133. records or transactions. Data file and program icons may represent files on a 
  6134. disk. A folder is represented by a real directory under its name. Figure "Data 
  6135. Structure Supporting the Workplace Shell" shows the approximate disk structure 
  6136. which supports the WPS. 
  6137.  
  6138. As you can see, all folders are contained within the desktop and the 
  6139. directories of each folder on the desktop are subdirectories of the "OS!2 2.0 
  6140. DESKTOP" directory. From the directory structure we can see that the screen 
  6141. will display a Documents folder on the desktop and it, in turn, will contain 
  6142. three other folders; SCRIPTFILES, PERSONAL and 1992PLAN. 
  6143.  
  6144. Icons in any folder can be dragged (moved) into another folder or onto the 
  6145. desktop. When this happens, the file system will handle it in two different 
  6146. ways. If it is a data file it will be physically moved to the new directory. If 
  6147. it is a program reference or a shadow copy of a data file, then a pointer to 
  6148. the original object and its working directory is passed from one folder to the 
  6149. other. 
  6150.  
  6151. The relationship of the desktop to the file system is shown in Figure 
  6152. "Drag/Drop - Physical Implementation" 
  6153.  
  6154. Both the folder and the abstract objects in it are stored as pointers (called 
  6155. HOBJECTs) in the OS2.INI file (see Running Programs (Folder Contents) for more 
  6156. details). When a program is copied to another folder, the HOBJECT of the 
  6157. program is placed in that folders area within the OS2.INI file. The HOBJECT is 
  6158. also placed in the EAs of the directory which corresponds to the folder, along 
  6159. with its position within the folder. 
  6160.  
  6161. Handling programs in this manner makes sense because, if the programs' main 
  6162. executable modules were to be moved, the executable files could become 
  6163. separated from their DLLs. This approach allows a program to be copied and 
  6164. moved around the desktop without having to be physically moved. 
  6165.  
  6166. "Shadows" of file objects are handled in a similar way to programs; the 
  6167. original file is left in the source folder but a pointer to it is created in 
  6168. the target folder. HOBJECTs are discussed further in Folders. 
  6169.  
  6170. There are some problems associated with the Workplace Shell implementation. 
  6171. These are outlined below and discussed in more detail in the rest of the 
  6172. chapter: 
  6173.  
  6174.  The system is critically dependent on a single file, OS2.INI, for much of the 
  6175.   information. Damage to this file can have a disastrous effect on the user's 
  6176.   working environment. 
  6177.  The WPS uses EAs to store settings for files. However, EAs are not recognized 
  6178.   by all file systems, nor by any DOS or Windows programs.  This can cause 
  6179.   problems when setting up the working environment for a user who needs both 
  6180.   OS/2 and DOS programs. 
  6181.  With a FAT file system, moving files can lengthen disk access times as files 
  6182.   become fragmented and the tables become cluttered. This would impact users 
  6183.   who want to migrate their systems from DOS to OS/2 V2.0. 
  6184.  A program file is treated by the WPS as either a program reference object or 
  6185.   a data file object, depending on the view used. Once registered as a program 
  6186.   reference object and placed in a folder, the WPS restricts the actions which 
  6187.   can be performed on it. For example, copying or moving the object moves the 
  6188.   program reference, not the underlying file. Viewing the object from the 
  6189.   Drives folder, however, allows the user to work with the physical file. Thus 
  6190.   direct manipulation in the WPS means that sometimes the program file can be 
  6191.   moved and sometimes it cannot. 
  6192.  While data files and programs are handled by the shell, there is no base 
  6193.   class for record structures and transactions. To be able to create a 
  6194.   persistent "transaction" object capable of interacting fully with the other 
  6195.   WPS objects might require us to derive a new base class from WPObject. See 
  6196.   OS/2 Version 2.0 - Volume 4:  Application Development for a more detailed 
  6197.   discussion of this issue. 
  6198.  
  6199.  
  6200. ΓòÉΓòÉΓòÉ 18.2. Workplace Shell Objects ΓòÉΓòÉΓòÉ
  6201.  
  6202. This section looks at the main Workplace Shell objects and provides an 
  6203. introduction to how they are implemented. 
  6204.  
  6205.  
  6206. ΓòÉΓòÉΓòÉ 18.2.1. Folders ΓòÉΓòÉΓòÉ
  6207.  
  6208. Every folder corresponds to a directory in the file system.  The desktop is a 
  6209. special type of work area and is represented by \OS!2 2.0 DESKTOP in the file 
  6210. system. The top-level folders on the desktop are subdirectories of \OS!2 2.0 
  6211. DESKTOP. WPFolder objects and their contents are stored using a combination of 
  6212. a directory and the OS2.INI file. A folder may contain any kind of WPS object. 
  6213.  
  6214. WPFileSystem objects are real files residing in a file system directory 
  6215. corresponding to the folder. These objects are stored in the folders directory 
  6216. but not in the folders section of the OS2.INI file. 
  6217.  
  6218. WPAbstract objects are stored in the OS2.INI file. The information is stored 
  6219. with a pointer, called a HOBJECT. The folder stores the HOBJECTs for the 
  6220. abstract objects contained within it in the OS2.INI file, as can be seen in 
  6221. Figure "Relationship of Folder to Directory and OS2.INI File". This information 
  6222. is also stored in the EAs file for the directory associated with that folder. 
  6223. See The OS2.INI File for more details and some examples. 
  6224.  
  6225. WPTransient objects can be placed in a folder but are not stored by the 
  6226. operating system and disappear from the folder when OS/2 is shut down. 
  6227.  
  6228. Settings information is stored in the Extended Attributes of the folder's 
  6229. directory. Figure "Relationship of Folder to Directory and OS2.INI File" may 
  6230. help to illustrate these relationships: 
  6231.  
  6232. In the folder, IH1 is the icon for a program, IH2 is the icon for a shadow copy 
  6233. of a file, and IF1 to IF4H1 are icons for data files. The data files are stored 
  6234. in a directory - in HPFS this bears the same name as the folder. Pointers 
  6235. (HOBJECTs) to the abstract objects are stored in the Extended Attributes (EA) 
  6236. for the directory. 
  6237.  
  6238. The pointers are generated by the WPS when an abstract object is created (for 
  6239. example, by installing a program) and are unique to each WPAbstract object. The 
  6240. physical references to each WPAbstract object, together with its HOBJECT, are 
  6241. stored in the OS2.INI file. We can see that the program represented in the 
  6242. folder as IH1 is called AbstObj1 in the OS2.INI file and has a HOBJECT of H1. 
  6243. This HOBJECT is what is stored in the directory EA. You will notice that 
  6244. OS2.INI also separately records which WPAbstract objects are stored in each 
  6245. folder. 
  6246.  
  6247. Folder Population 
  6248.  
  6249. A folder populates itself with icons when it is opened and refreshed. The 
  6250. following approach is used: 
  6251.  
  6252.  The WPAbstract class keeps track of which folders its instances are in. 
  6253.  Pointers to WPAbstract objects (programs, shadows, etc.) are read from the 
  6254.   OS2.INI file and their icons are displayed. 
  6255.  The WPFindObjects method of WPAbstract, WPTransient, WPFileSystem, and any 
  6256.   other base class is used to retrieve the contents of a folder. For example, 
  6257.   in WPFileSystem this method reads the EAs for each file in the directory, 
  6258.   which tells it the object's class and provides its icon. A message is sent to 
  6259.   the appropriate class which then instantiates it. If the file doesn't have 
  6260.   any EAs then the default used is the base class, WPFileSystem. 
  6261.  The EAs are read for the directory. This gives the name (or OS2.INI program 
  6262.   reference) and icon position for each object to be displayed in the folder. 
  6263.  The object icon and title are displayed in the folder. 
  6264.  
  6265. Any alteration to the contents of a folder, such as adding a file or removing a 
  6266. shadow copy, is saved by the object when the event occurs. However, attributes 
  6267. of the folder, such as icon positions or the size and position of an opened 
  6268. view of the folder, are not saved until the contents view of that folder is 
  6269. closed. 
  6270.  
  6271. A folders view will not be automatically updated when a file is created or 
  6272. destroyed by a process outside the WPS process (such as from a command line in 
  6273. an OS/2 window). Restarting the system may resolve this. 
  6274.  
  6275. This is because the WPS does not receive every message from the file system 
  6276. concerning files which lay outside its workplace directory structure (that is, 
  6277. not under "OS!2 2.0 Desktop"). Notification is received if a new file is 
  6278. created or if an existing file is deleted or renamed, but not if an existing 
  6279. file is changed outside of the workplace. 
  6280.  
  6281.  
  6282. ΓòÉΓòÉΓòÉ 18.2.2. File System Objects ΓòÉΓòÉΓòÉ
  6283.  
  6284. A data file object in the Workplace Shell represents a real file in the file 
  6285. system. If the user shreds the object by dragging its icon to the shredder, the 
  6286. file is deleted. 
  6287.  
  6288. The only view which is always available to a data file is the Settings view. 
  6289. Settings are stored in extended attribute (EA) files. Refer to Extended 
  6290. Attributes for more information on EAs. Settings are displayed in a separate 
  6291. window from the main window, using a notebook control. 
  6292.  
  6293. The difference between descriptive and physical names is important. The 
  6294. descriptive name (or "object title") is the name which appears under the icon. 
  6295. It can be set in the "Title" field in the Settings view, or by "direct 
  6296. editing". The physical name is the actual name by which the data file is known 
  6297. to the file system. It can be set in the "Physical name" field in the Settings 
  6298. view. 
  6299.  
  6300. The two need not be the same. This provides an advantage in that long, 
  6301. meaningful icon descriptions can be used even without HPFS. 
  6302.  
  6303. The filename and object title are synchronized as much as possible. However, in 
  6304. FAT file systems the physical name is limited to 12 characters. When the 
  6305. description is longer than FAT will support, the filename is truncated. If a 
  6306. similar filename already exists, a version number is appended to it, However, 
  6307. the WPS always tries to ensure that the digits at the end of the filename match 
  6308. those in the title of the object. For example, a file with the title "My File : 
  6309. 22" might have a filename of "My_Fil22" on FAT and "My File : 22" on HPFS. 
  6310.  
  6311. There is some possibility for confusion in both file systems, since two objects 
  6312. within the same folder can have the same descriptive name even though they have 
  6313. different physical names. Figure "Effect of Changing Description on HPFS file 
  6314. names" shows the effect of "direct editing" an icon description. 
  6315.  
  6316. This is another reason for using the HPFS disk format: if you change the file 
  6317. description the WPS automatically changes the filename to be the same as the 
  6318. description. As you can see, the description and icon for the object are stored 
  6319. in the files Extended Attributes (EAs). When you copy the file under OS/2 V2.0, 
  6320. its EAs are copied too. 
  6321.  
  6322. The operating system settings determine what happens when you try to copy a 
  6323. file into a directory which already contains a file of that name. If a user 
  6324. copies an object to a folder where an identically named object already exists, 
  6325. the Workplace Shell will prompt the user to change the name (this is the 
  6326. default setting). The WPS applies a similar protection if the user tries to 
  6327. rename the object using "direct editing" of the icon description, but will not 
  6328. prevent the user from changing the title in the Settings view. 
  6329.  
  6330. For example, if a user copies a file to another folder, changes the contents, 
  6331. then copies it back to the original folder, the filename will be changed as in 
  6332. Figure "Effect of Copying Files on Filenames." 
  6333.  
  6334. When you copy the file from FOLDER1 to FOLDER2, the filename stays the same 
  6335. (ABCD.XYZ). When you copy it back to FOLDER1, the user is prompted to change 
  6336. the filename to ABCD1.XYZ. This is because the WPS believes that it should not 
  6337. destroy user data by default. 
  6338.  
  6339. Sometimes this is very useful. For instance, if you copied a spreadsheet, 
  6340. changed it extensively but forgot to rename it, then copied it back, you would 
  6341. be horrified if you then realized you had just copied over the original - which 
  6342. was just as important as the new one! 
  6343.  
  6344. A data file may associated with an executable file. This allows the program to 
  6345. be started and the data file passed to it when the data file is double clicked 
  6346. on. This is discussed in more detail in File Associations. 
  6347.  
  6348. Making a filename association in a program and setting the file type attribute 
  6349. in an associated data file can sometimes cause problems. This is because 
  6350. filename associations take precedence over file type associations. So if a user 
  6351. subsequently wants to change the file type for an object to use a different 
  6352. program with it, the file extension association will prevent him from doing so. 
  6353.  
  6354.  
  6355. ΓòÉΓòÉΓòÉ 18.2.3. Shadows ΓòÉΓòÉΓòÉ
  6356.  
  6357. Shadows are "aliases" for objects. Both WPProgram and WPFileSystem objects can 
  6358. be "shadowed" but it is not recommended to make shadow copies of programs. This 
  6359. is because a user might mistakenly edit the program title of the shadow copy 
  6360. and change the original program's filename, thus preventing it from being 
  6361. executed. 
  6362.  
  6363. The behavior of a shadow is identical to the object it shadows in all respects 
  6364. except one; deleting a shadow does not affect the source object. In practice, 
  6365. the user may find other differences; for example, deleting an object causes the 
  6366. deletion of all its shadows. Shredding an object which has shadows linked to it 
  6367. will generate a message window, informing the user that this object has shadows 
  6368. associated with it. 
  6369.  
  6370. Distinguishing a shadow icon from an object icon can be difficult, as there is 
  6371. only a subtle visual distinction between objects and their shadows (the text of 
  6372. a shadow is "grayed" or "dimmed"). Some users find it difficult to distinguish 
  6373. such a subtle difference and they should modify the shadow color text using the 
  6374. Scheme Palette within the System Setup folder. Shadows are also differentiated 
  6375. from real objects by the presence of the "Original" choice at the bottom of 
  6376. their context menus. 
  6377.  
  6378.  
  6379. ΓòÉΓòÉΓòÉ 18.2.4. Abstract Objects ΓòÉΓòÉΓòÉ
  6380.  
  6381. These include program references and shadow copies of files. Some can be 
  6382. programs written and executing within the Workplace Shell, others can be 
  6383. application programs running in their own processes while others can be shadow 
  6384. copies of data files. Since all objects have to have a program running behind 
  6385. them somewhere, there are many of these objects in the system, stored in the 
  6386. OS2.INI file. 
  6387.  
  6388. The system clock is an example of a program running in the WPS process, while 
  6389. the icon editor is an example of a PM program running in its own process 
  6390. outside the WPS. Shadow copies are discussed in Shadows. 
  6391.  
  6392. Since WPAbstract objects only physically exist in the OS2.INI file, they cannot 
  6393. be copied to diskette. This may confuse some users, who think that dragging a 
  6394. program reference or shadow copy to a diskette will cause the real file to be 
  6395. copied. 
  6396.  
  6397. Information about WPAbstract objects is held in the OS2.INI file.  For more 
  6398. information refer to The OS2.INI File. 
  6399.  
  6400.  
  6401. ΓòÉΓòÉΓòÉ 18.2.5. Transient Objects ΓòÉΓòÉΓòÉ
  6402.  
  6403. The main difference between these programs and abstract objects is that 
  6404. transient objects cannot save their state, that is, they are not "persistent". 
  6405. Also pointers to transient objects are not stored in directory EAs, unlike 
  6406. abstract objects. The values used when transient objects are started are 
  6407. usually stored within the program and there is no mechanism to write these back 
  6408. to disk. Examples of these programs include the window/task list and device 
  6409. drivers. 
  6410.  
  6411.  
  6412. ΓòÉΓòÉΓòÉ 18.3. Workplace Shell Facilities ΓòÉΓòÉΓòÉ
  6413.  
  6414. In looking at how the Workplace Shell is implemented, it is useful to separate 
  6415. the shell from the underlying workplace facilities, since the same facilities 
  6416. are needed by both the shell and by all applications which run under the shell. 
  6417. These facilities include: 
  6418.  
  6419.  Object registration 
  6420.  
  6421.  File associations 
  6422.  
  6423.  Direct manipulation 
  6424.  
  6425.  Icon interaction/messaging 
  6426.  
  6427.  The ability to create multiple instances of objects. 
  6428.  
  6429. These functions are implemented as WIN APIs which can be accessed from any 
  6430. language that has appropriate bindings. For example, "WinCreateObject" can be 
  6431. called from a C program. Some of these APIs, such as "SysRegisterObjectClass", 
  6432. have been mapped to a new version of REXX, 
  6433.  
  6434. One of the most important points to make here is that, from an application's 
  6435. viewpoint, the WPS can be totally invisible provided the application only uses 
  6436. objects which are already defined in the WPS class hierarchy, such as data 
  6437. files. For example, templates for data files can be created and associated with 
  6438. the program. 
  6439.  
  6440. Applications written for previous versions of OS/2 may take advantage of the 
  6441. basic functions supported by the class under which they are registered 
  6442. (typically WPProgram). For instance, a program can be started by dropping a 
  6443. data file on the program icon providing the program will accept a file name as 
  6444. a parameter. 
  6445.  
  6446.  
  6447. ΓòÉΓòÉΓòÉ 18.3.1. Object Registration ΓòÉΓòÉΓòÉ
  6448.  
  6449. When the user double clicks the mouse on a data file icon in the Workplace 
  6450. Shell,  a window opens up to display its default view. To do this, the system 
  6451. has to invoke a program and pass the file name to that program as a parameter. 
  6452. This requires the system to know which application (or object handler) to 
  6453. invoke, and where it is stored. 
  6454.  
  6455. In the File Manager under OS/2 Version 1.3, the services which performed this 
  6456. function were hidden and not available to applications.  In OS/2 Version 2.0, 
  6457. however, they are exposed and accessible through the Workplace Shell. There are 
  6458. three elements to this: program registration, file registration and file 
  6459. association. 
  6460.  
  6461. When an application is installed under the Workplace Shell, a program template 
  6462. is used to  register the application as an instance of the WPProgram class (a 
  6463. subclass of WPAbstract). This makes the program a persistent object. 
  6464.  
  6465. The program reference information and icon are stored in the OS2.INI file. The 
  6466. icon is displayed in a specified folder, and a default view is defined.  After 
  6467. registration this icon can be dragged and dropped on other WPS objects, such as 
  6468. a folder or the shredder. 
  6469.  
  6470. Data files are also registered with the WPS, which creates new instances of the 
  6471. WPDataFile class for them. The file is stored in a directory and its "settings" 
  6472. information is stored in EAs attached to the file. 
  6473.  
  6474. When you make a shadow copy of a file, the WPS creates an instance of the 
  6475. WPShadow class and stores it in the OS2.INI file. For this shadow, as with 
  6476. programs and files, using WPS facilities to create a new instance automatically 
  6477. registers it with the WPS. 
  6478.  
  6479.  
  6480. ΓòÉΓòÉΓòÉ 18.3.2. File Associations ΓòÉΓòÉΓòÉ
  6481.  
  6482. Files are associated with their "file handler" in two ways. The Settings view 
  6483. for an executable file contains an Association page. This page allows an 
  6484. application to be associated with its data file. The association can be by file 
  6485. type or by full or partial file name and extension. 
  6486.  
  6487. The file type, file name, partial file name or file extension (for example WP*, 
  6488. WP*.DOC, *.DOC) can be associated with a program from the program itself or the 
  6489. program reference. The file type (for example, OS/2 command file or plain text 
  6490. file) can be associated with a program using the Settings view for an object. 
  6491. Both sets of information are stored in the OS2.INI file. See The OS2.INI File 
  6492. for further details. 
  6493.  
  6494. A data file that "belongs" to an application will reflect this by having the 
  6495. application's name appear as a view that can be opened. Plain text files, for 
  6496. example, may be opened as a "System Editor" view. The Association page is 
  6497. available for command (CMD) files as well as executable (EXE) files. 
  6498.  
  6499. This duplication can cause confusion to the user if the associations are set in 
  6500. all three places. We recommend that if you have a program reference for a 
  6501. program, use this to set the associations instead of setting the associations 
  6502. from the program object itself. 
  6503.  
  6504.  
  6505. ΓòÉΓòÉΓòÉ 18.3.3. Direct Manipulation ΓòÉΓòÉΓòÉ
  6506.  
  6507. In OS/2 Version 1.3, a set of functions and messages were provided for direct 
  6508. manipulation, but each program had to provide its own code to take advantage of 
  6509. these functions, and define its own protocols to be observed during drag/drop 
  6510. operations, so that each program knew what type of information was being 
  6511. transferred. 
  6512.  
  6513. These protocols are called Rendering Mechanisms. Three standard ones were 
  6514. defined in OS/2 Version 1.3: 
  6515.  
  6516. Print        Provided a mechanism to enable printing by direct manipulation 
  6517.  
  6518. OS/2 File    Intended to be used by PM programs that wanted to move and copy 
  6519.              files by direct manipulation (such as the File Manager) 
  6520.  
  6521. DDE          Enabled Dynamic Data Exchange links to be established by direct 
  6522.              manipulation. 
  6523.  
  6524. Since PM did not provide common objects, such as printers and shredders, to 
  6525. implement these protocols the value of these rendering mechanisms was reduced. 
  6526. The apparent complexity of the direct manipulation functions and protocols also 
  6527. inhibited their use. 
  6528.  
  6529. More importantly, however, the non-object-oriented structure of most PM 
  6530. applications made designing direct manipulation into existing programs both 
  6531. difficult and largely ineffectual. The benefit of direct manipulation is 
  6532. directly proportional to the granularity of the objects being manipulated; 
  6533. where the finest grained object is a file, the only other objects it can 
  6534. interact with are containers and devices. Such interactions can as easily be 
  6535. implemented by the shell, as is shown by the implementation of the WPS. 
  6536.  
  6537. OS/2 Version 2.0 provides many common objects which can be used by 
  6538. applications, all of which are drag/drop enabled. When an icon (representing a 
  6539. WPS object or something dragged from a PM program) is dragged over a WPS 
  6540. object, that target object will send a message to the source object to try to 
  6541. complete a direct manipulation operation. 
  6542.  
  6543. That message says what the target icon does, so a successful drop depends on 
  6544. the source and target object implementing a common rendering mechanism; that 
  6545. is, the source object must be able to: 
  6546.  
  6547.  Understand the message 
  6548.  Perform the action carried in the message. 
  6549.  
  6550. If the source icon represents something that is unsuitable for dropping on this 
  6551. target object, then a drop will not be allowed and the user will be informed by 
  6552. the pointer changing to a "no-entry" symbol. 
  6553.  
  6554. Where possible, the WPS includes standard PM rendering mechanisms (for example, 
  6555. DM_DISCARDOBJECT) as well as its own WP messages (for example, (WP_DELETE). It 
  6556. is therefore possible for a PM application to interact with WPS devices by 
  6557. coding appropriate responses into the application using the drag/drop APIs. To 
  6558. do this, the programmer must know and understand the rendering mechanisms used 
  6559. by each WPS object. 
  6560.  
  6561. This is made more difficult because the WPS, for performance reasons, often 
  6562. implements functions within the core classes rather than leaving it to objects 
  6563. derived from the base classes, such as WPFileSystem, to carry out the action. 
  6564. Thus, when dragging a file to the shredder, the file does not receive the 
  6565. WP_Delete message; instead, the shredder program tells the OS/2 file system to 
  6566. delete the file. 
  6567.  
  6568.  
  6569. ΓòÉΓòÉΓòÉ 18.3.4. WPS Events/Messages ΓòÉΓòÉΓòÉ
  6570.  
  6571. Workplace Shell makes implementing drag/drop considerably easier for the 
  6572. programmer than it is under PM. Much of the filling of data structures and the 
  6573. drag part of drag/drop is handled by WPS, so that WPS simply sends the target 
  6574. object a pre-defined message if a successful drop sequence is completed. 
  6575.  
  6576. Without this help from WPS, a program must, for example, include code to handle 
  6577. the DM_DRAGOVER messages that occurs when an icon is being dragged over another 
  6578. icon without being dropped on it. If each application had to code an exchange 
  6579. for each device object in the system, as well as all the other possible 
  6580. objects, this would significantly complicate application development. It would 
  6581. also increase program size and memory usage, since each application would need 
  6582. to be running all the time. 
  6583.  
  6584. The Workplace Shell avoids this requirement by allowing a developer to register 
  6585. a small object which understands all the capabilities of the application, and 
  6586. can call the relevant parts of the main application when required. The standard 
  6587. direct manipulation capabilities of the WPS include Print, Delete and File 
  6588. Move/Copy. 
  6589.  
  6590. Print 
  6591.  
  6592. Workplace Shell implements the standard PM Print rendering mechanism 
  6593. (DRM_PRINT); after a successful drop, the source icon is sent a 
  6594. "DM_PRINTOBJECT" message with the name of the relevant print queue as one of 
  6595. its parameters. For WPS objects, the WPS may print the object automatically; 
  6596. non-WPS programs should perform the print to the specified queue when they 
  6597. receive the DM_PRINTOBJECT message. 
  6598.  
  6599. Delete 
  6600.  
  6601. The Workplace Shell shredder object supports a rendering mechanism called 
  6602. DRM_DISCARD. This is not one of the standard PM rendering mechanisms. If an 
  6603. item supporting this rendering mechanism is dropped on a shredder, then the 
  6604. source program is sent a "DM_DISCARDOBJECT" message. In the case of a Workplace 
  6605. Shell object, it will be deleted; in the case of a non-WPS PM program, the 
  6606. program must delete the dragged item in response to this message. 
  6607.  
  6608. File Move/Copy 
  6609.  
  6610. When an item is dropped onto a folder object and the dropped item is either a 
  6611. WPS object derived from WPFileSystem or a PM item whose associated data 
  6612. structures indicate that it is suitable, the target initiates the OS/2 File 
  6613. rendering mechanism (DRM_OS2FILE). In the case of the PM item, its suitability 
  6614. depends on whether its associated DRAGITEM structure includes a reference to 
  6615. DRM_OS2FILE in its hstrRMF field. For details of this see OS/2 Version 2.0 - 
  6616. Volume 4:  Application Development, which includes a detailed discussion of 
  6617. direct manipulation. 
  6618.  
  6619. In both cases, copy and move operations are supported according to any modified 
  6620. keys the user may be holding down at the time. The implementation of this 
  6621. rendering mechanism results in files being moved or copied between directories 
  6622. on disk. 
  6623.  
  6624.  
  6625. ΓòÉΓòÉΓòÉ 18.3.5. Persistence ΓòÉΓòÉΓòÉ
  6626.  
  6627. Some objects will disappear when the machine is rebooted, others will reappear. 
  6628. The former are called "transient" objects in the WPS and the latter are called 
  6629. "persistent" objects. Persistent objects are stored in the OS2.INI file and 
  6630. directory EAs. 
  6631.  
  6632. When you close a work area or shut down the desktop, any opened objects are 
  6633. recorded in the OS2.INI file and restarted next time the desktop or work area 
  6634. is reopened. Persistence for all WPS objects, such as the system clock, 
  6635. programs and shadow copies, is handled by their classes. 
  6636.  
  6637. The OS2.INI file implementation is critical to the WPS because it represents a 
  6638. single point of focus for the entire operating system. If it becomes corrupted 
  6639. the system will lose all the information about how to run programs, the 
  6640. associations between files and programs and which programs were previously 
  6641. running in the system. 
  6642.  
  6643.  
  6644. ΓòÉΓòÉΓòÉ 18.4. Extended Attributes ΓòÉΓòÉΓòÉ
  6645.  
  6646. Extended Attributes (EAs) are widely used in the Workplace Shell to record 
  6647. information about the attributes of the WPS objects. In general, information 
  6648. about an object is stored by the object itself. Thus a file stores information 
  6649. about its class and the location of the icon used to represent it, while the 
  6650. folder stores the position of the icon within it. 
  6651.  
  6652. On an HPFS partition, Extended Attributes are stored in a special, hidden area, 
  6653. close to the files themselves. On a FAT file system, Extended Attributes for 
  6654. files and directories are stored in a hidden file in the root directory of each 
  6655. FAT partition..  This file is named "EA_DATA. SF". 
  6656.  
  6657. EAs for the Workplace Shell are stored in the root directory of any logical 
  6658. disk accessed by it, in a hidden file called "WP_ROOT. SF". This file holds 
  6659. specific information about setup of the desktop. It is updated after the disk 
  6660. is accessed by any WPS object, such as the Drives folder. 
  6661.  
  6662. EAs for the LAN independent shell are stored in the root directory of any 
  6663. logical disk accessed through LAN utilities, such as the LAN Server folder, in 
  6664. a hidden file called "WP_SHARE. SF". This file is updated when changes are made 
  6665. to the logical disk by programs which make up the LAN independent shell. 
  6666.  
  6667. However, changes which are made to this disk from a WPS program are stored in 
  6668. the "WP_ROOT. SF" file. For example, this would happen if a user accessed the 
  6669. disk by issuing a "NET USE" command and then used the Drives folder to work 
  6670. with it. 
  6671.  
  6672.  
  6673. ΓòÉΓòÉΓòÉ 18.4.1. Directory Extended Attributes ΓòÉΓòÉΓòÉ
  6674.  
  6675. Folder attributes are stored in the Extended Attributes (EA) of the directory 
  6676. associated with it. The WPS creates two sections in the EAs for a directory. 
  6677. One section is used to store the icon positions for the objects displayed in 
  6678. the folder while the other records the folder attributes. This section 
  6679. discusses the directory EAs on an HPFS disk. 
  6680.  
  6681. The first one created is called ICONPOS and contains the following information: 
  6682.  
  6683. ..A...WPShadow:A2DA0.a..
  6684. ..J...WPDataFile:Fxyz...
  6685. ..J...WPDataFile:Fabc...
  6686. ..J...WPDataFile:FData_File.V.
  6687. ..<...WPShadow:A48CA.@...C....
  6688.  
  6689. Contents of Directory Extended Attributes (ICONPOS) 
  6690.  
  6691. This folder contains five objects: three are data files, called "xyz", "abc" 
  6692. and "Data_File"; and two are shadows, with HOBJECTs "2DA0" and "48CA". 
  6693.  
  6694. The ICONPOS section is created automatically by the WPS and 30 bytes are 
  6695. allocated for the folder position. Each file which is added to the folder is 
  6696. recorded here and 21 bytes are allocated for the icon position plus 1 byte for 
  6697. each character in the file name. Abstract objects (shadows and programs) take a 
  6698. fixed number of bytes; 23. This is based on 21 bytes for the icon position and 
  6699. 2 bytes for the abstract reference (HOBJECT) in the OS2.INI file. 
  6700.  
  6701. The other section is called "CLASSINFO". This includes information such as the 
  6702. class the folder belongs to (this can be changed by the "work area" checkbox in 
  6703. the Settings view). 
  6704.  
  6705. .............WPFolder.E)...)..
  6706. .)...~.....(.WPFolder...T.....
  6707. 0...U...D.P...[.....0.........
  6708. ....6.WPObject................
  6709. ..............................
  6710.  
  6711. Contents of Directory Extended Attributes (CLASSINFO) 
  6712.  
  6713. Information about which WPS class the object belongs to is needed to ensure 
  6714. that the correct class methods are used when the WPS is asked to create a new 
  6715. instance of the folder. 
  6716.  
  6717. Directory EAs are updated when the folder settings are changed from the 
  6718. Settings view and as the name or contents change. 
  6719.  
  6720.  
  6721. ΓòÉΓòÉΓòÉ 18.4.2. File Extended Attributes ΓòÉΓòÉΓòÉ
  6722.  
  6723. File settings are stored in extended attribute (EA) files. EAs are 
  6724. automatically created if the file was created using one of the WPS templates, 
  6725. but not if the file was copied or created directly from a command prompt. 
  6726.  
  6727. If the Settings view is opened and the EAs do not exist, then they are created 
  6728. at that time. When any of the settings are changed, the EAs are updated. This 
  6729. is done when a page on the notebook is changed and when the Settings view is 
  6730. closed The settings information in a file's EAs looks like this: 
  6731.  
  6732. EA #: 1  NameLen: 10  Name: >.CLASSINFO< ValueLen: 142
  6733. .........w...WPDataFile..rJ..rJ.-sJ.g.....T.WPObject.............
  6734.  
  6735. EA #: 2  NameLen: 9  Name: >.LONGNAME< ValueLen: 15
  6736. ....Test 1 File
  6737.  
  6738. EA #: 3  NameLen: 8  Name: >.SUBJECT< ValueLen: 27
  6739. ....Test file for LAN stuff
  6740.  
  6741. EA #: 4  NameLen: 5  Name: >.TYPE< ValueLen: 34
  6742. ..........Plain Text....BASIC Code
  6743.  
  6744. EA #: 5  NameLen: 5  Name: >.ICON< ValueLen: 4070
  6745.  
  6746. Contents of File Extended Attributes 
  6747.  
  6748. The file EAs are used to store: 
  6749.  
  6750. Classinfo     This contains the WPS class to which the object belongs. This 
  6751.               ensures that the correct WPS methods are used to instantiate the 
  6752.               object when the folder is opened. Any new programs added to the 
  6753.               file menu are also stored here. 
  6754.  
  6755. Longname      This contains the descriptive text that is displayed below the 
  6756.               icon. This is needed for FAT file systems where filenames are 
  6757.               restricted to 8 characters plus 3 for the file extension. 
  6758.  
  6759. Subject       This data is entered in the "Subject" field of the Settings view. 
  6760.  
  6761. Type          This records the file type of the object. A file can have 
  6762.               multiple file types. They are used to provide an association with 
  6763.               a program through the OS2.INI file. 
  6764.  
  6765. Icon          This stores the new icon used by the object if the user decides 
  6766.               to replace the default icon. Note that if he chooses to "Create" 
  6767.               a new icon, 1014 bytes are used, whereas if he "Edits" or 
  6768.               "Finds" an icon, 4070 bytes are needed. 
  6769.  
  6770. File EAs can shrink as well as grow. The disk space needed for the EAs grows as 
  6771. options are chosen but if the choices are removed later the EAs size will be 
  6772. reduced. 
  6773.  
  6774.  
  6775. ΓòÉΓòÉΓòÉ 18.5. The OS2.INI File ΓòÉΓòÉΓòÉ
  6776.  
  6777. This is the most important file in the Workplace Shell. It is the only place 
  6778. where information about WPAbstract objects, including which folder(s) they can 
  6779. be found in, is stored. The need for sensible backup and recovery mechanisms 
  6780. for OS2.INI is discussed in Installing and Supporting the Workplace Shell. 
  6781.  
  6782. Because it is the only place in OS/2 V2.0 where WPAbstract objects are stored, 
  6783. the Workplace Shell is limited to those WPAbstract objects defined within the 
  6784. OS2.INI in the root directory. That is, the Workplace Shell user cannot see any 
  6785. WPAbstract objects defined on a server, even if he can access the entire disk 
  6786. and desktop structure of that server. 
  6787.  
  6788. The OS2.INI file uses its own data structure and cannot be edited by an 
  6789. ordinary text editor, so if anything goes wrong you will probably have to 
  6790. reinstall OS/2 Version 2.0. Taking a backup of the OS2.INI file is highly 
  6791. recommended. Running MAKEINI.EXE is a possibility, but this will only restore 
  6792. the OS2.INI file to the state it was in when it was originally installed and 
  6793. any subsequent customization will be lost. These approaches may result in 
  6794. HOBJECT pointers in the directory EAs being different from those in OS2.INI, 
  6795. leading to a condition known as "unresolved abstracts". 
  6796.  
  6797. The OS2.INI file includes the following information: 
  6798.  
  6799.  Running programs 
  6800.  Shadow copy objects 
  6801.  Program reference objects 
  6802.  Icons for abstract objects 
  6803.  Color palette objects 
  6804.  Disk objects 
  6805.  Object instances in each folder 
  6806.  Folder position 
  6807.  File/program association filters 
  6808.  File/program association types 
  6809.  
  6810.  
  6811. ΓòÉΓòÉΓòÉ 18.5.1. Running Programs ΓòÉΓòÉΓòÉ
  6812.  
  6813. When the operating system starts up it restarts any programs which were running 
  6814. when the WPS stopped. The OS2.INI file contains the necessary information to 
  6815. support this. For example, Figure "Running Programs Stored in OS2.INI" shows 
  6816. several running programs. 
  6817.  
  6818. FolderWorkareaRunningObjects
  6819.         D:\OS!2 2.0 DESKTOP\OS!2_SYSTEM\COMMAND_PROMPTS
  6820.                 WPProgram:A74A6.
  6821.         D:\OS!2 2.0 DESKTOP\OS!2_SYSTEM
  6822.                 WPFolder:DCommand_Prompts.
  6823.                 WPDrives:DDRIVES.
  6824.  
  6825. Running Programs Stored in OS2.INI 
  6826.  
  6827. The running programs can include programs and workplace objects, such as 
  6828. folders and drives. 
  6829.  
  6830. The above figure shows two open folders, OS!2_System and its subdirectory 
  6831. COMMAND_PROMPTS. The running programs are stored together with their location 
  6832. so that it is easier to reinstantiate the system as it was left. Refer to the 
  6833. process of opening folders in Folders to understand why this is so. 
  6834.  
  6835. Abstract Objects 
  6836.  
  6837. Each abstract object is also stored in the OS2.INI file so it can be located 
  6838. using its reference. In the following example, we can see how a program is 
  6839. stored with its instance data. 
  6840.  
  6841. PM_Abstract:Objects
  6842.         D98F
  6843.                 ....WPShredder..#..p#...#......
  6844.                 ....WPAbstract.......Shredder..
  6845.                 ...........G.WPObject..........
  6846.                 ...............................
  6847.                 ..........<WP_SHRED>...........
  6848.  
  6849. Abstract Object Reference for Shredder in OS2.INI 
  6850.  
  6851. This object is the WPS Shredder. It is stored with its Workplace Shell class, 
  6852. OBJECTID, icon description and the classes it inherits from. The hexadecimal 
  6853. pair, D98F, in the upper left corner is the HOBJECT of the shredder. The 
  6854. location of each abstract object is also stored within the folder section of 
  6855. OS2.INI, as can be seen in the example below. 
  6856.  
  6857. Folder Contents 
  6858.  
  6859. Folder contents are stored in two places; in the ICONPOS EA file for each 
  6860. directory and in the OS2.INI file as shown below. Any running programs in 
  6861. opened folders are stored under the WorkAreaRunningPrograms section for 
  6862. reinstantiation during the OS/2 initialization, while the FldrContent section 
  6863. below includes all the abstract object references in that folder. These 
  6864. references are also stored, with their window coordinates, in the ICONPOS.EA 
  6865. file of the directory associated with the folder. 
  6866.  
  6867. PM_Abstract:FldrContent
  6868.         5506
  6869.                0000  8FD9 0000 AB91 00 00
  6870.                0008  1C04 0000 1E7E 00 00
  6871.                0010  E13E 0000 22D5 00 00
  6872.  
  6873. Abstract Objects Contained in Folder 5506 
  6874.  
  6875. The hexadecimal numbers are read as pairs, for example 8FD9 is actually D98F. 
  6876. Each pair is a pointer to an abstract object (or program) in the system. Here, 
  6877. we can see that the shredder (D98F) is referenced as the first item in the 
  6878. folder. To help you read this, it is useful to know that 
  6879.  
  6880.  5506 is the HOBJECT for the folder 
  6881.  D98F is the HOBJECT of a WPAbstract instance contained in this folder. 
  6882.  
  6883. File Associations 
  6884.  
  6885. There are two association mechanisms in the OS2.INI file; one for association 
  6886. filters and the other for association types. The format for association types 
  6887. works with the information stored in the settings EAs for each file. If a file 
  6888. doesn't have any EAs then the association is based on its full or partial file 
  6889. name or extension, using the association filter. 
  6890.  
  6891. There are two formats for the association filters, depending on whether the 
  6892. program runs in the WPS process or its own process. These trigger the 
  6893. appropriate program when you double click on a data file icon. The first 
  6894. filter, for any file with a .MET extension (metafile), shows that two programs 
  6895. can be used. The first program is described by an OS2.INI program reference 
  6896. (8134). The second program includes the pathname and file name (PICVIEW.EXE). 
  6897.  
  6898. The second filter, for a file with a .ICO extension (Icon), also provides a 
  6899. program path and file name (ICONEDIT.EXE). 
  6900.  
  6901. PMWP_ASSOC_FILTER
  6902.        *.MET
  6903.          D:\OS!2 2.0 DESKTOP\OS!2_System\Productivity\WPProgram:A8134.
  6904.          D:\OS2\APPS\WPPROGRAMFILE:FPICVIEW.EXE.
  6905.        *.ico
  6906.          D:\OS2\APPS\WPPROGRAMFILE:FICONEDIT.EXE
  6907.  
  6908. Association Filters for File Extensions 
  6909.  
  6910. The association type uses the same two formats as the filter; we can see the 
  6911. program reference 8134 again for metafiles and ICONEDIT.EXE for bitmaps in the 
  6912. figure below. File types are specified for each data file in its Settings view. 
  6913. We can see five file types below: 
  6914.  
  6915.  Metafile 
  6916.  Plain text 
  6917.  OS/2 command file 
  6918.  Executable 
  6919.  Bitmap. 
  6920.  
  6921. PMWP_ASSOC_TYPE
  6922.         Metafile
  6923.                 D:\OS!2 2.0 DESKTOP\OS!2_System\Productivity\WPProgram:A8134
  6924.         Plain Text
  6925.                 D:\OS!2 2.0 DESKTOP\OS!2_System\Productivity\WPProgram:A7660
  6926.         OS/2 Command File
  6927.                 D:\OS!2 2.0 DESKTOP\OS!2_System\Productivity\WPProgram:A7660
  6928.         Executable
  6929.                 0000  00                       .
  6930.         Bitmap
  6931.                 D:\OS2\APPS\WPPROGRAMFILE:FICONEDIT.EXE
  6932.  
  6933. Association Filters for File Types 
  6934.  
  6935. When a user double-clicks on an icon for an object belonging to any of these 
  6936. file types, the program associated with it is started. Note that there is no 
  6937. association for executable files since they themselves are started. The file 
  6938. name association takes precedence over the file type association if both are 
  6939. specified for an object. 
  6940.  
  6941.  
  6942. ΓòÉΓòÉΓòÉ 18.6. Multiple Instances of Objects ΓòÉΓòÉΓòÉ
  6943.  
  6944. Within the Workplace Shell there are many folder and printer icons; one for 
  6945. each folder or attached printer in the system. There are two issues here: When 
  6946. we see multiple printers icons, do they refer to the same printer or to 
  6947. different printers, and do they share the same code? 
  6948.  
  6949. Multiple copies of folders refer to different folders but they all share the 
  6950. same program. They are instances of the same folder class. Multiple copies of 
  6951. printers may look similar but may actually be instances of different printer 
  6952. classes. 
  6953.  
  6954. To understand this, you have to understand something about the structure of the 
  6955. Workplace Shell and the System Object Model (SOM) which it is built on. Through 
  6956. inheritance, the System Object Model provides folders, work areas and other 
  6957. types of container objects which share their common code so the programmer only 
  6958. has to code the differences. SOM allows multiple instances of each class to be 
  6959. created and manages the memory, pointers, etc. for each of them. It also, 
  6960. through inheritance, allows instances of different classes to be created which 
  6961. look the same and share a significant degree of common code. 
  6962.  
  6963. What happens when multiple instances of a data file are created depends on the 
  6964. technique used to create the object. If you perform a copy, then a new file and 
  6965. file EAs are created in the directory corresponding to the folder which the 
  6966. file was created in. The file name and all the other details are copied 
  6967. verbatim. Here, each copy is a new instance of the WPDataFile class and can be 
  6968. modified without affecting the original file. 
  6969.  
  6970. If you create the copies in the same directory as the original, however, the 
  6971. operating system settings determine what happens when you try to copy a file 
  6972. into a directory which already contains a file of that name. As a default, the 
  6973. WPS will add a suffix to the file name and icon descriptive text; for the first 
  6974. copy a "1" is added, for the second a "2", and so on. The same thing happens if 
  6975. you create a copy in a different directory but then drag it back into the 
  6976. original directory while the original file is still there. This mechanism 
  6977. prevents you from accidentally overwriting copies of your work, but it can be 
  6978. frustrating when you are trying to replace an out-of-date version of a file. 
  6979.  
  6980. You can also make multiple instances of the same file using the shadow copy 
  6981. facility. Here, the shadow copy is an abstract object, stored as a HOBJECT 
  6982. pointer in OS2.INI which points back to the original file. In both cases, we 
  6983. have multiple instances of icons, but what the icons represent are instances of 
  6984. different classes with different characteristics. Here, when you modify the 
  6985. copy you are also affecting the original file. 
  6986.  
  6987.  
  6988. ΓòÉΓòÉΓòÉ 18.7. Summary ΓòÉΓòÉΓòÉ
  6989.  
  6990. The Workplace Shell is implemented using the System Object Model. Many of the 
  6991. characteristics of the Workplace Shell, such as folders and icons, are 
  6992. implemented as System Object Model classes.  This method of implementation 
  6993. allows an application developer to use such classes and inherit characteristics 
  6994. and behaviors from them. 
  6995.  
  6996. The ability to inherit standard behaviors from existing object classes can 
  6997. significantly simplify the task of developing a new object class, since only 
  6998. the differing behaviors must be explicitly defined; all others may simply be 
  6999. inherited from the parent class. 
  7000.  
  7001. The WPS implementation also enables multiple instances of each class to be 
  7002. created, as well as multiple copies of any specific instance. WPS classes 
  7003. include data files, programs and shadow copies. Each class has its own methods 
  7004. for instantiating and storing objects of that class and use a variety of 
  7005. techniques for recording the attributes and data for each object. 
  7006.  
  7007. Table "Workplace Shell Object Persistence Summary" summarizes persistence in 
  7008. the Workplace Shell. 
  7009.  
  7010. A data file stores its data in files within a disk directory and its attributes 
  7011. in Extended Attributes (EAs) associated with that file. A folder stores its 
  7012. contents in a disk directory and its attributes in EAs associated with that 
  7013. directory. 
  7014.  
  7015. Program files are stored on disk but access to them via the WPS is controlled 
  7016. by pointers in the OS2.INI file. Shadow copies do not physically exist, they 
  7017. are simply pointers to the original data file which are held in the OS2.INI 
  7018. file. These pointers are also stored by folders in a section of the OS2.INI 
  7019. file. The position of their icons is held in the directory EAs for that folder. 
  7020.  
  7021.  
  7022. ΓòÉΓòÉΓòÉ 19. Using REXX in OS/2 V2.0 ΓòÉΓòÉΓòÉ
  7023.  
  7024. REXX provides access to several OS/2 APIs via the the RexxUtil functions which 
  7025. have been added to OS/2 V2.0. To use these new functions in a REXX program, 
  7026. SysLoadFuncs must be called to automatically load all RexxUtil functions as 
  7027. follows: 
  7028.  
  7029.    /* Rexx program that uses RexxUtil functions */
  7030.    call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
  7031.    call SysLoadFuncs
  7032.  
  7033. RexxUtil functions are prefixed with "Sys".  For a complete list of Sys* 
  7034. functions please refer to the OS/2 2.0 Programming Guide Volume II. In WPS 
  7035. development the following Sys* commands are most frequently used: 
  7036.  
  7037.  SysRegisterObjectClass 
  7038.  
  7039.  SysDeregisterObjectClass 
  7040.  
  7041.  SysCreateObject. 
  7042.  
  7043. The following syntax descriptions should help explain what these REXX functions 
  7044. do: 
  7045.  
  7046.  Function: SysRegisterObjectClass
  7047.  Purpose:         Register a new object class definition to the system.
  7048.  Syntax:  result = SysRegisterObjectClass(classname, modulename)
  7049.  
  7050.  classname        The name of the new object class.
  7051.  modulename       The name of the module containing the object definition.
  7052.  result           The return code from WinRegisterObjectClass.
  7053.                   This returns 1 (TRUE) if the class was registered
  7054.                   or 0 (FALSE) if the new class was not registered.
  7055.  
  7056.  
  7057.  Function: SysDeregisterObjectClass
  7058.  Purpose:         Deregister an object class definition from the system.
  7059.  Syntax:  result = SysDeregisterObjectClass(classname)
  7060.  
  7061.  classname        The name of the object class to deregister.
  7062.  result           The return code from WinDeregisterObjectClass.
  7063.                   This returns 1 (TRUE) if the class was deregistered
  7064.                   or 0 (FALSE) if the class was not deregistered.
  7065.  
  7066.  
  7067.  Function: SysCreateObject
  7068.  Purpose:         Create a new instance of an object class.
  7069.  Syntax:  result = SysCreateObject(classname, title, location <,setup>)
  7070.  classname        The name of the object class.
  7071.  title            The object title.
  7072.  location         The object location.  This can be specified as either a
  7073.                   descriptive path (for example,
  7074.                   OS/2 System Folder\System Configuration)
  7075.                   or a file system path (for example, C:\bin\mytools).
  7076.  setup            A WinCreateObject setup string.
  7077.  result           The return code from WinCreateObject.
  7078.                   This returns 1 (TRUE) if the object was created
  7079.                   or 0 (FALSE) if the object was not created.
  7080.  
  7081.  
  7082. ΓòÉΓòÉΓòÉ 20. CUA Conformance in the Workplace Shell ΓòÉΓòÉΓòÉ
  7083.  
  7084. Some differences exist between the CUA architecture and the Workplace Shell 
  7085. implementation in OS/2 V2.0. Some of these differences may force applications 
  7086. to diverge from the CUA architecture, either because of the effort required to 
  7087. override OS/2, or because of the negative impact to system consistency or 
  7088. customization if the CUA guidelines are followed. 
  7089.  
  7090. This is of particular importance for CUA Fundamental items, which provide the 
  7091. foundation for many of the enhancements to CUA described in the "CUA Vision" 
  7092. demonstration and video. Some of the discrepancies between OS/2 and CUA are 
  7093. beyond the control of an individual application; under these circumstances the 
  7094. application has no choice but to use the OS/2 conventions. 
  7095.  
  7096. However, in other situations it is quite easy for an application to comply with 
  7097. the CUA guidelines rather than following the example of OS/2. To aid in this 
  7098. determination, an assessment of each OS/2 item has been made, and the results 
  7099. are summarized in Table "Fundamental Items". 
  7100.  
  7101. The same assessment has been made for non-fundamental (Recommended) items in 
  7102. Table "Recommended Items". Again, where the OS/2 implementation does not force 
  7103. an application to differ from the CUA architecture, the developer might simply 
  7104. use the OS/2 Workplace Shell as an example. In such cases the product could 
  7105. just as easily follow the CUA recommendations and should do so for improved 
  7106. consistency and ease of use. 
  7107.  
  7108. OS/2 Version 2.0 - Volume 4:  Application Development provides several examples 
  7109. of how to modify WPS objects and their behaviors, including subclassing folders 
  7110. and changing their icon description. These examples should prove useful to 
  7111. programmers who wish to implement CUA-conforming behaviors in their OS/2 V2.0 
  7112. applications. 
  7113.  
  7114. The relevant page in the IBM Systems Application Architecture CUA Advanced 
  7115. Interface Design Reference is indicated in the Reference Page column in both 
  7116. tables, together with an indication of which entry on that page is being 
  7117. applied. Each page of the IBM Systems Application Architecture CUA Advanced 
  7118. Interface Design Reference contains a definition, a "When to use" and a 
  7119. "Guidelines" section. The numbering scheme used refers to the item number 
  7120. within a section; W is "When to use" and G is "Guidelines", so 216/G2 is read 
  7121. as Page 216, second item in the Guidelines section. 
  7122.  
  7123.  
  7124. ΓòÉΓòÉΓòÉ 20.1. Other Items ΓòÉΓòÉΓòÉ
  7125.  
  7126. In a shell with as many objects as the Workplace Shell, it is almost inevitable 
  7127. that some of the windows may contain elements which do not comply with CUA 
  7128. guidelines. Application developers should not assume that these elements and 
  7129. their behaviors are sanctioned by CUA; they should continue to implement 
  7130. objects and behaviors which conform to the rules laid out in the IBM Systems 
  7131. Application Architecture CUA Advanced Interface Design Reference. 
  7132.  
  7133. This section provides a few examples of non-compliant behaviors in the 
  7134. following areas: 
  7135.  
  7136.  Navigation 
  7137.  Emphasis 
  7138.  Mnemonics 
  7139.  Push buttons 
  7140.  Miscellaneous. 
  7141.  
  7142.  
  7143. ΓòÉΓòÉΓòÉ 20.1.1. Navigation ΓòÉΓòÉΓòÉ
  7144.  
  7145. Notebook                 Up Arrow key moves the cursor from the notebook page 
  7146.                          to notebook tab 
  7147.  
  7148. Glossary Settings        On Properties page, Tab key moves the cursor within 
  7149.                          push button field 
  7150.  
  7151. Mouse Settings           On Mappings page, Arrow key moves the cursor between 
  7152.                          radio button field and checkbox field. 
  7153.  
  7154.  
  7155. ΓòÉΓòÉΓòÉ 20.1.2. Emphasis ΓòÉΓòÉΓòÉ
  7156.  
  7157. Dialog Editor            Help menu choice and all the choices in the pull-down 
  7158.                          are displayed with unavailable-state emphasis 
  7159.  
  7160. Clipboard Viewer         In the "File" menu, Import and Export choices are 
  7161.                          never available yet they are displayed with 
  7162.                          unavailable-state emphasis 
  7163.  
  7164. Font Palette             Target emphasis is not displayed during direct 
  7165.                          manipulation operations. 
  7166.  
  7167.  
  7168. ΓòÉΓòÉΓòÉ 20.1.3. Mnemonics ΓòÉΓòÉΓòÉ
  7169.  
  7170. Shredder            Mnemonic is missing from Refresh choice in pop-up menu 
  7171.  
  7172. Format              In Progress window, mnemonic is missing from Stop push 
  7173.                     button 
  7174.  
  7175. Menu Settings       Incorrect terminology and no mnemonic for predefined push 
  7176.                     button 
  7177.  
  7178. DOS Settings        Mnemonics are incorrectly assigned to Help and Cancel push 
  7179.                     buttons. 
  7180.  
  7181.  
  7182. ΓòÉΓòÉΓòÉ 20.1.4. Push Buttons ΓòÉΓòÉΓòÉ
  7183.  
  7184. Glossary List            Push buttons are not justified from the left 
  7185.  
  7186. Format                   In Progress window, Close push button is missing 
  7187.  
  7188. Device Driver Install    Exit push button performs Close function. 
  7189.  
  7190.  
  7191. ΓòÉΓòÉΓòÉ 20.1.5. Miscellaneous ΓòÉΓòÉΓòÉ
  7192.  
  7193. Edit Font                Pressing Enter key does not cause default action to 
  7194.                          begin in Action window 
  7195.  
  7196. Notebook                 Cursor is not visible on notebook page when focus is 
  7197.                          moved from tab to page using the keyboard 
  7198.  
  7199. System Error             Message window is missing the system menu icon and 
  7200.                          pull-down 
  7201.  
  7202. Shell                    Alt+Tab key switches between unassociated windows 
  7203.  
  7204. Clipboard Viewer         Exit is redundant in the File menu; Close in the 
  7205.                          system menu performs this same function 
  7206.  
  7207.  
  7208. ΓòÉΓòÉΓòÉ 21. Glossary ΓòÉΓòÉΓòÉ
  7209.  
  7210.  
  7211. ΓòÉΓòÉΓòÉ 21.1. API ΓòÉΓòÉΓòÉ
  7212.  
  7213. API 
  7214.  
  7215. Application Programming Interface; term used to describe the set of functions 
  7216. by which an application may gain access to operating system services. 
  7217.  
  7218.  
  7219. ΓòÉΓòÉΓòÉ 21.2. application-controlled viewport ΓòÉΓòÉΓòÉ
  7220.  
  7221. application-controlled viewport 
  7222.  
  7223. Viewport within a help window or online document window, where the display of 
  7224. information within that viewport is controlled by an application, which is 
  7225. specified by the developer of the source information.  Application-controlled 
  7226. viewports may be used to display image, video or other types of information 
  7227. under the control of the Information Presentation Facility.  See also 
  7228. IPF-controlled viewport. 
  7229.  
  7230.  
  7231. ΓòÉΓòÉΓòÉ 21.3. bit ΓòÉΓòÉΓòÉ
  7232.  
  7233. bit 
  7234.  
  7235. A binary digit, which may be either zero or one.  Bits are represented within a 
  7236. computing device by the presence or absence of an electrical or magnetic pulse 
  7237. at a particular point, indicating a one or a zero respectively. 
  7238.  
  7239.  
  7240. ΓòÉΓòÉΓòÉ 21.4. Boot Manager ΓòÉΓòÉΓòÉ
  7241.  
  7242. Boot Manager 
  7243.  
  7244. Boot Manager; feature of OS/2 Version 2.0 which allows multiple partitions to 
  7245. exist on fixed disks in the same machine, with a separate operating system on 
  7246. each partition.  At boot time, the user may select the desired operating system 
  7247. with which to start the machine. 
  7248.  
  7249.  
  7250. ΓòÉΓòÉΓòÉ 21.5. byte ΓòÉΓòÉΓòÉ
  7251.  
  7252. byte 
  7253.  
  7254. A logical data unit composed of eight binary digits (bits). 
  7255.  
  7256.  
  7257. ΓòÉΓòÉΓòÉ 21.6. Common User Access ΓòÉΓòÉΓòÉ
  7258.  
  7259. Common User Access 
  7260.  
  7261. Component of IBM Systems Application Architecture, which defines standards and 
  7262. guidelines for user interfaces in both character-based and GUI applications. 
  7263.  
  7264.  
  7265. ΓòÉΓòÉΓòÉ 21.7. compatability region ΓòÉΓòÉΓòÉ
  7266.  
  7267. compatability region 
  7268.  
  7269. In the OS/2 Version 2.0 flat memory model, the address region below 512MB, 
  7270. which may be addressed by a 16-bit application using the 16:16 addressing 
  7271. scheme and tiled local descriptor tables.  Under OS/2 Version 2.0, this region 
  7272. is equivalent in size to the process address space. 
  7273.  
  7274.  
  7275. ΓòÉΓòÉΓòÉ 21.8. container object ΓòÉΓòÉΓòÉ
  7276.  
  7277. container object 
  7278.  
  7279. An object in the SAA CUA Workplace Environment which allows logical grouping of 
  7280. objects in a manner determined by the user.  A container object may contain 
  7281. work items, physical devices and/or other container objects.  A new class of 
  7282. control window is implemented under OS/2 Version 2.0 to facilitate the creation 
  7283. and manipulation of containers. 
  7284.  
  7285.  
  7286. ΓòÉΓòÉΓòÉ 21.9. context menu ΓòÉΓòÉΓòÉ
  7287.  
  7288. context menu 
  7289.  
  7290. A menu associated with an object or view, which appears when the user moves the 
  7291. mouse cursor over the object or view and clicks mouse button 1.  The context 
  7292. menu allows actions to be performed upon the object or view, in a similar 
  7293. manner to that available with a menu bar under OS/2 Version 1.3. 
  7294.  
  7295.  
  7296. ΓòÉΓòÉΓòÉ 21.10. CUA ΓòÉΓòÉΓòÉ
  7297.  
  7298. CUA 
  7299.  
  7300. See Common User Access. 
  7301.  
  7302.  
  7303. ΓòÉΓòÉΓòÉ 21.11. DDE ΓòÉΓòÉΓòÉ
  7304.  
  7305. DDE 
  7306.  
  7307. Dynamic Data Exchange; interprocess communication protocol used by applications 
  7308. to define dynamic links.  Information updated in one application is 
  7309. automatically reflected in other applications linked to the first application 
  7310. via DDE. 
  7311.  
  7312.  
  7313. ΓòÉΓòÉΓòÉ 21.12. desktop ΓòÉΓòÉΓòÉ
  7314.  
  7315. desktop 
  7316.  
  7317. In the context of the SAA CUA Workplace Environment and the Workplace Shell, 
  7318. the background of the computer display, which represents an electronic analogy 
  7319. of the user's work environment.  Icons, representing objects to be manipulated, 
  7320. are moved on the desktop in order to perform work tasks, in a style known as 
  7321. direct manipulation. 
  7322.  
  7323.  
  7324. ΓòÉΓòÉΓòÉ 21.13. direct manipulation ΓòÉΓòÉΓòÉ
  7325.  
  7326. direct manipulation 
  7327.  
  7328. Term used to describe a style of interface whereby icons representing objects 
  7329. or work items are moved on the desktop to perform operations by dropping the 
  7330. icons over other icons representing physcial devices such as printers or 
  7331. conceptual devices such as an "out basket" in an electronic mail system.  Also 
  7332. known as drag and drop manipulation. 
  7333.  
  7334.  
  7335. ΓòÉΓòÉΓòÉ 21.14. DLL ΓòÉΓòÉΓòÉ
  7336.  
  7337. DLL 
  7338.  
  7339. Dynamic link library; application module containing routines and/or resources, 
  7340. which is dynamically linked with its parent application at load time or runtime 
  7341. rather than during the linkage editing process. The use of DLLs enables 
  7342. decoupling of application routines and resources from the parent program, 
  7343. enhancing code independence, facilitating maintenance and reducing resident 
  7344. memory consumption. 
  7345.  
  7346.  
  7347. ΓòÉΓòÉΓòÉ 21.15. drag and drop manipulation ΓòÉΓòÉΓòÉ
  7348.  
  7349. drag and drop manipulation 
  7350.  
  7351. See direct manipulation. 
  7352.  
  7353.  
  7354. ΓòÉΓòÉΓòÉ 21.16. Extended Attributes ΓòÉΓòÉΓòÉ
  7355.  
  7356. Extended Attributes 
  7357.  
  7358. Information which may be associated with a file under OS/2 Version 1.2 or above 
  7359. (including Version 2.0), to indicate various properties of that file.  Extended 
  7360. attributes are available with both the FAT and HPFS file systems.  An 
  7361. application may define extended attributes for files which it creates, and may 
  7362. update the extended attributes of files upon which it operates.  A number of 
  7363. standard extended attributes are defined by the operating system for 
  7364. commonly-used information. 
  7365.  
  7366.  
  7367. ΓòÉΓòÉΓòÉ 21.17. FAT ΓòÉΓòÉΓòÉ
  7368.  
  7369. FAT 
  7370.  
  7371. File Allocation Table; term used to describe the file system implemented by DOS 
  7372. and OS/2.  This file system uses a file allocation table to contain the 
  7373. physical sector addresses of all files on the disk.  The FAT file system is 
  7374. supported by OS/2 Version 2.0, along with the newer HPFS and other installable 
  7375. file systems. 
  7376.  
  7377.  
  7378. ΓòÉΓòÉΓòÉ 21.18. flat memory model ΓòÉΓòÉΓòÉ
  7379.  
  7380. flat memory model 
  7381.  
  7382. Conceptual view of real memory implemented by OS/2 Version 2.0, where the 
  7383. operating system regards memory as a single linear address range of up to 4GB. 
  7384.  
  7385.  
  7386. ΓòÉΓòÉΓòÉ 21.19. folder ΓòÉΓòÉΓòÉ
  7387.  
  7388. folder 
  7389.  
  7390. See container object. 
  7391.  
  7392.  
  7393. ΓòÉΓòÉΓòÉ 21.20. general protection exception ΓòÉΓòÉΓòÉ
  7394.  
  7395. general protection exception 
  7396.  
  7397. Operating system error which occurs when an application attempts to access 
  7398. memory in a page which has not been allocated to that process. OS/2 Version 2.0 
  7399. allows an application to trap a general protection exception using an exception 
  7400. handler registered with the operating system.  If an exception handler is not 
  7401. registered, the operating system will terminate the application as a result of 
  7402. a general protection exception.  Also known as a Trap 000D. 
  7403.  
  7404.  
  7405. ΓòÉΓòÉΓòÉ 21.21. guard page ΓòÉΓòÉΓòÉ
  7406.  
  7407. guard page 
  7408.  
  7409. Page within a memory object, for which the PAG_GUARD attribute has been 
  7410. specified.  Any attempt by the application to reference memory within the guard 
  7411. page results in a guard page exception. 
  7412.  
  7413.  
  7414. ΓòÉΓòÉΓòÉ 21.22. guard page exception ΓòÉΓòÉΓòÉ
  7415.  
  7416. guard page exception 
  7417.  
  7418. Operating system warning condition which occurs when an application accesses 
  7419. memory within a page which has been declared as a guard page. This exception 
  7420. may be trapped using an exception handler registered by the application in 
  7421. order to handle such occurrances.  The typical processing performed by the 
  7422. exception handler is to commit more memory within the memory object.  If an 
  7423. exception handler is not registered, the operating system's default handler 
  7424. commits the next available page within the memory object and sets its attribute 
  7425. to PAG_GUARD. 
  7426.  
  7427.  
  7428. ΓòÉΓòÉΓòÉ 21.23. GUI ΓòÉΓòÉΓòÉ
  7429.  
  7430. GUI 
  7431.  
  7432. Graphical User Interface; term used to describe a user interface which 
  7433. typically uses windows and graphical representation to allow an application to 
  7434. interact with the end user.  Examples of such interfaces include OS/2 
  7435. Presentation Manager and Microsoft Windows. 
  7436.  
  7437.  
  7438. ΓòÉΓòÉΓòÉ 21.24. HPFS ΓòÉΓòÉΓòÉ
  7439.  
  7440. HPFS 
  7441.  
  7442. High Performance File System; file system first implemented under OS/2 Version 
  7443. 1.2, offering enhanced performance over the original FAT file system 
  7444. implemented in DOS and prior versions of OS/2.  HPFS is an optional 
  7445. installation item under OS/2 Version 2.0; the FAT system may also be used to 
  7446. retain compatibility with DOS. 
  7447.  
  7448.  
  7449. ΓòÉΓòÉΓòÉ 21.25. hypergraphics ΓòÉΓòÉΓòÉ
  7450.  
  7451. hypergraphics 
  7452.  
  7453. Under the Information Presentation Facility, a portion of a bitmap displayed in 
  7454. a help panel or online document, which may be selected by the end user. 
  7455. Selecting such an item causes an event to occur, such as the display of another 
  7456. help panel, a popup window, the dispatch of a message to the parent application 
  7457. or the start of a new application.  See also hypertext. 
  7458.  
  7459.  
  7460. ΓòÉΓòÉΓòÉ 21.26. hypertext ΓòÉΓòÉΓòÉ
  7461.  
  7462. hypertext 
  7463.  
  7464. In the Information Presentation Facility, a word or phrase in a help panel or 
  7465. online document, which may be selected by the end user.  Selecting such an item 
  7466. causes an event to occur, such as the display of another help panel, a context 
  7467. menu, the dispatch of a message to the parent application or the start of a new 
  7468. application.  See also hypergraphics. 
  7469.  
  7470.  
  7471. ΓòÉΓòÉΓòÉ 21.27. icon ΓòÉΓòÉΓòÉ
  7472.  
  7473. icon 
  7474.  
  7475. A graphical image on a computer display, which represents an object such as a 
  7476. file or a physical device such as a printer or plotter.  In the SAA CUA 
  7477. Workplace Model, icons are used to electronically represent objects in the 
  7478. user's work environment, which are manipulated by moving icons on the desktop. 
  7479.  
  7480.  
  7481. ΓòÉΓòÉΓòÉ 21.28. Information Presentation Facility ΓòÉΓòÉΓòÉ
  7482.  
  7483. Information Presentation Facility 
  7484.  
  7485. Facility provided by OS/2 Presentation Manager which allows applications to 
  7486. create embeddded, context-sensitive help windows for their windows and dialog 
  7487. boxes.  Features include built-in indexing and hypertext.  Under OS/2 Version 
  7488. 2.0, the Information Presentation Facility is enhanced to include the ability 
  7489. to display hypergraphics. 
  7490.  
  7491.  
  7492. ΓòÉΓòÉΓòÉ 21.29. IPF ΓòÉΓòÉΓòÉ
  7493.  
  7494. IPF 
  7495.  
  7496. See Information Presentation Facility. 
  7497.  
  7498.  
  7499. ΓòÉΓòÉΓòÉ 21.30. IPF-controlled viewport ΓòÉΓòÉΓòÉ
  7500.  
  7501. IPF-controlled viewport 
  7502.  
  7503. Viewport within a help window or online document window, where the formatting 
  7504. and display of information within that window is controlled by the Information 
  7505. Presentation Facility.  This is the default case for information displayed 
  7506. using the Information Presentation Facility.  See also application-controlled 
  7507. viewport. 
  7508.  
  7509.  
  7510. ΓòÉΓòÉΓòÉ 21.31. Initial Program Load ΓòÉΓòÉΓòÉ
  7511.  
  7512. Initial Program Load 
  7513.  
  7514. Term used to describe the process of loading a program (operating system) into 
  7515. memory when a machine is switched on.  Also known as "boot", a reference to 
  7516. "lifting oneself up by ones bootstraps". 
  7517.  
  7518.  
  7519. ΓòÉΓòÉΓòÉ 21.32. IPL ΓòÉΓòÉΓòÉ
  7520.  
  7521. IPL 
  7522.  
  7523. See Initial Program Load. 
  7524.  
  7525.  
  7526. ΓòÉΓòÉΓòÉ 21.33. MB ΓòÉΓòÉΓòÉ
  7527.  
  7528. MB 
  7529.  
  7530. Megabyte; 1024 kilobytes, or 1024 x 1024 bytes. 
  7531.  
  7532.  
  7533. ΓòÉΓòÉΓòÉ 21.34. memory object ΓòÉΓòÉΓòÉ
  7534.  
  7535. memory object 
  7536.  
  7537. Logical unit of memory requested by an application, which forms the granular 
  7538. unit of memory manipulation from the application viewpoint. A memory object may 
  7539. be up to 512MB in size under OS/2 Version 2.0. 
  7540.  
  7541.  
  7542. ΓòÉΓòÉΓòÉ 21.35. Multiple Virtual DOS Machines ΓòÉΓòÉΓòÉ
  7543.  
  7544. Multiple Virtual DOS Machines 
  7545.  
  7546. Feature of OS/2 Version 2.0 which enables multiple DOS applications to execute 
  7547. concurrently in fullscreen or windowed mode under OS/2 Version 2.0, in 
  7548. conjunction with other 16-bit or 32-bit applications, with full pre-emptive 
  7549. multitasking and memory protection between tasks.  See also virtual DOS 
  7550. machine. 
  7551.  
  7552.  
  7553. ΓòÉΓòÉΓòÉ 21.36. MVDM ΓòÉΓòÉΓòÉ
  7554.  
  7555. MVDM 
  7556.  
  7557. See Multiple Virtual DOS Machines. 
  7558.  
  7559.  
  7560. ΓòÉΓòÉΓòÉ 21.37. notebook control ΓòÉΓòÉΓòÉ
  7561.  
  7562. notebook control 
  7563.  
  7564. New class of control window implemented under OS/2 Version 2.0, which provides 
  7565. for the display and navigation of complex user dialogs involving multiple 
  7566. related dialog boxes. 
  7567.  
  7568.  
  7569. ΓòÉΓòÉΓòÉ 21.38. NULL ΓòÉΓòÉΓòÉ
  7570.  
  7571. NULL 
  7572.  
  7573. A binary zero.  In C programming terms, NULL is typically used     to refer to 
  7574. a pointer which is set to the binary zero value. 
  7575.  
  7576.  
  7577. ΓòÉΓòÉΓòÉ 21.39. object ΓòÉΓòÉΓòÉ
  7578.  
  7579. object 
  7580.  
  7581. A physical entity such as a printer or fixed disk device, or a logical entity 
  7582. such as file or document, which is manipulated within the Workplace Shell under 
  7583. OS/2 Version 2.0, in order to perform a work task.  Objects are typically 
  7584. represented within the Workplace Shell using icons. 
  7585.  
  7586.  
  7587. ΓòÉΓòÉΓòÉ 21.40. page ΓòÉΓòÉΓòÉ
  7588.  
  7589. page 
  7590.  
  7591. Granular unit for memory management using the 80386 and 80486 processors.  A 
  7592. page is a 4KB contiguous unit of memory, which the processor manipulates as a 
  7593. single entity for the purpose of memory manipulation and swapping. 
  7594.  
  7595.  
  7596. ΓòÉΓòÉΓòÉ 21.41. page fault exception ΓòÉΓòÉΓòÉ
  7597.  
  7598. page fault exception 
  7599.  
  7600. Operating system error which occurs when an application attempts to access 
  7601. memory which has been allocated but not committed.  This exception may be 
  7602. trapped by an application using an exception handler registered with the 
  7603. operating system.  If an exception handler is not registered, the operating 
  7604. system's default handler will terminate the application as a result of a page 
  7605. fault exception.  Also known as a Trap 000E. 
  7606.  
  7607.  
  7608. ΓòÉΓòÉΓòÉ 21.42. pop-up menu ΓòÉΓòÉΓòÉ
  7609.  
  7610. pop-up menu 
  7611.  
  7612. See context menu. 
  7613.  
  7614.  
  7615. ΓòÉΓòÉΓòÉ 21.43. printer object ΓòÉΓòÉΓòÉ
  7616.  
  7617. printer object 
  7618.  
  7619. In the Workplace Shell, an icon on the desktop which represents a printer 
  7620. device to which output may be directed.  Objects such as files or documents are 
  7621. printed by moving their icons over the printer object and releasing the mouse 
  7622. button, thereby dropping the object onto the printer. 
  7623.  
  7624.  
  7625. ΓòÉΓòÉΓòÉ 21.44. protected mode ΓòÉΓòÉΓòÉ
  7626.  
  7627. protected mode 
  7628.  
  7629. Mode of operation for the Intel 80286 and 80386/80486 processors, whereby the 
  7630. address space is expanded to 16MB (80286) or 4GB (80386/80486), and memory 
  7631. references are translated via segment selector and offset, enabling full memory 
  7632. protection between processes executing in the system.  With the 80386 and 
  7633. 80486, paging is available in protected mode. 
  7634.  
  7635.  
  7636. ΓòÉΓòÉΓòÉ 21.45. RAM ΓòÉΓòÉΓòÉ
  7637.  
  7638. RAM 
  7639.  
  7640. Random Access Memory; term used to describe memory which may be dynamically 
  7641. read and written by a processor or other device during system operatons.  RAM 
  7642. is typically used to store program instructions and data which not being 
  7643. operated upon by the processor at the current moment in time, but which are 
  7644. required for the logical unit of work currently being carried out. 
  7645.  
  7646.  
  7647. ΓòÉΓòÉΓòÉ 21.46. real mode ΓòÉΓòÉΓòÉ
  7648.  
  7649. real mode 
  7650.  
  7651. Default mode of operation for the Intel 80286 and 80386/80486 processors, and 
  7652. the only mode of operation for the 8086 processor.  In real mode, the processor 
  7653. acts as a 16-bit device, its physical memory address space is limited to 1MB, 
  7654. and memory references translate directly to physical addresses.  With the 80386 
  7655. and 80486, paging is not supported in real mode. 
  7656.  
  7657.  
  7658. ΓòÉΓòÉΓòÉ 21.47. reference link ΓòÉΓòÉΓòÉ
  7659.  
  7660. reference link 
  7661.  
  7662. Mechanism by which a shadow object is associated with the "real" object to 
  7663. which it pertains.  See also shadow object. 
  7664.  
  7665.  
  7666. ΓòÉΓòÉΓòÉ 21.48. ROM ΓòÉΓòÉΓòÉ
  7667.  
  7668. ROM 
  7669.  
  7670. Read-Only Memory; term used to describe memory which may be read, but not 
  7671. written to, during system operations.  ROM is typically used to store basic 
  7672. hardware initialization instructions, BIOS or self-testing code, which is 
  7673. required to be available prior to accessing the disk subsystem. 
  7674.  
  7675.  
  7676. ΓòÉΓòÉΓòÉ 21.49. SAA ΓòÉΓòÉΓòÉ
  7677.  
  7678. SAA 
  7679.  
  7680. See Systems Application Architecture. 
  7681.  
  7682.  
  7683. ΓòÉΓòÉΓòÉ 21.50. segment ΓòÉΓòÉΓòÉ
  7684.  
  7685. segment 
  7686.  
  7687. Unit of memory addressable by the Intel 80x86 processors.  With the 8086 and 
  7688. 80286 processors, a sgement may be from 16 bytes to 64KB in size.  With the 
  7689. 80386 and 80486 processors, a segment may be up to 4GB in size. 
  7690.  
  7691.  
  7692. ΓòÉΓòÉΓòÉ 21.51. segment selector ΓòÉΓòÉΓòÉ
  7693.  
  7694. segment selector 
  7695.  
  7696. Field which specifies the base address of a memory segment when using the 
  7697. segmented memory model.  The selector is 16 bits in length on an 80286 
  7698. processor, and 32 bits in length on an 80386 or 80486 processor. 
  7699.  
  7700.  
  7701. ΓòÉΓòÉΓòÉ 21.52. semaphore ΓòÉΓòÉΓòÉ
  7702.  
  7703. semaphore 
  7704.  
  7705. Construct used under OS/2 Version 2.0. and previous versions of OS/2 to enable 
  7706. synchronization between processes and between threads in the same process. 
  7707. OS/2 Version 2.0 provides enhanced semaphore facilities over previous versions. 
  7708.  
  7709.  
  7710. ΓòÉΓòÉΓòÉ 21.53. service layer ΓòÉΓòÉΓòÉ
  7711.  
  7712. service layer 
  7713.  
  7714. Executable code which performs the operating system function requested by an 
  7715. application using an API. 
  7716.  
  7717.  
  7718. ΓòÉΓòÉΓòÉ 21.54. shadow object ΓòÉΓòÉΓòÉ
  7719.  
  7720. shadow object 
  7721.  
  7722. An object on the desktop or in a folder, which actually references another 
  7723. object.  Shadow objects allow an object such as a device to be defined in 
  7724. multiple locations.  For example, a high-quality printer object may be defined 
  7725. in both a Word Processing folder and a Spreadsheets folder.  A shadow object is 
  7726. associated with a "real" object via a reference link. 
  7727.  
  7728.  
  7729. ΓòÉΓòÉΓòÉ 21.55. shredder object ΓòÉΓòÉΓòÉ
  7730.  
  7731. shredder object 
  7732.  
  7733. Object on the Presentation Manager desktop which allows an object such as a 
  7734. file or document to be erased from the system, by dropping the object onto the 
  7735. shredder object's icon. 
  7736.  
  7737.  
  7738. ΓòÉΓòÉΓòÉ 21.56. slider control ΓòÉΓòÉΓòÉ
  7739.  
  7740. slider control 
  7741.  
  7742. New class of control window implemented under OS/2 Version 2.0, for use when a 
  7743. particular property or value should be set by analogue rather than exact 
  7744. digital means. 
  7745.  
  7746.  
  7747. ΓòÉΓòÉΓòÉ 21.57. SOM ΓòÉΓòÉΓòÉ
  7748.  
  7749. SOM 
  7750.  
  7751. See System Object Model. 
  7752.  
  7753.  
  7754. ΓòÉΓòÉΓòÉ 21.58. sparse object ΓòÉΓòÉΓòÉ
  7755.  
  7756. sparse object 
  7757.  
  7758. Memory object for which a linear address range has been reserved, but for which 
  7759. no physical memory has yet been committed.  This capability is used to reserve 
  7760. storage in the process address space for use by an application, without causing 
  7761. an adverse impact on system performance by requesting large amounts of physical 
  7762. memory. 
  7763.  
  7764.  
  7765. ΓòÉΓòÉΓòÉ 21.59. Systems Application Architecture ΓòÉΓòÉΓòÉ
  7766.  
  7767. Systems Application Architecture 
  7768.  
  7769. Set of rules, standards and guidelines introduced by IBM in 1987 to facilitate 
  7770. ease-of-use of applications, and portability between different operating system 
  7771. environments.  Systems Application Architecture consists of three components; 
  7772. Common User Access, Common Programming Interfaces and Common Communications 
  7773. Support. 
  7774.  
  7775.  
  7776. ΓòÉΓòÉΓòÉ 21.60. System Object Model ΓòÉΓòÉΓòÉ
  7777.  
  7778. System Object Model 
  7779.  
  7780. Language-independent, object-oriented mechanism in which the Workplace Shell is 
  7781. written. It consists of a specification for language-independent message 
  7782. passing and inheritance for objects, some base classes from which the WPS class 
  7783. hierarchy is derived, and language bindings for C. 
  7784.  
  7785.  
  7786. ΓòÉΓòÉΓòÉ 21.61. thunk ΓòÉΓòÉΓòÉ
  7787.  
  7788. thunk 
  7789.  
  7790. Term used to describe a routine which performs address conversion, stack and 
  7791. structure realignment, etc.  Thunking is used to pass control between 16-bit 
  7792. and 32-bit application modules. 
  7793.  
  7794.  
  7795. ΓòÉΓòÉΓòÉ 21.62. Trap 000D ΓòÉΓòÉΓòÉ
  7796.  
  7797. Trap 000D 
  7798.  
  7799. See general protection exception. 
  7800.  
  7801.  
  7802. ΓòÉΓòÉΓòÉ 21.63. Trap 000E ΓòÉΓòÉΓòÉ
  7803.  
  7804. Trap 000E 
  7805.  
  7806. See page fault exception. 
  7807.  
  7808.  
  7809. ΓòÉΓòÉΓòÉ 21.64. value set ΓòÉΓòÉΓòÉ
  7810.  
  7811. value set 
  7812.  
  7813. New class of control window implemented under OS/2 Version 2.0, for use when 
  7814. selecting an item from a finite set of mutually exclusive choices. Similar in 
  7815. function to a radio button, but has the added flexibility of being able to 
  7816. display graphical items such as color patches, icons or bitmaps. 
  7817.  
  7818.  
  7819. ΓòÉΓòÉΓòÉ 21.65. view ΓòÉΓòÉΓòÉ
  7820.  
  7821. view 
  7822.  
  7823. Particular visual representation of an object under the Workplace Shell.  An 
  7824. object may have several available views; for example, and icon view depicts the 
  7825. objects as an icon, whereas a settings view enables the user to set properties 
  7826. and define the appearance of other views. 
  7827.  
  7828.  
  7829. ΓòÉΓòÉΓòÉ 21.66. viewport ΓòÉΓòÉΓòÉ
  7830.  
  7831. viewport 
  7832.  
  7833. Under the Information Presentation Facility, a portion of a help window or 
  7834. online document window which may be separately manipulated.  The use of 
  7835. multiple viewports in a window enables the display or different types of 
  7836. information in the same window, with separate formatting and scrolling. 
  7837. Viewports may be either simple or complex, and may be IPF-controlled or 
  7838. application-controlled. 
  7839.  
  7840.  
  7841. ΓòÉΓòÉΓòÉ 21.67. VDM ΓòÉΓòÉΓòÉ
  7842.  
  7843. VDM 
  7844.  
  7845. See Virtual DOS Machine. 
  7846.  
  7847.  
  7848. ΓòÉΓòÉΓòÉ 21.68. Virtual DOS Machine ΓòÉΓòÉΓòÉ
  7849.  
  7850. Virtual DOS Machine 
  7851.  
  7852. A protected mode process under OS/2 Version 2.0 which emulates a DOS operating 
  7853. system environment, such that DOS applications executing within the virtual 
  7854. machine operate exactly as if they were running under DOS. virtual DOS machines 
  7855. support both text and graphics applications, and make use of the virtual 8086 
  7856. mode of the 80386 and 80486 processors. 
  7857.  
  7858.  
  7859. ΓòÉΓòÉΓòÉ 21.69. windows ΓòÉΓòÉΓòÉ
  7860.  
  7861. windows 
  7862.  
  7863. An area of the screen with visible boundaries within which information is 
  7864. displayed.  A window can be smaller than or the same size as the screen. 
  7865. Windows can appear to overlap on the screen. 
  7866.  
  7867.  
  7868. ΓòÉΓòÉΓòÉ 21.70. Workplace Environment ΓòÉΓòÉΓòÉ
  7869.  
  7870. Workplace Environment 
  7871.  
  7872. User interface model for GUI systems under IBM 1991 Systems Application 
  7873. Architecture Common User Access.  The Workplace Environment defines guidelines 
  7874. for an interface where icons are manipulated using a mouse or keyboard, to 
  7875. perform work tasks electronically in a way analagous to that in which they 
  7876. would be performed manually.  Such an interface facilitates user training and 
  7877. allows greater productivity through its intuitive nature. 
  7878.  
  7879.  
  7880. ΓòÉΓòÉΓòÉ 21.71. Workplace Shell ΓòÉΓòÉΓòÉ
  7881.  
  7882. Workplace Shell 
  7883.  
  7884. Object-oriented user shell implemented by Presentation Manager in OS/2 Version 
  7885. 2.0.  The Workplace Shell uses icons to represent objects such as files or 
  7886. devices, and allows the user to perform work tasks by directly manipulating 
  7887. these icons on the desktop with the mouse or keyboard. 
  7888.  
  7889.  
  7890. ΓòÉΓòÉΓòÉ 21.72. WPS ΓòÉΓòÉΓòÉ
  7891.  
  7892. WPS 
  7893.  
  7894. See Workplace Shell. 
  7895.  
  7896.  
  7897. ΓòÉΓòÉΓòÉ 21.73. 0:32 ΓòÉΓòÉΓòÉ
  7898.  
  7899. 0:32 
  7900.  
  7901. Term used to describe the addressing scheme used for the 32-bit flat memory 
  7902. model, where a memory address is expressed as a 32-bit offset within the linear 
  7903. address range. 
  7904.  
  7905.  
  7906. ΓòÉΓòÉΓòÉ 21.74. 16:16 ΓòÉΓòÉΓòÉ
  7907.  
  7908. 16:16 
  7909.  
  7910. Term used to describe the addressing scheme used for the 16-bit segmented 
  7911. memory model, where a memory address is expressed as a 16-bit segment selector, 
  7912. and a 16-bit offset within that segment. 
  7913.  
  7914.  
  7915. ΓòÉΓòÉΓòÉ 21.75. 16-bit ΓòÉΓòÉΓòÉ
  7916.  
  7917. 16-bit 
  7918.  
  7919. Term used to describe an application which uses the 16:16 addressing scheme 
  7920. implemented under DOS and previous versions of OS/2.  In fact, such 
  7921. applications use a 24-bit address since the segment selector and offset are 
  7922. normally overlapped.  Such applicaitions typically use the 16-bit instruction 
  7923. set implemented under the Intel 80286 processor. 
  7924.  
  7925.  
  7926. ΓòÉΓòÉΓòÉ 21.76. 32-bit ΓòÉΓòÉΓòÉ
  7927.  
  7928. 32-bit 
  7929.  
  7930. Term used to describe an application which uses the 0:32 addressing scheme 
  7931. implemented under OS/2 Version 2.0.  Such applications may make full use of the 
  7932. 80386 instruction set. 
  7933.  
  7934.  
  7935. ΓòÉΓòÉΓòÉ 21.77. 80386 ΓòÉΓòÉΓòÉ
  7936.  
  7937. 80386 
  7938.  
  7939. Intel 80386 microprocessor; the 32-bit processor upon which the OS/2 Version 
  7940. 2.0 operating system is based. 
  7941.  
  7942.  
  7943. ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ
  7944.  
  7945. W is "When to use" and G is "Guidelines," so 216/G2 is read as Page 216, second 
  7946. item in the Guidelines section.