home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 144.lha / Leach_v1.3 / tech-notes < prev   
Encoding:
Text File  |  1986-11-21  |  3.4 KB  |  60 lines
  1.  
  2. This file contains a set of random observations about my experiences
  3. developing Leach.
  4.  
  5. It is amazing that Leach got written at all. I originally thought of three
  6. different designs for the program. I can't get the two most interesting of
  7. those ways to work. I started with the crudest approach. Encouraged by
  8. initial moderate success, I tried the more sophisticated approaches. In
  9. both cases, I wasted a lot of time staring at the code until I realized
  10. that there were fundamental insurmountable flaws in both of them.
  11.  
  12. One thing I learned is that you can't mess with the pointer value in
  13. "UserPort" in an application's Window structure except in the limited ways
  14. described in the Intuition Manual. If you change the contents of this
  15. variable (Who in their right mind would even consider doing this?),
  16. Intuition stops sending messages to the original IDCMP. Actually this might
  17. have its uses in Leach technology. The problem is that the Host is also
  18. likely to switch its attention to the new port. In retrospect, this isn't
  19. surprising.  Intuition knows which window is the active one, and this
  20. window gets all the input events that its IDCMPFlags specify.  How does
  21. Intuition know which IDCMP to send the input event messages to? It looks in
  22. the active window's Window structure, that's how.
  23.  
  24. The next lesson was that Intuition reuses IntuiMessage structures that are
  25. returned to it by ReplyMsg()'s. This shouldn't be news to anybody. However,
  26. when these messages get recycled into an unprioritized message queue,
  27. Intuition does not re-clear the node's ln_Pri member. I tried to hide some
  28. flags in ln_Pri and soon started receiving new messages with the flags
  29. already set!
  30.  
  31. My original intent was to replace mp_Task and mp_Signal in the Host's
  32. UserPort with values belonging to Leach. Late in the project, is noticed
  33. that the signal Leach had allocated was the same as the one the Host was
  34. expecting. This seemed like a bug, so I added code to make sure the two
  35. signals had different values. The result was that the Host would respond to
  36. the first signal "ring" from Leach and then ignore all others. Again in
  37. hindsight, the reason seems obvious. Digi-View is almost certainly doing a
  38. "Wait( 1L << UserPort->mp_Signal);". It's not saving the signal bit
  39. independently. When Leach begins to execute, the Host is already Wait()'ing
  40. for the original signal, so it responds to the first ring. From then on,
  41. since I had changed the value of mp_Signal, the Host starts waiting for the
  42. new signal.
  43.  
  44. It appears that for low resolution screen, you can get MOUSEMOVE messages,
  45. even though the mouse pointer has not really moved. "Twitching" the mouse,
  46. can generate a single input event/message that has the same mouse
  47. coordinates as those in the last message you received, ie. the mouse hasn't
  48. moved! It seems that MOUSEMOVE coordinates always reflect the dimentions of
  49. your screen, but the MOUSEMOVE events are triggered by crossing boundaries
  50. of a fixed 640x400 grid.
  51.  
  52. Leach Version 1.3 initially exibited serious problems when run against
  53. Hosts that set the MENUVERIFY IDCMP flag; the system locked up when the
  54. menu button was pressed! Apparently, Exec shuts down so completely,
  55. Wait()'ing for the Host to reply to the MENUVERIFY message, that Leach
  56. never got a chance to relay the reply back to Intuition. I don't yet
  57. understand the exact mechanism behind this problem. For the time being, I
  58. have had to settle for the poor solution of disabling all Intuition verify
  59. messages.
  60.