How to call OnFileNew() from a dialog box in MFC VC++?

I am using a MDI application project.

I need to open an new file/document when a button in a dialog box is clicked..

How to call the OnFileNew() or is there any other way to open a new document?

(I also have some other actions to be performed when the button is clicked like closing the dialog..
So, creating a new document is to be 1 of the statement)

I am running into a deadline to finish my project..

Please help me.... Thank u...

You can post a WM_COMMAND message with ID_FILE_NEW to the main window.

You can also set a pointer to your View Class and then call FileOpen, however if you FileOpen function is set to Protected you must make it public.

Cilu approach is easier, but you are limited to only access the FileOpen, and you have to transmit a message for every function, and I'm pretty sure you are limited to only funtions that have a message attached to them.

If you want access to all the functions in View Class and it's variables (The ones that are or are made to be public) then having a pointer to the view class is cool.

I always create a global pointer to my View, defined just beneath the
"theApp" global var , class so that I can access any Function, Var or even another Dialog Box that
is a member of the View. Having access to a View pointer pretty much gives you access to the whole App.


i.e

Code:

---


In the App file

CMyApp theApp;
CMyView *gpView; //Define a Global pointer to my view class


In the View Cpp file:

extern CAUTOWEBView *gpView;

void CMyView::OnInitialUpdate()
{
        ...

        ::gpView = this;  //Initialize the Global Pointer

}


Don't forget to in Include header files in you to your View Class in
your Dialog CPP files and the Extern statement too.

---

If you have a lot of Dialog boxes in a App with a CView derived Class as the Client Area, I found this to come in handy:)

Quote:

---

Originally Posted by ADSOFT

You can also set a pointer to your View Class and then call FileOpen, however if you FileOpen function is set to Protected you must make it public.
...
If you want access to all the functions in View Class and it's variables (The ones that are or are made to be public) then having a pointer to the view class is cool.

I always create a global pointer to my View

---

What a bad idea to "create a global pointer to ... View" class! :thumbd:
The fact it might work in some rare situations (like in a simple SDI application with ONLY one View class) does NOT mean this approach is reliable.
In fact it is NOT! This won't work in either MDI or in SDI app with multiple Views.
It also contract the basic OOP principle

So, never just try it!

Quote:

---

Originally Posted by VictorN

What a bad idea to "create a global pointer to ... View" class! :thumbd:
The fact it might work in some rare situations (like in a simple SDI application with ONLY one View class) does NOT mean this approach is reliable.
In fact it is NOT! This won't work in either MDI or in SDI app with multiple Views.
It also contract the basic OOP principle

So, never just try it!

---

:confused::confused: I think you're confused and you have to think before you type.

Obviously if you have multiple Views you are going to need multiple pointers to your views. And for your information nothing in life works for every situation, so .... get a clue!!!!


And furthermore if you have multiple views they each have their own OnPrint function!!!! .... stick that in your pipe and smoke it.

So if you want to access OnPrint, you have to know which View's OnPrint your dealing with, Sending a message works, but it's only going to work for that particular View, if you have multiple views that is not GUARNTEED to work either.

... YOU HAVE TO KNOW WHAT VIEW YOU'RE TALKING ABOUT :wave:

Quote:

---

Originally Posted by ADSOFT

:confused::confused: I think you're confused and you have to think before you type.

Obviously if you have multiple Views you are going to need multiple pointers to your views. And for your information nothing in life works for every situation, so .... get a clue!!!!


And furthermore if you have multiple views they each have their own OnPrint function!!!! .... stick that in your pipe and smoke it.

So if you want to access OnPrint, you have to know which View's OnPrint your dealing with, Sending a message works, but it's only going to work for that particular View, if you have multiple views that is not GUARNTEED to work either.

... YOU HAVE TO KNOW WHAT VIEW YOU'RE TALKING ABOUT :wave:

---

He does know what he's talking about. A global pointer to a view is a really bad idea. Views come and go as documents are open and closed. Trying to keep the global pointer current sounds like way more trouble than it's worth. MFC provides mechanisms to get the active view from anywhere in the app, and to get all the views associated with a document. It's folly to try to maintain that yourself when MFC does it for you and does it reliably.

Quote:

---

Originally Posted by GCDEF

