home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19977 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.3 KB
  1. Xref: sparky comp.lang.c++:19977 comp.std.c++:2129
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!usc!news.cerf.net!nic.cerf.net!hlf
  3. From: hlf@nic.cerf.net (Howard Ferguson)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: Callbacks -- suggested approaches??
  6. Date: 26 Jan 1993 21:10:08 GMT
  7. Organization: CERFnet Dial n' CERF Customer Group
  8. Lines: 49
  9. Message-ID: <1k49bgINNo63@news.cerf.net>
  10. References: <DAVIDM.93Jan25171343@consilium.com> <1k41efINN2oj@darkstar.UCSC.EDU>
  11. NNTP-Posting-Host: nic.cerf.net
  12.  
  13. In article <1k41efINN2oj@darkstar.UCSC.EDU> spencer@cats.ucsc.edu (Michael Spencer) writes:
  14. >
  15. >davidm@consilium.com (David S. Masterson) writes:
  16. >
  17. >>I'm looking for suggestions on how to handle callback functions in C++ that
  18. >>will be more standard than the one we're currently using.
  19. >
  20. >Would the following approach be helpful. If so, drop me a message.
  21. >
  22. > 
  23. >                         WIDGET CALLBACKS
  24. > 
  25. >Widgets which use callbacks are similarly easy. XSimple widgets attach
  26. >their own callback and pass to it a reference to a coder written
  27. >Procedure. The callback calls the Procedure and passes to it a
  28. >Choice object which contains the data needed to respond to the event.
  29. >For example, to activate a popup dialog widget:
  30. > 
  31. >          PopupYesno (parent, "Do it ?", YesnoProc);   // evoke popup
  32. > 
  33. >          void YesnoProc (Choice chose)    // coder written to handle event
  34. >               {
  35. >               if (chose.flag)
  36. >                    // do something
  37. >                    }
  38. >               else
  39. >                    // do something else
  40. >               }
  41. > 
  42. >The coder written YesnoProc() defines what occurs based on the
  43. >user's election. Choice is an object (declared in XUTILS.H) which
  44. >will hold any information generated by any callback or event handler.
  45. > 
  46. >BUT, the coder need not become involved in the sordid details of
  47. >adding the callback to the widget or extracting the relevant
  48. >information from the returned callback struct. That is done
  49. >automatically and the relevant information is passed via the
  50. >Choice data members. 
  51.  
  52. Yes but the coder does have to get involved in the sordid details
  53. of the prototype of the YesnoProc. Ther type of the function being
  54. passed in has to be considered. In good old C the function would
  55. be automatically cast to whatever form it was stored in.
  56.  
  57.     hlf
  58.  
  59.  
  60.  
  61.  
  62.