home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 1 / ARM_CLUB_CD.iso / contents / magazines / progs / spectrum2 / !Spectrum2 / Articles / Regulars / Prog / WimpIdea < prev    next >
Encoding:
Text File  |  1994-09-11  |  4.1 KB  |  95 lines
  1. {fon:hom459045}
  2. WIMP lives up to its name?
  3. {fon:tri}
  4.  
  5.   Let's face it, the main market for Acorn computers is always going
  6. to be in education. The big thing that got Acorn where it is in
  7. education is the fact that it's fairly easy to learn to write nice
  8. structured readable programs in BBC BASIC.  I think it would be a
  9. good idea to enhance BBC BASIC to make it MUCH easier to write
  10. multitasking programs by adding elements to the language to handle
  11. some WIMP processing.
  12.  
  13.   The concept would be similar to that of sprite handling. Using the
  14. system sprite area, it's possible to write many programs using simple
  15. * calls and PLOT commands. If you want to do something really tricky,
  16. then you have to use SYS OS_SpriteOp. Commercial programs are
  17. expected to handle sprites in their own sprite area, and therefore
  18. would always use the SYS calls.
  19.  
  20.   For WIMP processing, BASIC would provide commands for a subset
  21. of WIMP operations, such as template loading and the poll loop.
  22. BASIC itself would handle all the mandatory processing, like opening
  23. a window when the poll loop returns an open window request. The
  24. BASIC programmer could write a readable program without having to
  25. stuff magic numbers into data blocks and invoking cryptic SYS calls.
  26.  
  27.   The programmer would first declare an application directory and
  28. name, APPLICATION("<App$Dir>", "MyApplication"); BASIC would then
  29. assume that the templates are in <App$Dir>.Templates and any local
  30. sprites are in <App$Dir>.Sprites. BASIC would then automatically
  31. perform the following operations without the programmer necessarily
  32. being aware of it: 1. Perform a Wimp_Initialise  2. Create a suitable
  33. local sprite area and load the sprites into it  3. Load all the
  34. templates from the template file and create the windows.
  35.  
  36. The programmer would then declare each of the Wimp_Poll responses
  37. that are to be handled, like:-
  38.  
  39. WHENEVER NULL:PROCnull
  40. WHENEVER MOUSE_CLICK window$,icon%,button%:PROCbutton
  41. WHENEVER MENU_SELECTION main%,sub%:PROCmenu
  42. WHENEVER DATA_LOAD filename$,size%,type%:PROCdataload
  43.  
  44. At this point, BASIC doesn't perform any operations, it just
  45. remembers the commands, and generates a suitable poll mask.
  46.  
  47. Finally the programmer invokes the poll loop:-
  48.  
  49.       WIMP_POLL
  50.  
  51.   The BASIC WIMP_POLL command handles all the following:
  52.  1: Performs a SYS"Wimp_Poll" and invokes any appropriate
  53. WHENEVER command.
  54.  2: Handles all open window requests by opening the window.
  55.  3: Handles all close window requests by closing the window.
  56.  4: Handles any quit message by performing the WHENEVER, if there is
  57. one, then doing a SYS"Wimp_CloseDown" and END. (This allows the
  58. program to do any application specific tidying up before ENDing).
  59.  
  60.   If the programmer wants to end the program, he just types END.
  61. BASIC will remember that this is a WIMP program and do the
  62. closedown automatically.
  63.  
  64.   There would be commands for creating menus, altering the text in
  65. writable text icons, changing the sprite in sprite icons, and such
  66. like. There would not be any BASIC commands for creating or deleting
  67. windows or icons, if you want to do that you would need to use the
  68. SYS calls directly.
  69.  
  70.   Whenever a window is referenced, it would be referred to by its name.
  71. BASIC would be responsible for mapping these to window numbers. 
  72. Instead of a command for creating a menu, perhaps there could be
  73. standard MENU files, like template files, and the program would
  74. simply invoke the predefined menus when it needed them.
  75.  
  76.   BASIC would not support any window that needs to be redrawn by the
  77. program except for the provision of a WHENEVER REDRAW
  78. command. When this is invoked, the program would need to do its own
  79. SYS "Wimp_GetRectangle" etc.  There would be different WHENEVER
  80. commands for certain specific messages, such as QUIT, DATA_SAVE,
  81. MODE_CHANGE, HELP_REQUEST.
  82.  
  83.   In order for it to be possible to write a program that just does a
  84. small amount of its own WIMP handling there would be a set of
  85. WHENEVER options that return the Wimp data block, these would look
  86. like:
  87.  
  88. WHENEVER EVENT 6,b%:PROCkeypress
  89. WHENEVER MESSAGE &80145,b%:PROCprinttypeodd
  90.  
  91. Now see the next article for an example of my new code.
  92.  
  93. {spr:l03}
  94. {end}
  95.