Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Run-time objects and CRuntimeClass

Run-time objects and CRuntimeClass

Scheduled Pinned Locked Moved C / C++ / MFC
questiondata-structureshelplearning
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Antti Keskinen
    wrote on last edited by
    #1

    Hi there ! I made a few searches through the articles and through the board, but didn't manage to find an answer.. If there is already an answer to this, just post the link :) So, I have a CCtrlView-derived class, CTabView (No, not a co-incidence). This class is responsible for upkeeping a Tab control (Created through CCtrlView's constructor) and an array of CViews. Now, when you wish to add a new view to the tab, it requires you to insert a pointer to your CView-derived class through the RUNTIME_CLASS-macro. After that, it checks if the run-time info you specified is indeed a CView-derived, and creates a new object based on this info with CRuntimeClass::CreateObject. When the creation is done, it creates and attaches a new view to this object by casting a pointer to the CView-class and calling it's Create-method. Then, it saves the CView-pointer to a CObList for further use. When quitting, the application goes through the list and calls each CView's DestroyWindow in succession until the list is clear. After that, it posts a OnDestroy-message to the underlying CCtrlView which destroys the tab control. But the problem is that when I build & run this app, it works smoothly until the quit phase. There, it causes an assertion. What am I missing here ? Should I use 'delete' on each of the pointers after DestroyWindow as well ? Can it be done ? What, exactly, does CreateObject do when it builds an object from the run-time info ? And if 'delete' is not the answer, what is ? Or shouldn't I delete the views at all, but let "The Framework" work it out ? Of course, if someone already has a functioning Tab control which accomplishes the above mentioned smoothly, a link is again appreciated :) Thanks in advance, Antti Keskinen EDIT: The 'delete' operation did no good, the app still asserts. For additional info, I am using a splitter window to where my derived control view is loaded to. Debugging reveals it is XTreme toolkit's CXTPFrameWnd, which causes the assertion. ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups