From: Jd on
On Apr 20, 6:20 pm, Mikel Luri <mikel.luri_NOS...(a)gmail.com> wrote:
> El 20/04/2010 10:29, Mikel Luri escribió:
>
>
>
> > El 20/04/2010 9:56, Mikel Luri escribió:
> >> El 20/04/2010 7:20, Jd escribió:
> >>> I have an SDI application with multiple views. By default, it creates
> >>> a new document when the application starts. I want to modify this
> >>> behavior so that a new document is created only when user explicitly
> >>> clicks on "New". Or at least mimic this behavior.
> >>> I am using Visual Studio 2008 with MFC feature pack.
> >>> I googled and found some solution to this problem in an old MS Journal
> >>> article.
> >>>http://www.microsoft.com/msj/archive/S204D.aspx
> >>> But unfortunately it doesn't seem to work now, because framework is
> >>> sending the command ID_FILE_NEW instead of calling the virtual
> >>> function OnFileNew().
> >>> Any workarounds or solutions?
>
> >>> In short, I need to differentiate between framework call to
> >>> OnFileNew() and User Click on New.
>
> >>> Is this a correct approach/design/choice in first place?
>
> >>> TIA,
> >>> Jd
>
> >> Does that even make sense? I think you cannot have an SDI without a
> >> document.
> >> But you can have a MDI with a 1 document limit though, and you can
> >> prevent a new document from opening at startup with MDI (just as
> >> explained in the link you provide)
> > Sorry, I've taken a better look at the link and I see it refers to SDI.
> > Well, maybe they've changed something and that's why it doesn't work.
> > Sorry again
>
> It's me again.
> I've been reading carefully the article you linked to, while doing what
> it says in a little test app, and it seems like the command routing
> doesn't work as stated in the article, at least while initializing the app.
>
> Specifically, we can see:
> BOOL CWinApp::ProcessShellCommand(CCommandLineInfo& rCmdInfo)
> {
>          BOOL bResult = TRUE;
>          switch (rCmdInfo.m_nShellCommand)
>          {
>          case CCommandLineInfo::FileNew:
>             if (!AfxGetApp()->OnCmdMsg(ID_FILE_NEW, 0, NULL, NULL))
>                 OnFileNew();
>             if (m_pMainWnd == NULL)
>                 bResult = FALSE;
>             break;
> [...]
>
> }
>
> So it seems that ProcessShellCommand sends directly a ID_FILE_NEW
> command to the App, thus invalidating Paul's workaround.
>
> A possible solution would be to make that particular call to OnCmdMsg
> return FALSE.
> To do so, you can declare a member variable in your app class, say
> m_bInit, which would be FALSE until the end of InitInstance, where you
> set it to TRUE, and override OnCmdMsg. If m_bInit is FALSE, (and the
> command ID is ID_FILE_NEW) you return FALSE, otherwise, you call your
> base class' OnCmdMsg.
> I've tried it and in seems to work. OnMyNewFile does not get called
> until the user asks for a new file.
>
> I'm not sure it's the best solution, though. If I had to do it, I would
> probably take the MDI route, setting a 1 document limit and doing the
> "cmdInfo.m_nShellCommand = FileNothing;" thing.

Hello Mike,
Thanks for the workaround. Its working :-)
I guess when that MS Journal article was published, the framework used
to call the virtual function. But now it sends a message instead.
And your tip beautifully workarounds the problem.
Once again thanks a ton!!

Jd
From: Jd on
On Apr 20, 10:54 pm, Goran <goran.pu...(a)gmail.com> wrote:
> On Apr 20, 3:53 pm, Goran <goran.pu...(a)gmail.com> wrote:
>
> Whoops! Copy-pasted MFC code (the "no magic" part) went out horribly.
> Sorry 'bout that.
>
> Goran.

Dear Goran,
Thanks for the solution :) I'll try it out.
Why I chose this "No document on startup" idea, is that my app has
some more features, which doesn't depend on the document.
User can use the same application for creating a configuration file or
can use it for status monitoring.
I am not sure if my idea is correct though.


Jd..
From: Goran on
On Apr 21, 2:39 am, Jd <j.durgapra...(a)gmail.com> wrote:
> Why I chose this "No document on startup" idea, is that my app has
> some more features, which doesn't depend on the document.
> User can use the same application for creating a configuration file or
> can use it for status monitoring.

Ok, but what's wrong with creating your file while you have e.g. an
empty new document open? I don't see the relation between the two. I
don't quite understand what you mean by "status monitoring", but
again, isn't this also orthogonal to the doc? I have a similar app
(speaks to embedded devices over a proprietary protocol over a serial/
TAPI/TCP connection), and that indeed is orthogonal to the document in
our case.

Goran.
From: Goran on
On Apr 21, 4:56 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> What the OP is asking is how to have an app that allows for either of two types of
> documents to be created, at the user's request, instead of creating only one type of
> document by default.  The techniques discussed earlier are what are required.
>                                         joe

Well, it doesn't seem so. Ï understood it as needing to modify a
config file for the whole app (some kind of "options" command an such)
- happens all the time. It's an overkill to introduce another doc type
for that.

Goran.
From: Goran on
On Apr 22, 4:14 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> Actually, I did this some years ago.  The "config" file was an external file that
> specified the properties of a remote embedded system.  The other type of documeht actually
> communicated to a remote embedded system.

Well, for an SDI application, it's either one doc type open, or the
other. I still think it's an overkill.

One can just "edit" the "config" file from "options" dialog or some
such, without reaching for a second DocTemplate.

Goran.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: VS2010 help viewer
Next: Adding Edit Control to MainFrame.