home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18880 < prev    next >
Encoding:
Text File  |  1993-01-09  |  3.0 KB  |  70 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!think.com!ames!purdue!mentor.cc.purdue.edu!biomac1g.bio.purdue.edu!user
  3. From: pf@bilbo.bio.purdue.edu (Paul Furbacher)
  4. Subject: Re: TVISION:cmQuit and clearEvent :(
  5. Message-ID: <pf-090193223831@biomac1g.bio.purdue.edu>
  6. Followup-To: comp.lang.c++
  7. Sender: news@mentor.cc.purdue.edu (USENET News)
  8. Organization: Purdue University
  9. References: <1993Jan9.100350.22034@sparc4.ncu.edu.tw>
  10. Date: Sun, 10 Jan 1993 03:48:51 GMT
  11. Lines: 57
  12.  
  13. My mailer is broken this weekend: hopefully you'll see this
  14. even though you specifically request e-mail replies.
  15.  
  16. In article <1993Jan9.100350.22034@sparc4.ncu.edu.tw>, oper7@ee05.ncu.edu.tw
  17. (Anthony Shih Hao Lee) wrote:
  18.  
  19. > [when] I quit my TV app, TApplication seems not to destroy all
  20. > other objects which has created for my application.
  21.  
  22. This is true, for objects such as collections.  You have to 
  23. handle the disposing of objects which are not inserted into
  24. either the application object or the desktop.  To do this, 
  25. you have to override the destructor member function of the 
  26. Application class.
  27.  
  28. > I must actively to broadcast cmQuit message to those windows
  29. > which has exposed on the desktop, so that they could finish their job.
  30.  
  31. No. Since you own BC++&AF, look up the source for TGroup, the 
  32. ancestor of among other things, TDesktop, TProgram and TApplication.
  33. You will see that calling TApplication.Done (Pascal flavor here, if you 
  34. don't mind, = ~TApplication) you are eventually calling 
  35. TGroup.Done.  And TGroup.Done iterates through its linked list
  36. of inserted subviews -- be they editor windows, calculators, 
  37. memos, ascii tables, whatever -- and calls their destructors.
  38. Therefore, objects inserted into TApplication and TDesktop
  39. descendents are properly disposed of, assuming any descendent
  40. destructors you may have written for any of the subviews are 
  41. deallocate properly. 
  42.  
  43. > 1.
  44. > in fact, TApplication should broadcast some useful message such as
  45. > cmClose, cmQuit to announce windows on the desktop.
  46. > and, cmQuit message for a TApplication seems not similar to other
  47. > evCommand.
  48. > 2.
  49. > Due to cmQuit is the most important message which all
  50. > handleEvent should take response, user's TApplication::handleEvent
  51. > could not use clearEvent, and must pass this message to it's parent
  52. > handleEvent. am I wrong?
  53.  
  54. Again, this is where it is up to you to create a descendent of
  55. TApplication and modify the destructor and possibly the HandleEvent()
  56. member function.  Remember that if you want your descendent 
  57. to get first crack at handling an event, place your modifying
  58. code ***before*** the call to the ancestor's method, especially
  59. in the case where you know the ancestor clears the event.
  60.  
  61. And it is up to you to design the messaging between objects --
  62. the application framework foundation classes cannot anticipate
  63. all your special messaging needs.  This is what inheritance is
  64. all about: creating descendents whose behavior is evolved to 
  65. a greater degree of sophistication than the ancestors'.
  66.  
  67. Hope this is clear enough for you to make further progress.
  68.  
  69. PF
  70.