home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13501 < prev    next >
Encoding:
Text File  |  1992-09-10  |  6.2 KB  |  170 lines
  1. Xref: sparky comp.lang.c++:13501 comp.windows.open-look:3794 alt.toolkits.xview:855
  2. Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!jethro.Corp.Sun.COM!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!midniteoil!soloway
  3. From: soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
  4. Newsgroups: comp.lang.c++,comp.windows.open-look,alt.toolkits.xview
  5. Subject: C++ and callback problems (VERY LONG)
  6. Date: 10 Sep 1992 22:28:52 GMT
  7. Organization: Sun Microsystems, Inc.
  8. Lines: 156
  9. Distribution: world
  10. Message-ID: <lavj14INN4ul@appserv.Eng.Sun.COM>
  11. Reply-To: soloway@midniteoil.Eng.Sun.COM
  12. NNTP-Posting-Host: midniteoil
  13.  
  14. From <name kept anonymous to protect the innocent>:
  15.  
  16. > This letter concerns the your article in alt.toolkits.xview.  I have
  17. > tried to implement your method of encapsulating callbacks thru a
  18. > static wrapper function and storing the 'this' pointer as xv_data.
  19. > Two problems have arisen: the first was due to the fact that i ignored
  20. > your short and somewhat cryptic note:
  21. > ->        // If a notify handler has been specified, via
  22. > ->        // "void Button::setNotifyHandler (void (*)(Button *, Event *))",
  23. > ->        // then call it.
  24. > ->            if (object->notifyHandler)
  25. > ->              (*object->notifyHandler)(object, event);
  26. > 
  27. > I called directly object->notifyhandler(), but then calls in derived classes
  28. > were made to the ancestor callback, as the value of
  29. > object->notifyhandler() is known at compile-time.  I then realized what
  30. > u did, and added a private variable which points to the callback, thus
  31. > sort of explicitly writing the late-binding code.  What turns out
  32. > (using g++ 2.1), is that the code is unusable, because the
  33. > private handler receives a hidden this pointer as its first parameter,
  34. > but no such parameter is pushed to the stack in:
  35. > ->        (*object->notifyHandler)(event);
  36. > thus, stepping into a call of the form
  37. >         (*object->notifyhandler(menu, menuitem)
  38. > where menu=x and menuitem=y, and notifyhandler pointing at notifyhandlerproc
  39. > yields
  40. >         notifyhandlerproc(this=x, menu=y, menuitem=junk)
  41. > 
  42. > i could explicitly define the variable notifyhandlerproc to be a
  43. > pointer to a function which receives (obj *, Menu, Menu_item), but how
  44. > portable is this?  and since you stated in your article that this
  45. > method was used in uit, can you please let me know what the portable,
  46. > arm-compliant, overall stable workaround is?
  47.  
  48. After re-reading what I wrote, I can see why my original article may have
  49. been confusing.  I left out a class declaration that would have made example
  50. #1 more clear and I made a mistake in the "notifyProc" part of example
  51. #2 that could make the example very confusing.  In order to correct these
  52. mistakes, I've included portions of the original posting along with commentary
  53. that will hopefully clear up the confusion.
  54.  
  55. -> This article describes a method I use to provide a convenient C++
  56. -> callback interface for XView and provide the ability to encapsulate
  57. -> callback behavior in a subclass.  The method described is used in
  58. -> UIT V2.
  59.  
  60. [text deleted]
  61.  
  62. EXAMPLE 1:
  63.  
  64. -> A basic notifyProc member function that calls a user spcified callback
  65. -> handler might look like this:
  66. -> 
  67. ->     void Button::notifyProc (Panel_item item, Event *event)
  68. ->     {
  69. ->       Button *object = (Button *)xv_get(item,
  70. ->                                         XV_KEY_DATA,
  71. ->                         THIS_POINTER_KEY);
  72. -> 
  73. ->       // If a notify handler has been specified, via
  74. ->       // "void Button::setNotifyHandler (void (*)(Button *, Event *))",
  75. ->       // then call it.
  76. ->           if (object->notifyHandler)
  77. ->             (*object->notifyHandler)(object, event);
  78. ->     }
  79.  
  80. The "notifyHandler" member used here is actually a data member.  The class
  81. might look something like this:
  82.  
  83.     class Button {
  84.     public:
  85.       ...
  86.       void setNotifyHandler (void (*handler)(Button *, Event *))
  87.         {
  88.           notifyHandler = handler;
  89.         }
  90.  
  91.     protected:
  92.       Panel_item xviewButton;
  93.  
  94.     private:
  95.       static void   notifyProc(Panel_item, Event *);
  96.       void        (*notifyHandler)(Button *, Event *);
  97.     }
  98.  
  99. The notifyHandler data member is just a holder for a user specified
  100. callback function.  The user specified callback function should be
  101. a regular external function (not a member function of another or this
  102. class).
  103.  
  104. The function that XView actually calls for the PANEL_NOTIFY_PROC is
  105. "notifyProc".  "notifyProc" does not have an implicit "this" parameter
  106. because it is a static member function.  "notifyProc" needs to be
  107. declared public for use with g++ because it is illegal to use the
  108. address of a private or protected member function (static or non-static)
  109. in g++.  This is not the case for AT&T or ANSI C++.
  110.  
  111. -> This provides a "convenient" callback interface, but it does not provide
  112. -> for encapsulation of callback behavior in the class.  To provide the ability
  113. -> to encapsulate the behavior, you need to provde a virtual function that
  114. -> will be overridden in subclasses that are encapsulating the callback
  115. -> behavior:
  116.  
  117. EXAMPLE 2:
  118.  
  119. ->     class Button {
  120. ->     public:
  121. ->       ...
  122. -> 
  123. ->     protected:
  124. ->       // Make xviewButton protected so that derived classes can get hold
  125. ->       // of the XView button object when inside of their personalized
  126. ->       // handlers.
  127. ->           Panel_item xviewButton;
  128. -> 
  129. ->     private:
  130. ->       static  void notifyProc(Panel_item, Event *);
  131. ->       virtual void notifyHandler(Event *);
  132. ->     }
  133. -> 
  134. ->     void Button::notifyProc (Panel_item item, Event *event)
  135. ->     {
  136. ->       Button *object = (Button *)xv_get(item,
  137. ->                                         XV_KEY_DATA,
  138. ->                         THIS_POINTER_KEY);
  139. -> 
  140. ->       (*object->notifyHandler)(event);
  141. ->     }
  142.  
  143. The "notifyHandler" in this example is an actual member function of the
  144. class.  It should be called as such.  Since I made a mistake in this
  145. example, this is where most of the confusion probably is.  The above
  146. "notifyProc" should be re-written as follows:
  147.  
  148.     void Button::notifyProc (Panel_item item, Event *event)
  149.      {
  150.        Button *object = (Button *)xv_get(item,
  151.                                          XV_KEY_DATA,
  152.                          THIS_POINTER_KEY);
  153.  
  154.        object->notifyHandler(event);
  155.      }
  156.  
  157. -> You can then define the behavior of notifyHandler in a class derived
  158. -> from Button:
  159.  
  160. [text deleted]
  161.  
  162.                      - Mark
  163.  __________________________________________
  164.  \_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
  165.  /_Distributed Systems Services (ToolTalk)_/
  166.  \__SunSoft (A Sun Microsystems Company)___\
  167.  
  168.  
  169.  
  170.