发ID_FILE_PRINT消息打印，如何屏蔽'打印'设置对话框而直接打印

[vc8fans]

在VC框架中发ID_FILE_PRINT消息直接打印，每次都先弹出"打印"窗口，选打印机，纸张，打印数量，
其实在打印直接已经是默认的了，如何屏蔽这个每次都弹出的'打印'设置对话框而,, 而直接打印输出，？？？？
这个就可以在后台打印了，否则每次打印都先弹出这个对话框，都要按确定键，，很头疼

[schlafenhamster]

不是有个: "ON_COMMAND(ID_FILE_PRINT_DIRECT, CView::OnFilePrint) //直接打印 没有打印设置框"

[schlafenhamster]

引用:

#0001 void CView::OnFilePrint()
#0002 {
#0003      // get default print info
#0004    CPrintInfo printInfo;
#0005      ASSERT(printInfo.m_pPD != NULL);    // must be set
#0006
#0007      if (GetCurrentMessage()->wParam == ID_FILE_PRINT_DIRECT)
#0008      {
#0009          CCommandLineInfo* pCmdInfo = AfxGetApp()->m_pCmdInfo;
#0010
#0011          if (pCmdInfo != NULL)
#0012          {
#0013              if (pCmdInfo->m_nShellCommand == CCommandLineInfo::FilePrintTo)
#0014              {
#0015                  printInfo.m_pPD->m_pd.hDC = ::CreateDC(pCmdInfo->m_strDriverName,
#0016                      pCmdInfo->m_strPrinterName, pCmdInfo->m_strPortName, NULL);
#0017                  if (printInfo.m_pPD->m_pd.hDC == NULL)
#0018                  {
#0019                      AfxMessageBox(AFX_IDP_FAILED_TO_START_PRINT);
#0020                      return;
#0021                  }
#0022              }
#0023          }
#0024
#0025          printInfo.m_bDirect = TRUE;
#0026      }

printInfo.m_bDirect = TRUE;

[vc8fans]

回1楼 我是单对话框结构的，发 ::SendMessage(this->GetSafeHwnd(), WM_COMMAND, ID_FILE_PRINT_DIRECT, 0); :没有反应 ::SendMessage(this->GetSafeHwnd(), WM_COMMAND, ID_FILE_PRINT, 0);打印前总出个“打印设置对话窗” 选打印机，纸张类型，张数，很烦恼。。。

[schlafenhamster]

void CView::OnFilePrint() View 有这个,对话框没有,要自己写.

[vc8fans]

void CView::OnFilePrint() View 有这个,对话框没有,要自己写. 这个如何写？？、，，能有例子吗谢谢！！！??/

[worldy]

ON_COMMAND(ID_FILE_PRINT_DIRECT, aClass::OnFilePrint)//攫取掉app的打印例程，主意，不能再将控制传给基类

[vc8fans]

思路是有了，水平菜点有例子的连接吗？谢谢，想学习一下

[schlafenhamster]

vc6 安装盘有个 EZPRINT （EasyPrint） 例子。

[vc8fans]

这个代码确实没有找到

[youyoudaishu]

你好，这段demo功能是实现自动打印的吗？你讲的实现自动打印的过程能否在详细点，有点不太明白？ 我基本的打印功能实现了，现在想在dialog上添加一个button实现自动打印的过程，自动打印用demo具体实现的过程是怎么样的，能否指导一下，谢谢！

[schlafenhamster]

