Re: Lost WM_COMMAND message?

The problem here is that this is sent before lots of context is established. Even after
the frame window is created, I would feel more comfortable doing a PostMessage

More below...
On Thu, 01 Nov 2007 14:45:19 -0000, Alex Y Wang <redflyingpig@xxxxxxxxx> wrote:

Hi, I'm not quite familiar with MFC yet I need to maintain this large
MFC project. Our program is a typical MDI program but in certain
occasions we need to use it simply as a document previewer. Thus the
program needs to enter 'preview' mode on startup, so I did this in
InitInstance:

m_pMainWnd->SendMessage(WM_COMMAND, ID_FILE_PRINT_PREVIEW);

before drawing the window. Then I customized the preview toolbar with
my own class derived from CPreviewView. This in turn requires the
'print' and 'close' button on the preview toolbar to be customized -
because they used to close the preview frame and return to the parent
frame, which in this case doesn't exist. So I rewrote the
CPreviewView::OnPreviewPrint method like this (similar with the above
code used in InitInstance):

CWinThread *pThread = AfxGetThread();
CWnd *pMainWnd = pThread->m_pMainWnd;
pMainWnd->SendMessage(WM_COMMAND, ID_FILE_PRINT);
****
You need to show where this is relative to the rest of the startup. My own preference
would be to have a CMultiDocTemplate which was not registered with AddTemplate, and just
instantiate a document/view with this.

Given you are in the main thread of the app, there is little reason to write code this
complex. You could use
CWnd * MainWnd = AfxGetApp->m_pMainWnd;
which is easier to write and understand, and it always works right. But I would not send
print messages to the main window, since it has no idea how to print; I'd just implement
it in the view as would be normal.

There's no reason to invent complicated mechanisms to solve simple problems; print with
doc/view works fine, so all you need to do is force the print preview mechanism for a
standard doc/view, and not invent complicated schemes.
*****

hoping to print without closing the preview frame.

But it doesn't work. Where am I doing wrong? Any help will be
appreciated!
****
There are lots of interpretations of "doesn't work". For example, you claim in the header
that the message is lost. Are you sure it is lost? Does Spy++ tell you if the message
arrived? If it arrived, it is not lost, but then you have to make sure you have a handler
for it. Note that WM_COMMAND messages are routed, so it might be intercepted somewhere
else and discarded because the frame is one of the last places that can handle it. If any
class sees it first, it will be dispatched to the default handler for that class, and if
that handler does nothing, too bad, the message has been handled. It isn't lost, it is
properly handled, by a mechanism that does nothing.

I'm not sure why a message to the main frame is required at all. I think there are
simpler techniques that can do this, but I've not looked into the details.
joe
****

Alex Y. Wang
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.