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. MFC splitter window view linkage

MFC splitter window view linkage

Scheduled Pinned Locked Moved C / C++ / MFC
questioncsharpc++data-structurestutorial
3 Posts 3 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.
  • M Offline
    M Offline
    Mister Transistor
    wrote on last edited by
    #1

    Hi, I'm building an MFC app (not everyone has moved to .NET yet, in fact I have decided to skip .NET and wait for the next framework, due any time now)that has a splitter window with two main panes, left and right. In each pane I have a tab control. The left tab control has a tree control in each tab. The right tab control will have different controls in each tab, depending upon the selection in the left tab control's selected tree and item. That's all fairly specific, but my question is quite general. What is the best way to cause events in one pane of a splitter (in the case selecting a treeitem) to make things happen in another pane. In a more simple example, how would events in the left view cause changes to the right view? I ask this because normally views do not know about each other, only about their parent frame. What's the most elegant way to link the views? (NB, I'm not asking what are the tree notification events, I know those).

    J 1 Reply Last reply
    0
    • M Mister Transistor

      Hi, I'm building an MFC app (not everyone has moved to .NET yet, in fact I have decided to skip .NET and wait for the next framework, due any time now)that has a splitter window with two main panes, left and right. In each pane I have a tab control. The left tab control has a tree control in each tab. The right tab control will have different controls in each tab, depending upon the selection in the left tab control's selected tree and item. That's all fairly specific, but my question is quite general. What is the best way to cause events in one pane of a splitter (in the case selecting a treeitem) to make things happen in another pane. In a more simple example, how would events in the left view cause changes to the right view? I ask this because normally views do not know about each other, only about their parent frame. What's the most elegant way to link the views? (NB, I'm not asking what are the tree notification events, I know those).

      J Offline
      J Offline
      Jose Lamas Rios
      wrote on last edited by
      #2

      Mister Transistor wrote: That's all fairly specific, but my question is quite general. What is the best way to cause events in one pane of a splitter (in the case selecting a treeitem) to make things happen in another pane. In a more simple example, how would events in the left view cause changes to the right view? I ask this because normally views do not know about each other, only about their parent frame. What's the most elegant way to link the views? (NB, I'm not asking what are the tree notification events, I know those). Both views are linked to the same CDocument, right? I'd follow the same approach as for document data changes in general. I'd add the following to the document: 1. some member to represent the shared state (i.e.: 'selected item') 2. a member function to get the shared state 3. a member function to alter the shared state 4. an enum with identifiers to be used in UpdateAllViews notifications, including an identifier for "shared state changed". Then, the view that changes the selected item simply calls the method in 3, which is implemented as follows:

      ////////////////////////////////////////
      // in your document header file:

      class YourDocument : public CDocument
      {
         // normal stuff
         [...]

      public:
         enum UpdateHints {ANY_CHANGE, SELECTED_ITEM_CHANGED, ...};
         void YourDocument::ChangeSelectedItem(ItemIdentifier item, CView* pRequestingView = NULL);
      };

      ////////////////////////////////////////
      // in your document implementafion file:

      void YourDocument::ChangeSelectedItem(ItemIdentifier item, CView* pRequestingView /*= NULL*/)
      {
         m_itSelected = item;
         UpdateAllViews(pRequestingView, SELECTED_ITEM_CHANGED, NULL);
      }

      The OnUpdate implementation for the right view can do something like:

      void RightView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)
      {
         switch (lHint)
         {
            default:
               Invalidate();
               break;
       
            case YourDocument::SELECTED_ITEM_CHANGED:
               OnSelectedItemChanged();
               break;
       
            // Other hints

      A 1 Reply Last reply
      0
      • J Jose Lamas Rios

        Mister Transistor wrote: That's all fairly specific, but my question is quite general. What is the best way to cause events in one pane of a splitter (in the case selecting a treeitem) to make things happen in another pane. In a more simple example, how would events in the left view cause changes to the right view? I ask this because normally views do not know about each other, only about their parent frame. What's the most elegant way to link the views? (NB, I'm not asking what are the tree notification events, I know those). Both views are linked to the same CDocument, right? I'd follow the same approach as for document data changes in general. I'd add the following to the document: 1. some member to represent the shared state (i.e.: 'selected item') 2. a member function to get the shared state 3. a member function to alter the shared state 4. an enum with identifiers to be used in UpdateAllViews notifications, including an identifier for "shared state changed". Then, the view that changes the selected item simply calls the method in 3, which is implemented as follows:

        ////////////////////////////////////////
        // in your document header file:

        class YourDocument : public CDocument
        {
           // normal stuff
           [...]

        public:
           enum UpdateHints {ANY_CHANGE, SELECTED_ITEM_CHANGED, ...};
           void YourDocument::ChangeSelectedItem(ItemIdentifier item, CView* pRequestingView = NULL);
        };

        ////////////////////////////////////////
        // in your document implementafion file:

        void YourDocument::ChangeSelectedItem(ItemIdentifier item, CView* pRequestingView /*= NULL*/)
        {
           m_itSelected = item;
           UpdateAllViews(pRequestingView, SELECTED_ITEM_CHANGED, NULL);
        }

        The OnUpdate implementation for the right view can do something like:

        void RightView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)
        {
           switch (lHint)
           {
              default:
                 Invalidate();
                 break;
         
              case YourDocument::SELECTED_ITEM_CHANGED:
                 OnSelectedItemChanged();
                 break;
         
              // Other hints

        A Offline
        A Offline
        Anonymous
        wrote on last edited by
        #3

        Jose, many thanks, your proposal is logical and relatively simple and elegant - I like it! regards Andrew

        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