Re: MFC 9 , the next issue

From:

"Rick Ruhl" <ricker@cssincorp.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 14 Jul 2009 10:34:38 -0500

Message-ID:

<Opu6aiJBKHA.1380@TK2MSFTNGP02.phx.gbl>

yeah, duh! that's what I get for coding when Im tired and under stress,
nevermind LOL

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:cbuo55pjpnvtg5s9hges8svb7f50so3b47@4ax.com...

See below...
On Tue, 14 Jul 2009 00:20:59 -0500, "Rick Ruhl" <ricker@cssincorp.com>
wrote:

Joe, et all

I was able to replicate it failing at loadframe in the new test code I
made. When I changed the cs.lpszClass from the default name to another
name, it failed in my test app. Commenting it out made it work.

Now, I was able to change the cs.lpszClass before I moved to the new
classes.

Code attached to show you where I set it at.

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CMDIFrameWndEx::PreCreateWindow(cs) )
return FALSE;
// TODO: Modify the Window class or styles here by modifying
// the CREATESTRUCT cs
cs.lpszClass = _T("TEST");

****
I don't see where you did a RegisterWindowClass of this name. Since you
did not show it,
I presume you did not do it, so OF COURSE this will fail. The class name
must be a name
which you have previously registered.
joe
****

cs.style = WS_OVERLAPPED | WS_CAPTION | FWS_ADDTOTITLE
| WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_MAXIMIZE |
WS_SYSMENU;
return TRUE;
}

"Rick Ruhl" <ricker@cssincorp.com> wrote in message
news:IImdnT7RlLsFYMbXnZ2dnUVZ_uGdnZ2d@posted.hiwaay1...

tracing through MFC, it's failing at

if (!pFrame->LoadFrame(m_nIDResource,
WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, // default frame styles
NULL, &context))

in doctempl.cpp at line 275

"Rick Ruhl" <ricker@cssincorp.com> wrote in message
news:xM-dnR7doYSwZcbXnZ2dnUVZ_tGdnZ2d@posted.hiwaay1...

That's what I did Joe, I made a new project with splitters and all and
checked it class by class. That's what's driving me nuts..

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:vdsn55t0imdudj3p146biv2cucsq840i7j@4ax.com...

Generally, hand-editing changes like this is dangerous. My own
approach
would be to
create a whole new project based on the "Ex" style, then use something
like windiff or
some similar source-compare tool to compare key modules of the new
project with the old
project, and make sure that all the appropriate code (that is, any
code
I did not write)
is the same in both projects. Generally, just simple hand-edits are
not
really sufficient
to guarantee that everything will work as expected. Otherwise, I'd
not
offer an opinion
on what might have gone wrong because until I did the source-compare
of
the critical
modules I wouldn't know if my hand-edits had captured all the
essentials.
joe

On Mon, 13 Jul 2009 20:20:03 -0500, "Rick Ruhl" <ricker@cssincorp.com>
wrote:

Im getting a ASSERT on File/New

Code was changed as follows:

CWinApp to CWinAppEx
CMDIChildWnd to CMDIChildWndEx
CMDIFrameWnd toCMDIFrameWndEx

etc etc

I do the following

m_pDocTemplate = new CMultiDocTemplate(
IDR_DXTERMTYPE,
RUNTIME_CLASS(CDXTermDoc),
RUNTIME_CLASS (CSession), // csession is the CMDIChildWndEx
RUNTIME_CLASS(CTextView));
m_pDocTemplate->SetContainerInfo(IDR_MAINFRAME);
AddDocTemplate(m_pDocTemplate);

CSession does have a splitter windows in it. CMysplitter derived from
CSplitterWndEx

So when I do a file/new I can get to the constructor of
CSession::CSession
and trace through that, but then I get an assert
in winmdi.cpp at line 504, which is

ASSERT(::IsWindow(pParentWnd->m_hWndMDIClient));

All this worked before I moved to the new classes, have I missed
anything?

Thanks
Rick

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm