Accessing another classes variables

[minifiredragon]

Ok, this is more or less a continuation of the winsock question. Through looking over some working programs I have found that I needed to establish a pointer to the CICServerDoc class. All my work is being done in the CICServerView class since I have it linked into a database.

I searched through this forum and found something I thought might help me:

CICServerDoc * pPointer = (CICServerDoc*)GetParent();
CString testing = pPointer->m_test;

but it gives a badpointer error when I try to get the information from a variable in the CICServerDoc class. I know it is a basic question and it is probably somewhere in my brain, but for the life of me I can not figure out how transfer data back and forth between classes.

I had no problems with the classes I created (mostly dialog).

I did the follow:

CInsertDlg dlgInsert;
dlgInsert.m_strTest = test;//send a variable to another class)
dlgInsert.DoModal;

and if I wanted to get the variable later, I called:

mytest = dlgInsert.m_strTest;

But since I am not to clear on how the CICServerView was created, I don't have a clue to how to get a public variable from in, while in the CICServerDoc and vise versa.

I did a test with:

CICServerDoc * pPointer = (CICServerDoc*)GetParent();
CString testing = pPointer->m_test;

but set it up as an int, and stored 56 in it, and it passed only a 6. So I am now scratching my head. Once I get over this hurdle I think I am in the home stretch. I finsihed the 1st App I have been asking questions about earlier and it works better then I'd expected. I am now adding winsock support so it can exchange short, no more then 32 chars between 2 programs.

and if I ever wanted to

 

[PerFnurt]

The doc is not the parent of the view.
The view has a GetDocument() method though...

They have an subject-observer relation. See Observer pattern in "Design Patterns" by GoF (one of the few book I consider a MUST to have read).

Your
CICServerDoc * pPointer = (CICServerDoc*)GetParent();
actually illustrates how dangerous it is to do c-style casting, since you erroneously cast from one class to another.

If you instead had done a dynamic cast, pPointer would have been NULL, which you could handle/check in your code (ASSERT(pPointer!=NULL)) as it is indeed be a programmatical error (aka bug) to cast wildly...

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[minifiredragon]

GoF? Can you list the books you consider to be of Help?? I been to Borders Books and Music and have all the pertinent books on Visual C++, but that doesn't mean they had the good books.

 

[PerFnurt]

>GoF?
&quot;Gang of Four&quot;:
1. Erich Gamma
2. Richard Helm
3. Ralph Johnson
4. John Vlissides

http://hillside.net/patterns/DPBook/DPBook.html

>Can you list the books you consider to be of Help

It's a generic question, and hard to answer, besides &quot;Design Patterns&quot; (which I consider a must) I'd also definately recommend
&quot;Writing solid Code&quot;

http://www.amazon.com/exec/obidos/ASIN/1556156502/ref=sim_books/104-5977491-1879169

Some other nice books:
&quot;Essential C++&quot;

http://www.amazon.com/exec/obidos/tg/detail/-/0201485184/104-5977491-1879169?v=glance

&quot;More exceptional C++&quot;

http://www.amazon.com/exec/obidos/tg/detail/-/020170434X/104-5977491-1879169?v=glance

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}

 

[minifiredragon]

Excellent. I will try and acquire these. But at the moment, perhaps you can answer something for me. I am trying to trace the order of which an MFC applications start and the &quot;Main()&quot; part of the application.

As far as I can tell, it starts with:
MainAPP

which creates a:

MainFrame
MainView
MainDoc

which then call the additional classes. And they communicate by grabbing pointers to the other classes they need.

Correct or not?

 

[PerFnurt]

MainApp is the (one and only) application instance.

MainFrame is the window (a.k.a graphical thingie) of your application.

The Document is the class &quot;owning&quot; the views and internally it has a list of its views. It sends information to them by calling UpdateAllViews method.

The Views are windows (somewhere in the MainFrame) showing the document's data in some manner. Excactly how to show it is up to the specific view.

The GetParent method is a window (a.k.a graphical thingie) related gizmo, not to be confused with the document-view relationship, which isnt.

>And they communicate by grabbing pointers to the other classes they need
You could say that. The grabbing is hidden somewhere down in MFC though, you usually don't have to think about it.

The UpdateAllViews call mentioned above resolves in a call to each view's OnUpdate mathod (which you thus should override to do your stuff). Each view can access its document by a GetDocument method.

You could see it as the views are subscribing on events that are sent by the document class.

Not sure this makes sense, it's all probably better explained in a MFC book. The only one Ive read is &quot;Inside Visual C++&quot; for VC++ 5.0 but its kinda old these days. It explained it fairly well though, perheps there's a newer one out there...

/Per

_{if (typos) cout << &quot;My fingers are faster than my brain. Sorry for the typos.&quot;;}