He does know what he's talking about. A global pointer to a view is a really bad idea. Views come and go as documents are open and closed. Trying to keep the global pointer current sounds like way more trouble than it's worth. MFC provides mechanisms to get the active view from anywhere in the app, and to get all the views associated with a document. It's folly to try to maintain that yourself when MFC does it for you and does it reliably.

---

If you get a pointer to the active view you still have to type cast it to your view type.


How is MFC going to know what particular functions you have in your View?

You can always initialize you pointer to NULL and know if it's been initialized.

And by the way, if you want to access a particular view, now that I think about it, who says it has to be active??? It just has have been created! It could be sitting in memory somewhere and you are accessing, some of it's components.


What I'm getting at is that if you do decide to get the Active View anywhere in the App via:

Code:

---

::AfxGetApp()->GetMainWnd()->GetParentFrame()->GetActiveView();

---

... what is your next step?

Quote:

---

Originally Posted by ADSOFT

If you get a pointer to the active view you still have to type cast it to your view type.


How is MFC going to know what particular functions you have in your View?

You can always initialize you pointer to NULL and know if it's been initialized.

And by the way, if you want to access a particular view, now that I think about it, who says it has to be active??? It just has have been created! It could be sitting in memory somewhere and you are accessing, some of it's components.


What I'm getting at is that if you do decide to get the Active View anywhere in the App via:

Code:

---

::AfxGetApp()->GetMainWnd()->GetParentFrame()->GetActiveView();

---

... what is your next step?

---

Why does MFC have to know what functions are in your view?

As I said, you can get all the views not just the active one, but usually that's the one you want.

How does initializing to NULL help? Every time the framework opens or closes a document, changes the active view, etc. you need to update your pointers. It's really sounding like you're not really sure how the doc/view architecture works and how to use it properly.

Quote:

---

Originally Posted by GCDEF

Why does MFC have to know what functions are in your view?

As I said, you can get all the views not just the active one, but usually that's the one you want.

How does initializing to NULL help? Every time the framework opens or closes a document, changes the active view, etc. you need to update your pointers. It's really sounding like you're not really sure how the doc/view architecture works and how to use it properly.

---

Why does MFC have to know?? If you want to access a function that you defined in for your view you're going to have to tell MFC. So you have to have to type cast the active view everytime you access it view MFC general functions. If I have to access the Active View several times within a dialog box, after a while you're going to realize that it would be lot easier to just have a pointer to the View Class. Why call all those MFC functions everytime and then do a type cast. A pointer would save you time and save the app from computational overhead.


And regarding the null pointer, once the View is activated, it will not return a null, so what I ment was that checking for a Null value on the pointer will let you know if it's active.

When you have mutliple views you have to keep track of your pointers anyway. MFC is not going to manage your views for you.

It sounds to me like you haven't done much coding in situations where you have many dialog boxes at multiple levels initiated from a view class. Having a pointer to your view comes in very handy. I'm not going to go through:

Code:

---

(MyView*)(:AfxGetApp()->GetMainWnd()->GetParentFrame()->GetActiveView())->MyFunction();

---

... or something close to that, evertime I have to access a particular view from a dialog box :rolleyes:

Code:

---

gpMyView->Myfunction(); // Is a lot better.
gpMyView->MyVar = ...    // "   
gpMyView->OnFileNew();              "

---

That's what I'm talking about!

Quote:

---

Originally Posted by ADSOFT

What I'm getting at is that if you do decide to get the Active View anywhere in the App via:

Code:

---

::AfxGetApp()->GetMainWnd()->GetParentFrame()->GetActiveView();

---

... what is your next step?

---

Next step:

Code:

---

    if(pActiveView && pActiveView->IsKindOf(RUNTIME_CLASS(CMyDesiredView)))
    {
        AfxMessageBox(_T("Boo!!! ;-)"));
        ((CMyDesiredView*)pActiveView)->...
    }

---

Quote:

---

Originally Posted by ADSOFT

Why does MFC have to know?? If you want to access a function that you defined in for your view you're going to have to tell MFC. So you have to have to type cast the active view everytime you access it view MFC general functions. If I have to access the Active View several times within a dialog box, after a while you're going to realize that it would be lot easier to just have a pointer to the View Class. Why call all those MFC functions everytime and then do a type cast. A pointer would save you time and save the app from computational overhead.


