How do I get a handle to CRUNTIMECLASS initiated classes?

Hello!
I am making an MDI application where each of the CMDIChildWnd windows contain 2 CScrollviews in a CSplitterWnd.

I have severe problems accessing the individual CScrollviews from the CMDIChildWnd window.

Basically my CMDIChildWnd contains 4 panes, where 2 are CSplitterWnd scroll views (see code below).
When the CScrollview classes attempt to find out who is their parent owner, then there is an assertion error and the app. crashes. I assume that this happens because the CScrollviews are
kicked off as CRUNTIMECLASS objects? (have no clue elsewise...) - I have tried to use methods GetParent, GetOwner, etc. nothing changes the situation....

I really need to get a pointer to my CSplitterWnd scroll views in so that the owner (and only the owner) CMDIChildWnd window can address them by choice. I am really suspicious about how CRUNTIMECLASS works, and maybe I need to get the pointer using completey different method calls.

What can I do?
Grateful if somebody knows what I do wrong - Please check my code below.
Best regards
Gustav


=========Part of my code ===========================================


-------------------------------------SETTING UP THE SCROLL VIEWS---------------------------------------------
1.
CCMDIChildWnd code that sets up the CCSplitterWnd scroll views:
______________________________________________________

IMPLEMENT_DYNCREATE(CChildFrame, CMDIChildWnd)

// CChildFrame construction/destruction

BOOL CChildFrame::OnCreateClient(LPCREATESTRUCT /*lpcs*/, CCreateContext* pContext)
{

if(!m_wndSplitter.CreateStatic(this,2,2)||
/* THESE 2 PANES DO NOT NEED TO ACCESS THEIR PARENT - SO NO PROBLEM HERE*/
!m_wndSplitter.CreateView(0,0,RUNTIME_CLASS(CCurrent_pane_view),CSize(this->ParentWidth,20),pContext)||
!m_wndSplitter.CreateView(0,1,RUNTIME_CLASS(CRef_pane_view),CSize(CSize(this->ParentWidth,20)),pContext)||
/*!!!!!!!!! THESE TWO PANES WILL BOTH CRASH ...*/
!m_wndSplitter.CreateView(1,0,RUNTIME_CLASS(CCurrentFileView),CSize(this->ParentWidth/2,0),pContext)||
!m_wndSplitter.CreateView(1,1,RUNTIME_CLASS(CReference_File_View),CSize(this->ParentWidth/2,0),pContext))
return FALSE;

return TRUE;
}
----------------------THE CSCROLLVIEW CLASS-------------------------------------------------------------------
2:
The CScrollView code that always crashes:
_________________________________

IMPLEMENT_DYNCREATE(CCurrentFileView, CScrollView)

CCurrentFileView::CCurrentFileView()
{
/* HERE WE GET AN ASSERTION ERROR EACH TIME! APPARENTLY MY CLASS HAS NO IDEA OF WHO OWNS IT? */

CWnd* ParentWnd=this->GetParent();

/* PROGRAM CRASHED NOW....*/

if(ParentWnd!=NULL)
{
ParentWnd->SendMessage(MSG_SET_REF_POINTER,NULL,NULL);

}

Take a look here: http://www.codeguru.com/cpp/w-d/splitter/


I was doing some splitter stuff last week, but I'm a SDI kind of guy :)

Quote:

---

Originally Posted by Gustav_sf

The CScrollView code that always crashes:
_________________________________

IMPLEMENT_DYNCREATE(CCurrentFileView, CScrollView)

CCurrentFileView::CCurrentFileView()
{
/* HERE WE GET AN ASSERTION ERROR EACH TIME! APPARENTLY MY CLASS HAS NO IDEA OF WHO OWNS IT? */

CWnd* ParentWnd=this->GetParent();

/* PROGRAM CRASHED NOW....*/

if(ParentWnd!=NULL)
{
ParentWnd->SendMessage(MSG_SET_REF_POINTER,NULL,NULL);

}

---

It sounds like your CCurrentFileView window had not been created at the moment you created the splitter window (and this has nothing to do with the RUNTIME_CLASS at all!)

Why do you try to access the parent of your CCurrentFileView window while this window does NOT exist? :confused:

Hello VictorN!
Thank you for your reply, you are absoluttely right about that the CCurrentFileView class is initiated as part of the creation of the CSplitterWnd, and of course CCurrentFileView can not start
to query about it's parent when the parent is still under 'construction'. So it is clear to me why the application crashes.
On the other hand, I still need to find out how I can get a pointer from my CChildFrame window to the CCurrentFileView, that is initiated as a CRUNTIMECLASS. What can I do ?
Hope you still want to help me....
Best regards
Gustav

Can you post your app, or at least the part that brings up or tries to bring up the screens?

Hello ADSOFT & VictorN!
The app is just too massive, so it makes no sense passing it on, but thanks for the offer to review ADSOFT! I am still studying the references you pointed out earlier.
Anyway, I have worked on with VictorN's comment on that the CSplitterWnd needs to be instantiated before any parent to the CCurrentFileView class can be identified.
If I call GetParent() from CCurrentFileView's OnDraw() method, then I am actually getting a pointer
to the parent of CCurrentFileView, which of course is the CSplitterWnd that has instantiated at this point. Then I can pass the pointer on to the parent of the CSplitterWnd. The parent is the
CChildFrame window. So in this way one can say that the problem is solved. I am using SendMessage() to pass on the pointer to the parent(s).......
I am JUST NOT HAPPY with the solution as e.g. it is invoked from CCurrentFileView's OnDraw() method which is called a trillion times during app execution. Then also, I do not like too much 'SendMessage stuff' in my programs. I just do not like this solution.
Is'nt there a way to get the pointer to CCurrentFileView directly from the CChildFrame , after the CSplitterWnd and CCurrentFileView have instantiated ?
I am still wondering about the CRUNTIMECLASS, if it is'nt possible to somehow address it to get the pointer at the time when the CChildFrame instantiates CSplitterWnd and CCurrentFileView?
Pls. give me more input:-)
Best regards
Gustav

Hello!
After further checking up on the problem I managed to get the right solution - I think.
Having instantiated the CSplitterWnd panes, I can actually get a pointer to their views using
something like in the CChildFrame window:

CWnd* CurFileView=m_wndSplitter.GetPane(1,0);

Then I can address the CCurrentFileView view created as a CRUNTIME_CLASS and the problem seems to be solved!

VictorN & ADSOFT: thank you for contributing.
Best regards
Gustav

Glad to hear it.

I wanted to get more into this thread, I'm just not a MDI type, .... and you probobly don't want to hear my SDI talk :lol:


I'm glad you got it solved.

It's sounds right because when I was building the MULTIVIEW sample, I had to copy reference (..i.e., #Includes) to all my Views; Obvioulsy they where being referenced in those classes. I just don't remember if it was in the Application Class or the MainFrame Class, I would have to dig up the project, .. but then it would require SDI , so you know how it is.

Anyhow, I'm glad it's working for you.