home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14609 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  4.9 KB
  1. Xref: sparky comp.sys.mac.programmer:14609 comp.sys.mac.system:11346
  2. Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system
  3. Path: sparky!uunet!caen!destroyer!terminator!potts
  4. From: potts@itl.itd.umich.edu (Paul Potts)
  5. Subject: Re: Color Icons
  6. Message-ID: <1992Aug27.154337.8345@terminator.cc.umich.edu>
  7. Keywords: coloricon
  8. Sender: news@terminator.cc.umich.edu (Usenet Owner)
  9. Organization: Instructional Technology Laboratory, University of Michigan
  10. References: <1992Aug26.233800.21347@sagpd1>
  11. Date: Thu, 27 Aug 1992 15:43:37 GMT
  12. Lines: 107
  13.  
  14. In article <1992Aug26.233800.21347@sagpd1> bberqu@sagpd1 () writes:
  15. ... stuff on color icons left out...
  16. >
  17. >Programmers question:
  18. >
  19. >I'm trying to use ModalDialog with a filterProc function which will
  20. >handle popupmenus,  when I call ModalDialog and just let it sit there
  21. >no mouse movement or anything, after a while, I get, I believe a system
  22. >error #26 according to MacsBug, all my filter proc function does is 
  23. >return (TRUE), I've also tried FALSE.  My impression from IM is that
  24. >ModalDialog sits there and waits for a mousedown event within the dialog
  25. >and when it gets either a itemhit or incontent or whatever, it then calls 
  26. >the filterProc function (if defined), is this true? 
  27.  
  28. Not quite. When you set up a filter procedure, ModalDialog 
  29. sends all the events to it for screening before it looks at them. 
  30. This includes idle events, if there are any: you can actually do things
  31. on idle time in your filter procedure, if you don't need any guarantee that
  32. you will get idle time (you wont' get it in a very busy system, at least
  33. not consistently).
  34.  
  35. ModalDialog *always* quits when it gets one of its triggering events,
  36. like a keypress that it understands (return for the default button, for
  37. example), or a mouse click in a button or on a checkbox. If you have, say,
  38. ten check boxes and an OK button, and you want to keep the modal dialog up
  39. until the OK button is hit, you have to call ModalDialog in a loop which
  40. checks to see what was hit and only stops calling it if the OK button was
  41. hit.
  42.  
  43. If you install a filter procedure, you return TRUE if you want ModalDialog
  44. to quit. You have the event that got passed to your filter proc, so you
  45. can change it if you want. You have a pointer to the item ID that ModalDialog
  46. should return. Here's a diagram:
  47.  
  48. Without a filter proc (actually with the default filter proc)
  49.  
  50. ---> event--->   ModalDialog  ---------> exit (return the item that was hit
  51.                  Was a triggering              to dismiss the dialog)
  52.                  event received?
  53.                  
  54.  
  55. With a filter proc
  56.  
  57. ---> event---> FilterProc ----> ModalDialog ----> exit (return the item that
  58.                look at the       Did filterProc         was hit to dismiss the
  59.                event; return     send "True?"           dialog)
  60.                TRUE to tell      If so, dismiss
  61.                ModalDialog that  the dialog.
  62.                this was a        Otherwise, handle
  63.              "triggering event", the event.
  64.                otherwise return  
  65.                false. 
  66.  
  67. No doubt someone will have a correction or two to add to the above, but
  68. it should give you the general idea.
  69.  
  70. Here's an example: if you want your filter procedure to do something
  71. on its own when the dialog is passed an update event, code it like this:
  72.  
  73. (fragment from a filter procedure)
  74.  
  75. switch (theEvent->what)
  76. {
  77.     case (updateEvt):
  78.     HandleUpdate(theDialog);
  79.     return FALSE;
  80. /*Do not return an item hit value.  Returning
  81. FALSE tells modalDialog to handle the update
  82. event.  We have just added our own handling
  83. of the event. */
  84.     break;    
  85.  
  86. where "HandleUpdate" is a routine of mine that draws on the dialog.
  87. Note that if your filter proc handles the event fully, and you don't want
  88. ModalDialog to even see it, you can clear the event, although this generally
  89. shouldn't be necessary since ModalDialog has useful default reactions to
  90. most events.
  91.  
  92. >I assume that it 
  93. >passes the dialog poointer/event record pointer/itemhit pointer, is this 
  94. >true?  It looks like its calling my filterProc constantly, if this is true 
  95. >do I need handle events within the filterProc?  Assuming all my parameters
  96. >are correct for filterProc are correct, what am I doing wrong?
  97.  
  98. It is calling your filterProc constantly: every event goes through it. 
  99.  
  100. >
  101. >An explanation of how ModalDialog and the filterProc functions work with
  102. >each other would be nice.
  103. >
  104. >Thanks in advance
  105.  
  106. I hope this helps some with your understanding of modal dialogs. I'm not
  107. sure how you should go about supporting a pop-up menu, but I tend to think
  108. that doing all the mouse tracking in the filter proc is the wrong approach.
  109. I was under the impression that there was pop-up support in the OS now.
  110. Can anyone confirm or deny? If not you may want to build a window and
  111. handle your own events from scratch, track the control, etc.
  112.  
  113. >
  114. >Brian
  115.  
  116.  
  117. -- 
  118. "It'sVerySad / toSeeTheAncientAndDistinguishedGameThatUsedToBe / aModelOf
  119. DecorumAndTranquilityBecomeLikeAnyOtherSportABattlegroundForRivalIdeologies
  120. toSlugItOutWithGlee." (from _Chess_). -potts@itl.itd.umich.edu-
  121.