And regarding the null pointer, once the View is activated, it will not return a null, so what I ment was that checking for a Null value on the pointer will let you know if it's active.

When you have mutliple views you have to keep track of your pointers anyway. MFC is not going to manage your views for you.

It sounds to me like you haven't done much coding in situations where you have many dialog boxes at multiple levels initiated from a view class. Having a pointer to your view comes in very handy. I'm not going to go through:

Code:

---

(MyView*)(:AfxGetApp()->GetMainWnd()->GetParentFrame()->GetActiveView())->MyFunction();

---

... or something close to that, evertime I have to access a particular view from a dialog box :rolleyes:

Code:

---

gpMyView->Myfunction(); // Is a lot better.
gpMyView->MyVar = ...    // "   
gpMyView->OnFileNew();              "

---

That's what I'm talking about!

---

Or you could just write a function that uses the framework to get your view and does the cast in the function. You call your function, no casting necessary.

The point I'm trying to make is MFC manages the pointers for you. You close a document and open a document, you have a different view object. You have to manage that yourself. Why duplicate what MFC is already doing?

OnFileNew is typically handled by the app class. If you're doing it from the view, you're overriding standard doc/view behavior, and while that may work for you, it's probably not a good general purpose solution.

Quote:

---

Originally Posted by ADSOFT

Code:

---

gpMyView->Myfunction(); // Is a lot better.
gpMyView->MyVar = ...    // "   
gpMyView->OnFileNew();              "

---

---

Are you trying to teach us "C Programming in CPP files"? :)

GCDEF

I agree that having a global pointer to a view class is not going to work in MDI case, it does cut down a lot of work in SDI's which is what I mostly work on.

Having a function to return a pointer in every dialog box that returns a pointer to it's view class is too much overhead.

Creating a member variable in each Dialog that points to it's base View might work better.

Anyhow, this discussion is off-topic, the OP having nothing in common with a view or an active view.

Quote:

---

Originally Posted by ADSOFT

GCDEF

I agree that having a global pointer to a view class is not going to work in MDI case, it does cut down a lot of work in SDI's which is what I mostly work on.

Having a function to return a pointer in every dialog box that returns a pointer to it's view class is too much overhead.

Creating a member variable in each Dialog that points to it's base View might work better.

---

I didn't say put a function in every dialog, I said, or meant, set up a global function that uses the framework to get the view pointer, returning the type that's appropriate for your app. Done properly, it will work for SDI or MDI.

Quote:

---

Originally Posted by ovidiucucu

Anyhow, this discussion is off-topic, the OP having nothing in common with a view or an active view.

---

Good point, as OnFileNew is a CWinApp function, not a CView function.

AfxGetApp()->OnFileNew() should do the trick.

Returning on-topic.
As already stated here before (by GCDEF), usually in an MDI/SDI application, the wizard maps the ID_FILE_NEW command as follows...

Code:

---

BEGIN_MESSAGE_MAP(CMyApp, CWinApp)
    ON_COMMAND(ID_FILE_NEW, &CWinApp::OnFileNew)
//...
END_MESSAGE_MAP()

---

...which simply calls the base class OnFileNew method (CWinApp::OnFileNew).

If someone really wants to modify the default implementation and/or add something, it has to:

• modify ON_COMMAND macro removing the base class call
  
  Code:

  ---

  ON_COMMAND(ID_FILE_OPEN, &OnFileNew)

  ---

• declare and implement OnFileNew handler function in its own CWinApp-derived class
  
  Code:

  ---

  class CMyApp : public CWinApp
{
public:
    afx_msg void OnFileNew();
//...
};

  ---

  Code:

  ---

  void CMyApp::OnFileNew()
{
    CWinApp::OnFileNew(); // call base class method and / or...
    // ...add other tasks here.
}

  ---

Further, if really, really wants to call CMyApp::OnFileNew anywhere in the application, simply has to write something like this

Code:

---

    CMyApp* pApp = (CMyApp*)AfxGetApp();
    if(pApp)
    {
        pApp->OnFileNew();
    }

---

or

Code:

---

    theApp.OnFileNew();

---

// no matter which is the active view, the framework will correctly do its job.

Quote:

---

Originally Posted by GCDEF

Good point, as OnFileNew is a CWinApp function, not a CView function.

AfxGetApp()->OnFileNew() should do the trick.

---

:confused: Sorry,

