15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


1 Doc., n Views - 0.5A, 1Q

PP mail system -- LAWSONW@sydney.ccur.com
Wednesday, October 02, 1996

G'day!
My trusty old ('93 and MFC 2.0, ISBN 1-55615-511-5) Kruglinski
lays out a general solution to the problem on pp254-255.

However, I got to thinking about a fast-n-dirty solution where
"one template fits all".  Which is to say, all views are superficially
similar, as produced by the standard menu "New Window" command.

Which raises another question.

What is the difference between invoking an MFC method via the standard
message pump of WM_COMMANDs and doing so directly?  I can't see why
executing via DispatchCmdMsg should be any different than executing from
a user-written call.  A little experiment (code extracts follow) brought
up 2 views at startup with no errors, but I'd hardly call that a
definitive test.

Can anyone see traps in making direct calls on message-handlers?

Regards,
Jim LW

>From MFC Source, and a starting point for a "proper" solution
=============================================================

void CMDIFrameWnd::OnWindowNew()
{
    CMDIChildWnd* pActiveChild = MDIGetActive();
    CDocument* pDocument;
    if (pActiveChild == NULL ||
       (pDocument = pActiveChild->GetActiveDocument()) == NULL)
    {
        TRACE0("Warning: No active document for WindowNew command.\n");
        AfxMessageBox(AFX_IDP_COMMAND_FAILURE);
        return;     // command failed
    }

    // otherwise we have a new frame !
    CDocTemplate* pTemplate = pDocument->GetDocTemplate();
    ASSERT_VALID(pTemplate);
    CFrameWnd* pFrame = pTemplate->
                        CreateNewFrame(pDocument, pActiveChild);
    if (pFrame == NULL)
    {
        TRACE0("Warning: failed to create new frame.\n");
        return;     // command failed
    }

    pTemplate->InitialUpdateFrame(pFrame, pDocument);
}

------------------------------------------------------------------------

>From the Test Project
=====================

In ClassWizard:
    Activate ID_WINDOW_NEW for CMainFrame.

In CMainFrame.h:

    public:
        void DoNewWindow(){OnWindowNew();};

In CMainFrame.cpp:

void CMainFrame::OnWindowNew()
{
    // TODO: Add your command handler code here
    CMDIFrameWnd::OnWindowNew();
}


In the main application module:

// CFREDApp initialization

BOOL CFREDApp::InitInstance()
{
    // Standard initialization

    

    // The main window has been initialized,
    // so show and update it.
    pMainFrame->ShowWindow(m_nCmdShow);
    pMainFrame->UpdateWindow();

    //Now do a second one!
    pMainFrame->DoNewWindow();

    return TRUE;
}



Stuart Downing -- stuartd@izzy.net
Friday, October 04, 1996

[Mini-digest: 2 responses]

----------
>What is the difference between invoking an MFC method via the standard
>message pump of WM_COMMANDs and doing so directly?  I can't see why
>executing via DispatchCmdMsg should be any different than executing from
>a user-written call.  A little experiment (code extracts follow) brought
>up 2 views at startup with no errors, but I'd hardly call that a
>definitive test.
>
 >Can anyone see traps in making direct calls on message-handlers? 
1)  You're "unprotecting" a protected member function.  Perhaps that's not too bad.
2)  You're calling an undocumented interface.  On the other hand, as shown in your 
code, if you were to handle the ID_WINDOW_NEW command in your frame
window, it would be perfectly natural to call CMDIFrameWnd::OnWindowNew to
get the base class functionality.  This is typical of many MFC message handlers.
3)  When you call a function directly, you're circumventing the message map-style 
function overriding mechanism.  I.e. message maps provide a virtual function like
service that you can't use when you call the function directly.  In your case, however
you know that what you want is the code in MFC's handler for some message.  You're 
adding a utility function, not a message handler.
So I guess even though your thoughts are impure, your intentions are valiant.  I wonder
what Mike will say. :)
------------------------
Stuart Downing
Creative Solutions, Inc.
stuartd@izzy.net




-----From: Roger Onslow/Newcastle/Computer Systems Australia/AU

You don't get the routing.  However, if you *really* know who's going to get 
the message (and that there won't be some derived class with its own message 
map because message handlers aren't virtual remember), then no harm and more 
efficient - but only in those cases.

Roger




| Вернуться в корень Архива |