Hi there, I'm new to C++ and am using Visual Studio 2010 Professional. I've been using dialog based apps until now and have been doing ok, but now I need to make an app that handles multiple items at once. So the multiple documents application type seemed like a natural choice.
I am, however, having trouble figuring something out. After creating my first skeleton app it starts with a blank document open. However, I haven't figured out how it's opening that document, and I don't want the app to start with an open document.
My skeleton project was created by making the following selections (only specifying changes from the default):
MFC app (let's name it skeleton)
Multiple Document, uncheck tabs
MFC Standard project style
Now, if I go into the skeletonView.cpp file that was created for me, and set a breakpoint in it's constructor, I can see that it's being called from:
in skeletonApp::InitInstance(). But that's about all I can figure out so far. I can see where this skeletonView is being added to a template, and where the template is being added to the main window, but from my understanding this just lets the main window create instances of the view.
I'm sure I'm missing something simple. Anyone care to enlighten me?
Oh, just as an addendum, commenting out the ProcessShellCommand line does make the window go away with seemingly no ill effects, but I don't understand why there would be a directive in there to open a new window in the first place.
I don't really like doing things that I don't understand, so basically I'd like to find out if commenting it out is the right thing to do or if I need to do something else. (And why?)
Well, that's how I figured out that it was being called from skeletonApp::InitInstance().
I can see that the code is originally starting in wWinMainCRTStartup and so forth, but I didn't think that it was useful information. The ProcessShellCommand line in InitInstance is the first of my app's code that appears in the stack trace.
Would it help if I posted a stack trace?
What it looks like to me is that the cmdInfo contains a new window message (probably intended to start up the main window), and the default code generated by the wizard is passing that along to generate a child window. But I'm not sure of this.
Probably you want to know where the view window is created.
Well, the view class constructor is not the right place to find it.
That window is created a little bit later by calling Create function.
So, a better place for the breakpoint is, for example, the overridden function PreCreateWindow, which is called by the MFC framework just before the window is created.
Then step until reach a call to CWnd::Create.
I put a breakpoint in PreCreateWindow as you suggested, and it looks like Create calls CreateEx which calls PreCreateWindow. Tracing it further back (skipping many steps) we get right back to the ProcessShellCommand command in InitInstance.
So the same ProcessShellCommand command ends up doing the PreCreateWindow as well as the constructor, which still brings me back to my original problem: Is this ProcessShellCommand just there to spawn a default window or does it have other purposes? Why does the CCommandLineInfo (cmdInfo) contain a new window message?
I guess what it comes down to is it looks to me like they got a new window message that was intended to spawn the main window, and then they reused it to spawn a child window. But without explicitly telling us they're doing that, that seems... bad. The comments for that line just say "Dispatch commands specified on the command line". But I didn't specify anything about a new document in any command lines that I know of (is there a "commandline input" settting somewhere in VC10?).
So I see one of two things:
1) The comment is correct, and I need to find somewhere else to disable the initial new document (say, if there is a commandline setting I need to fiddle with, or overload some function somewhere)
2) The comment is garbage, and they're just throwing around a message they're getting from somewhere else as a convenient way of causing a new window.
So I'm inclined to believe option 1), but that puts me back at not understanding where the window is coming from.
For a MFC-beginner, the main priority is to learn how to use the framework as it is and extend it by using good wizards.
Further, can modify some default framework behaviors by overriding MFC classes virtual functions.