error C2248: 'OnFileNew' : cannot access protected member declared in class 'CWinApp'


... I tried it, didn't work.

Quote:

---

Originally Posted by ADSOFT

:confused: Sorry,

error C2248: 'OnFileNew' : cannot access protected member declared in class 'CWinApp'

---

Yes, of course!
Message handlers have to be protected member functions in a class.
Therefore cilu suggested you to use SendMessage! :cool:

Quote:

---

Originally Posted by ADSOFT

:confused: Sorry,

error C2248: 'OnFileNew' : cannot access protected member declared in class 'CWinApp'


... I tried it, didn't work.

---

Guess you need to override it then to call it directly, or as cilu pointed out in the first reply in this thread, send a message.

Quote:

---

Originally Posted by VictorN

Yes, of course!
Message handlers have to be protected member functions in a class.
Therefore cilu suggested you to use SendMessage! :cool:

---

No kidding Albert Einstien :rolleyes: :thumbd:

Quote:

---

Originally Posted by ADSOFT

:confused: Sorry,

error C2248: 'OnFileNew' : cannot access protected member declared in class 'CWinApp'


... I tried it, didn't work.

---

That's because, again, you do not (want to) read all the replies.
http://www.codeguru.com/forum/showth...05#post1832805

Guys, thanks for all of ur replies..

But i asked how open a new document when a button in the dialog box is clicked...
And i am just a basic programmer in MFC..

I created my own dialog box with a button.. and need to open the new doc from there..

Can u help me with that?

Quote:

---

Originally Posted by krishna_kumar

Guys, thanks for all of ur replies..

But i asked how open a new document when a button in the dialog box is clicked...
And i am just a basic programmer in MFC..

I created my own dialog box with a button.. and need to open the new doc from there..

Can u help me with that?

---

That's been answered several times in this thread. The first reply told you what to do.

Dear krishna_kumar!
As cilu already wrote in the post#2:

Quote:

---

Originally Posted by cilu

You can post a WM_COMMAND message with ID_FILE_NEW to the main window.

---

For example, you could place this line somewhere within your dialog:

Code:

---

AfxGetMainWnd()->SendMessage(WM_COMMAND, ID_FILE_NEW);

---

Quote:

---

Originally Posted by ovidiucucu

That's because, again, you do not (want to) read all the replies.
http://www.codeguru.com/forum/showth...05#post1832805

---

:rolleyes: The point I was trying to make there is that his advise doesn't work, and that he should try the code before he posts it.


....obviously it's going to take more than sending a message from a non-member function because the OnFileNew base class function is PROTECTED!!!!!!!!!!!!!

Quote:

---

Originally Posted by ADSOFT

:rolleyes:
....obviously it's going to take more than sending a message from a non-member function because the OnFileNew base class function is PROTECTED!!!!!!!!!!!!!

---

What does "sending a message from a non-member function" have to do with the declaration type (public/protected/private) of CWinApp::OnFileNew message handler? :confused:

Quote:

---

Originally Posted by ADSOFT

:rolleyes: The point I was trying to make there is that his advise doesn't work, and that he should try the code before he posts it.


....obviously it's going to take more than sending a message from a non-member function because the OnFileNew base class function is PROTECTED!!!!!!!!!!!!!

---

You're taking this a little too seriously. So, it was protected. Override it or send a message. What's the big deal? The point remains that OnFileNew is an app function, not a view function, and that maintaining a global pointer to a view wasn't a particularly good solution to the problem. Don't take it so personally.

Quote:

---

Originally Posted by GCDEF

You're taking this a little too seriously. So, it was protected. Override it or send a message. What's the big deal? The point remains that OnFileNew is an app function, not a view function, and that maintaining a global pointer to a view wasn't a particularly good solution to the problem. Don't take it so personally.

---

I thought we all agreed that OnFileNew was an App function, it was an oversite on my part thinking it was part of the View, that's why we got back on topic. I had a simular situation arise when I had to print from Dialog boxes in my app, at first I sent messages then created a pointer to the View, so I could print from anywhere in the app; .... so sorry for the confusion on that part.


Yes the function is protected and if I would have addressed the problem without mentioning that, then some of these guys would have raised a storm.

Thanks a lot guys...

I have to check the coding.. No, i have to implement that coding..

U guys cleared my problem... That means a lot to me...

Thank u...