C++ Q & A by Paul DiLascia Paul DiLascia is a freelance software consultant specializing in training and software development in C++ and Windows. He is the author of Windows++: Writing Reusable Code in C++ (Addison-Wesley, 1992). QI’m trying to implement printing for my application. I want to do something like what Word, Microsoft¨ Excel, and other programs do, where there’s a File Print command that displays the print dialog and a toolbar button that prints without displaying a dialog. I noticed MFC has commands for ID_FILE_PRINT and ID_FILE_PRINT_DIRECT, so I used ID_FILE_PRINT in my menu command and ID_FILE_PRINT_DIRECT for my toolbar button. I also made Ctrl-P an accelerator key for File Print, and I wanted to make Ctrl-Shift-P an accelerator key for direct printing, but it doesn’t work. When I type Ctrl-Shift-P, I still get the print dialog, even though this key is bound to ID_FILE_PRINT_DIRECT. I tried different keys, but no matter which key I used, I couldn’t get direct printing to work—I always got the dialog. It works fine from the toolbar button, however. What gives? Martin Buren AThe problem is a bug in CView::OnFilePrint. This is MFC’s standard handler for both ID_FILE_PRINT and ID_FILE_PRINT_DIRECT. In a normal app, you’d have entries in your view’s message map that map both commands to OnFilePrint. BEGIN_MESSAGE_MAP(CMyView, CView) • • • ON_COMMAND(ID_FILE_PRINT, OnFilePrint) ON_COMMAND(ID_FILE_PRINT_DIRECT, OnFilePrint) END_MESSAGE_MAP() How does CView::OnFilePrint know whether the command is ID_FILE_PRINT or ID_FILE_PRINT_DIRECT? Therein lies the bug. If you look at the MFC source code for CView::OnFilePrint, you’ll discover it’s a rather long function, but the overall structure of it goes like this: void CView::OnFilePrint() { CPrintInfo printInfo; // create print info ASSERT(printInfo.m_pPD != NULL); if (GetCurrentMessage()->wParam == ID_FILE_PRINT_DIRECT) { • • • printInfo.m_bDirect = TRUE; } • • • } GetCurrentMessage is an MFC function that returns the current message as an MSG structure. For a command, the message is WM_COMMAND and wParam is the command ID. So if the command ID (wParam) is ID_FILE_PRINT_DIRECT, MFC does direct printing by setting the flag CPrintInfo::m_bDirect. CView::DoPreparePrinting will later examine this flag to determine (among other things) whether it needs to run the print dialog or not. If the wParam for WM_COMMAND is not ID_FILE_PRINT_DIRECT, OnFilePrint skips that part of the if clause and m_bDirect remains FALSE, its default value initialized by the CPrintInfo constructor. All this looks pretty innocent at first blush, until you realize that wParam is not exactly the command ID. The command ID is in the low-order word of wParam; the high-order word contains the notification code. Notification codes are used when the WM_COMMAND is a control notification, like EN_CHANGE from an edit control or LBN_DBLCLK from a list box. For menu commands there is no notification code. Or is there? If you reach into the far recesses of your mind where you store all that useless Windows¨ trivia (or if you just read the documentation carefully), you’ll recall that Windows uses the notification code for simple commands to tell your app whether the command came from the menu or an accelerator key. If the command came from an accelerator key, as opposed to a menu command or toolbar button, then Windows sets the notification code (high word of wParam) to 1. Surprise, surprise! The idea is to provide a way to differentiate between a command invoked from the menu and one invoked from an accelerator, should you ever wish to do that. Now you can see the bug; instead of looking at wParam, CView::OnFilePrint should only look at LOWORD(wParam). No doubt this bug snuck in when the MFC folks upgraded from Windows 3.1 to Win32¨. That’s when the parameters for WM_COMMAND got shuffled slightly. WPARAM grew from a 16-bit WORD to a full 32-bit LONG. At the same time, the API designers moved the notifica-tion code from HIWORD(lParam) to HIWORD(wParam). Oh well, these things happen. The question is, how do you fix it? There are many ways, but the quickest one I can think of is to override CView::OnFilePrint to simply clobber the notification code. void CMyView::OnFilePrint() { MSG& msg = AfxGetThreadState()->m_lastSentMsg; msg.wParam &= 0xFFFF; // zero hi word CView::OnFilePrint(); // pass to MFC } Now, whether the command came from the menu or an accelerator key, HIWORD(wParam) will be zero before CView::OnFilePrint sees it. If for some reason you need to do something different when the command comes from an accelerator, you can always test for HIWORD(wParam)==1 before you clobber it. Note that I used AfxGetThreadState()->m_lastSentMsg instead of GetCurrentMessage. The former is slightly faster because it doesn’t call ::GetMessageTime and ::GetMessagePos (like GetCurrentMessage does) to fill in MSG.time and MSG.pt—neither of which you care about here. I’m sure the folks in Redmond will fix OnFilePrint as soon as they discover the bug (perhaps from reading this). In the meantime, if any of you have apps that you’ve recently ported from Windows 3.1 to Win32, you might want to test all your accelerated commands and grep your source files for use of wParam in a WM_COMMAND message. Looking at wParam instead of LOWORD(wParam) to get the command ID is a fairly common Win32 gotcha.

[youyoudaishu]

Thank you! The question mentioned above has been solved.@schlafenhamster