Doc/view woes fixed

This is a discussion on Doc/view woes fixed within the Windows Programming forums, part of the Platform Specific Boards category; I dunno why this gave me so much trouble. I wish someone would have pointed me in the right direction ...

  1. #1
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598

    Doc/view woes fixed

    I dunno why this gave me so much trouble. I wish someone would have pointed me in the right direction but alas - the problem was working against the framework.

    Doc/view is actually quite useful because I can switch the doc/view pair at any time via a pointer - and the main frame window stays the same.

    So I just put all my data in the document class, which it just so happens that the view class has a way to get a pointer to the document which solves all of my access and communication problems between classes.

    So for those using doc/view -

    Document - stores all the information.
    View - draws in the window based on the information.

    So in my case the document class contains a map pointer, a tile manager pointer, and some other variables to specify map size, tile size, etc.

    The view class retrieves a pointer to the document class and gets a pointer to the needed information and/or has access to the information (by declaring the data members needed as public in the document class). Then it draws the tile map based on the information.

    Now why couldn't the SDK say that in English?


    So far it works great....that is until MFC crashed again. This is the third time I've rebuilt the project.....but so far nothing major has been lost.

  2. #2
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    I must admit that I have rarely used Doc/View in MFC. I havent personally come across a situation where it has been that needed, and many of my apps end up Dialog based.

    The closest I've got is a database app I'm slowly working on at the moment. It uses a Tab control to hold a variety of views, each one with it's own recordset and a few different variables. For that I have a CMainDialog->CViewTabCtrl->CIndividualViewDialog situation, and I end up using a pointer in the Tab control class to point to the current view (pretty much like MFC's Doc/View architecture that you discribed).

    I have a morbid (and slightly irrational) fear of using public variables in a parent for use in the view classes though. I ended up deriving a class for each individual view type (with it's own private variables). I also like using object factories to generate these classes. That then allows me to add an extra view very simply at the end, or even have an easy option of dynamically creating a tab at runtime.

    If you have it working though, then congrats. My app still has a lot of work, and I dont have the time to give it.

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Yeah even though MFC speeds some things up I think it slows others down. I've fought hard with this program and now my object factory as I would call it since it creates like 480 bitmap objects is crashing the system.

    Doesn't make sense though because all the destructors are being called. I also have a strange problem that dialogs do not show up as top-level windows until I load a bitmap into my CTileWindow class. Perhaps it has something to do with the paint code. Weird stuff.

    Another thing that is extremely difficult about MFC is when the error you get points you really deep into the heart of MFC code, even though it is your code that caused the error. This makes errors very hard to find.

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,691
    >> Yeah even though MFC speeds some things up I think it slows others down.
    Learning MFC is a never ending journey for me. More and more tasks will become speedy under MFC as you continue to learn it.

    >> Another thing that is extremely difficult about MFC is when the error you get points you really deep into the heart of MFC code...
    Determining the cause is usually as easy as viewing the debug call stack - find the first call site in your code that trickled down into an ASSERT within MFC. Figuring out why your code caused the assert isn't usually too tricky.

    gg

  5. #5
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    Quote Originally Posted by Codeplug
    >> Yeah even though MFC speeds some things up I think it slows others down.
    Learning MFC is a never ending journey for me. More and more tasks will become speedy under MFC as you continue to learn it.
    Agreed, and the same goes for ATL (well for me anyway). I recently tried to use COM events (both as a client, and as a server), this is horrible to do straight (and I ended up abandoning it once in the past becase it drove me nuts) , but under ATL it's not too bad at all.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 09:18 PM
  2. reading fixed length
    By Cpro in forum C++ Programming
    Replies: 4
    Last Post: 07-03-2008, 04:12 PM
  3. How accurate is the following...
    By emeyer in forum C Programming
    Replies: 22
    Last Post: 12-07-2005, 12:07 PM
  4. Fixed point MOD (for sin LUT)
    By Pea in forum C Programming
    Replies: 0
    Last Post: 04-10-2005, 07:03 PM
  5. Linking error
    By DockyD in forum C++ Programming
    Replies: 10
    Last Post: 01-20-2003, 05:27 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21