home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / programm / 13919 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.8 KB
  1. Path: sparky!uunet!sun-barr!apple!apple!mlanett
  2. From: mlanett@Apple.COM (Mark Lanett)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: IYourObject, Views, & ViewEdit
  5. Message-ID: <71159@apple.Apple.COM>
  6. Date: 13 Aug 92 04:54:50 GMT
  7. References: <1992Aug12.231336.1049@reed.edu>
  8. Organization: Apple Computer Inc., Cupertino, CA
  9. Lines: 53
  10.  
  11. bowman@reed.edu (Eric Bowman (bobo)) writes:
  12.  
  13. >MacApp 3.0.1 question:
  14.  
  15. >I've created a window in ViewEdit with several views, including a couple of
  16. >subclasses of TTextListView.  When I close then window, MacApp drops into
  17. >Macsbug to tell me that I've handed FreeIfObject an invalid object.  I
  18. >thought the problem might be that IMyTextListView wasn't getting called.
  19. >This belief proved to be correct (though I have no idea if it's related to
  20. >the crashing...), which causes me some confusion.  So I played with the
  21. >skeleton app, and discovered that IViewSkeleton never gets called, either.
  22.  
  23. There are two ways to create objects in MacApp, procedurally or via resources.
  24. If you subclass a view, then to support procedural creation you write an
  25. I<class> routine, and *you* call it. For example:
  26.  
  27.     TMyTextListView* list = new TMyTextListView;
  28.     list->IMyTextListView (myParams, doc, super, loc, size, ...);
  29.  
  30. View creation via resources is different. What MacApp does is read the
  31. view signature and allocate an uninitialized view object. So it will allocate
  32. an object for TMyTextListView, but won't call IMyTextListView (it knows
  33. how big it is and can allocate it, but doesn't know which methods you've
  34. written to initialize it). Instead it will call Initialize and DoPostCreate (or
  35. just IRes in MacApp 2.0).  So to support view creation via resources you
  36. override Initialize and DoPostCreate and do your own work in there. Initialize
  37. is normally used for setting fields to nil, DoPostCreate for allocating other
  38. objects. You generally override both of them. For example:
  39.  
  40. pascal void TMyTextListView::Initialize () {
  41.     inherited::Initialize(); // DON'T forget to call (FIRST!) or you will
  42.         // have very strange errors later.
  43.     fMyList = nil;
  44. }
  45. pascal void TMyTextListView::DoPostCreate(TDocument* doc) {
  46.     inherited::DoPostCreate(doc);
  47.     fMyList = NewList();
  48. }
  49.  
  50. The reason for setting the field to nil first is a matter of safety with Free.
  51.  
  52. If you need to pass some specific information to a view, then write a Set<>
  53. routine and call that after creating it. Set<> doesn't need to call any I<>
  54. routines.
  55.  
  56.     TWindow* wind = gViewServer->NewTemplateWindow(...);
  57.         // MacApp calls DoPostCreate for all views
  58.     TView* list = wind->FindSubView('list');
  59.     if (list == nil) ProgramBreak("View resource problem - list");
  60.     ((TMyTextListView*) list)->SetMySpecialParams(myParams);
  61. -- 
  62. Have a bajillion brilliant Jobsian lithium licks.
  63. Mark Lanett, NOT speaking for anyone. Personal opinion only.
  64.