|
I have this problem. I have CView derived class. In the OnCreate function I
create a CRichEditCtrl like this:
AfxInitRichEdit();
m_richEdit.Create(ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_MULTILINE |
ES_WANTRETURN |
WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL, rect, this, 1);
where m_richEdit is a CRichEditCtrl variable defined in the header file of
my CView class. In OnSize I set the
appropriate size of the control.
Now I have this problem. What do I have to do to print the contents of the
m_richEdit and to see the contents of this
in Print Preview. I have tried many thinks, but I failed.
Thank you very much.
David Pokluda
pokluda@mujweb.cz
|
|
|
|
|
I have done this with a CView derived child (CScrollView) but not with a CWnd derived child. With the CView child the code looked like this:
void CViewClass::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
//Resize the child if needed.
m_child.MoveWindow(&m_rectChild, TRUE);
//Print the child.
m_child.OnPrint(pDC, pInfo);
//Call the base class.
CView::OnPrint(pDC, pInfo);
}
Now the CWnd child does not have the OnPrint(...) method. But you may be able to use the CWnd::Print(CDC* pDC, DWORD dwFlags) method instead.
Please let me know if it works...
Jonathan Craig
|
|
|
|
|
The CWnd::Print(…) method will not work. But the CRichEditCtrl knows how to render itself to a device context. The code below will work. I didn’t have a chance to figure out the formatting. You need to look up the FORMATRANGE structure in the MSDN. The code below was cut and pasted for the MSDN article CRichEditCtrl::FormatRange. Also look at the MSDN article Printing in Rich Edit Controls. If you don’t have MSDN you can search Microsoft’s web site.
void CPrintChildWindowView::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
FORMATRANGE fr;
long lPageWidth = ::MulDiv(pDC->GetDeviceCaps(PHYSICALWIDTH),
1440, pDC->GetDeviceCaps(LOGPIXELSX));
long lPageHeight = ::MulDiv(pDC->GetDeviceCaps(PHYSICALHEIGHT),
1440, pDC->GetDeviceCaps(LOGPIXELSY));
CRect rcPage(0, 0, lPageWidth, lPageHeight);
// Format the text and render it to the printer.
fr.hdc = pDC->m_hDC;
fr.hdcTarget = pDC->m_hDC;
fr.rc = rcPage;
fr.rcPage = rcPage;
fr.chrg.cpMin = 0;
fr.chrg.cpMax = -1;
m_pREC->FormatRange(&fr, TRUE);
// Update the display with the new formatting.
RECT rcClient;
m_pREC->GetClientRect(&rcClient);
m_pREC->DisplayBand(&rcClient);
CView::OnPrint(pDC, pInfo);
}
Good Luck,
Jonathan Craig
|
|
|
|
|
I have this problem. I am developing an application that needs to know how
many papers have been printed on the printer. I would like to do it this
way. The application would be a service or a program that would be running
all the time and when the user prints something it will get the info from
the printer manager. But...
How can I connect to a print manager so that I would now how many pages are
printed? If it is possible is it even possible to figure out the quality of
the printed pages (best/normal/economy)?
Thank you very much for any suggestion.
David Pokluda (pokluda@mujweb.cz)
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
Try GetDC()->GetBkColor()
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
Its the second time i got this message from ms visual studio 6.0 :
"Debug Assertion Failed !
Program : prgram.exe
File : dlgdata.cpp (?)
Line : 43
For info on debug [...] see ms vsc doc...
Press retry to debug the application"
It just seems to come out of nowhere since my program doesnt pose any problem during the compilation.
Can anyone help me please, i'm stuck ! !
thanks.
|
|
|
|
|
assertions are a good thing!
They are placed in code by the programmer to verify that something is true, and if it isn't true, force (when DEBUG is defined) the display of a nasty message like the one you describe.
You are getting this assertion from an MFC app (via the ASSERT() macro) but the standard library assert() is available as well for non MFC apps.
MFC code uses ASSERTs liberally - as it should. Very often you'll see code that does something like ASSERT(pointer != NULL). If the expression is true, the code continues - but if not (i.e. a NULL pointer) the code will 'assert'. The idea is that its better to see the fault here than to track a subsequent access violation (which may end up in a system DLL).
Note that you have to be careful not to put code with side effects inside an ASSERT - because it won't be compiled for a release build - MFC provides the VERIFY macro if you want to do the equivalent of an assert in a release build.
Philosophies vary on what constitutes a valid place for an assertion. Some say they should be reserved for critical things like NULL pointers that will generally cause a crash. I tend to use them for even minor things that may not be critical but I want to know about them - things that I might miss if I just TRACE a notification to the debug output window.
The ASSERT you are getting comes from CDataExchange - probably some problem with a dialog control ID. What you can do is choose Retry to invoke the debugger, then press Alt+7 to display the call stack. (Or View | Debug Windows | etc.) By looking at the ASSERT statement and the surrounding code, you should be able to identify some offending variable or resource define. You'll often need the call stack to backtrack to the source of the problem, but unless its some nasty mess in your resouce file you should be able to figure it out.
|
|
|
|
|
Thanx a lot !
You've been a great help, thanks to the call stack i noticed some references to edit box ID's which were useless since i had deleted the corresponding edit boxes...
Thank you again !!
|
|
|
|
|
Excellent summary Tim, you should submit it as an article.
As you and I both know  , new MFC programmers (and many long standing ones), don't really understand the value and function of ASSERT()'s, and quite often after they start using them, place code in them not realizing the code is only included in a Debug build.
I also agree that they should be used liberally, as they have zero effect on the performance of runtime code.
|
|
|
|
|
I'm new to MFC, and I have a little problem.
Is there a way to have a dialog bar on the top of a CView in an MDI app?
I have the following code, but the dialog bar doesn't get drawn!
It works great if I create the dialog bar on the MainFrm.
int MyView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
m_pDlgBar = new CDialogBar();
if (!m_pDlgBar)
return -1;
m_pDlgBar->Create(
this,
IDD_DLGBAR,
WS_CHILD | CBRS_TOP | CBRS_TOOLTIPS | CBRS_FLYBY,
ID_DIALOGBAR); // I don't really know what this parameter does
m_pDlgBar->ShowWindow(SW_SHOWNORMAL);
if (CView::OnCreate(lpCreateStruct) == -1)
return -1;
}
Any suggestions?
Thanks In Advance.
Erik
|
|
|
|
|
You want to add the toolbar (or dialog bar) to the frame insted of the view. You can catch the button messages in the doc, view, or frame. The code below will add a toolbar to the child frame:
int CFrameClass::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CMDIChildWnd::OnCreate(lpCreateStruct) == -1)
return -1;
//Create the toolbar.
{
EnableDocking(CBRS_ALIGN_ANY);
if(!m_wndToolBar.Create(this, WS_CHILD | WS_VISIBLE | CBRS_TOP, IDR_TOOLBAR_DEFECTVIEW) ||
!m_wndToolBar.LoadToolBar(IDR_TOOLBAR_DEFECTVIEW))
{
TRACE0("Failed to create toolbar\n");
}
else
{
// TODO: Remove this if you don't want tool tips or a resizeable toolbar
m_wndToolBar.SetBarStyle(m_wndToolBar.GetBarStyle() |
CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC);
// TODO: Delete these lines if you don't want the toolbar to
// be dockable
m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
DockControlBar(&m_wndToolBar, AFX_IDW_DOCKBAR_RIGHT);
}
return 0;
}
Good luck,
Jonathan Craig
|
|
|
|
|
Thanks!
It worked, but how can I get a pointer to the child from the view?
Thanks again!
Erik
|
|
|
|
|
Look up this document in the MSDN or on Microsoft's web site; "Relationships Among MFC Objects". I keep this one tacked to the wall next to my computer.
The function you want is CWnd::GetParentFrame(). Remember the view is a child of the frame.
Good luck and happy hacking...
Jonathan Craig
|
|
|
|
|
This is very strange problem because my code works perfectly when dynamically linking to MFC.
At some point in my project I use:
HCURSOR hAniCur = (HCURSOR)LoadImage(AfxGetResourceHandle(),
MAKEINTRESOURCE(IDR_HOURGLASS), IMAGE_CURSOR, 0, 0, LR_DEFAULTCOLOR);which gives me a valid handle as long as MFC is in a DLL, but returns NULL when I link static MFC libraries.
There are no differences between Debug or Release builds, both suffer the same problem. I also tried to change the resource ID of the animated cursor and to use a string instead of a number, but without success.
I have reproduced this problem on a little test project if anyone likes the challenge...
Thanks in advance,
Paolo
|
|
|
|
|
Step through AfxGetResourceHandle() and make sure it's returning the correct HINSTANCE. I've seen that function return unexpected results before, which then causes all sorts of resource headaches.
|
|
|
|
|
I tried with AfxGetInstanceHandle(), AfxGetResourceHandle() and GetModuleHandle(NULL). They all return the same value, that is 0x00400000, which is right.
What's more, loading from a file works just fine with the arguments I pass to the function.
It seems like LoadImage can't find the resource, but why?
When I link with static libraries I add some resources to my executable, so I thought something was in conflict with the animated cursor resource. I tried with different IDs, but without any luck.
I imported the animated cursor as a custom resource, naming that type "ANICURSOR". Is this right? Or I should use something else?
I think the correct resource type is RT_ANICURSOR, but how can I add such resources to my project?
However, loading the animated cursor with the type I specified works in Debug version.
Any other ideas?
|
|
|
|
|
Convert the image to one of the closest DIB format, and then use StretchDIBits to display it.
My guess is that each pixel is a 16-bit grayscale level, so the closest DIB format would be 8-bit grayscale image, or a 256-color DIB with a grayscale color table.
Setup a BITMAPINFO structure with a 256-color grayscale color table, convert the image array to a 64x64 BYTE array, and then use StretchDIBits to display it.
|
|
|
|
|
I discovered what was wrong: if there are static cursor resources (RT_CURSOR) both LoadImage() and LoadCursor() don't look for animated cursor resources (RT_ANICURSOR = 21).
Statically linking to MFC involves the inclusion of some MFC resources, among which there are two cursors for context-sensitive help.
I've tried adding the animated cursor as a static cursor, but both VC++ IDE and the resource compiler recognize the internal file format.
So what should I do, if I don't want to load the cursor from file?
Is this a BUG ?? (tested on Win95 and Win2000)
Any suggestion would be appreciated... 
|
|
|
|
|
To solve the problem, I thought to load the animated cursor resource and then create the cursor handle with the following code:HRSRC hResInfo = FindResource(NULL, MAKEINTRESOURCE(IDR_HOURGLASS), RT_ANICURSOR);
DWORD dwResSize = SizeofResource(NULL, hResInfo);
HGLOBAL hRes = LoadResource(NULL, hResInfo);
PBYTE pResData = (PBYTE)LockResource(hRes);
HCURSOR hAniCur = CreateIconFromResourceEx(pResData, dwResSize,
FALSE, 0x00030000, 32, 32, LR_DEFAULTCOLOR);
The problem remains
All the instruction are successful with both types of linkage, but the last returns a valid handle only when dynamically linking to MFC. When I specify to use static MFC libraries, CreateIconFromResourceEx() cease to work and returns NULL.
Can anyone tell me why?
I tried to debug USER32 code, but it's a suicide without debug symbols.
Where can I get debug symbols for Windows 2000?
Please help!!
|
|
|
|
|
i'm working on a program that reads an open file and puts a line into a sting buffer until a newline is found, then puts the string into the clipboard. This is done through a windows WH_KEYBOARD hook... is there anyway for the read file's handle to be shared so that all processes can share the same instance of the handle?
Any non-MFC solution would be very much appreciated.
|
|
|
|
|
Can I create a MDI form with child forms WITHOUT USING MFC? If it's possible, could you show me some code to do it?
Thanks a lot in advance!
B
|
|
|
|
|
If you really want to do it without any wraper classes (i.e. MFC), get a few books like, "Windows 2000 Programming from the Ground Up" by Herbert Schildt. Herbert likes to hand crank all his stuff and will have examples on how to handle the messaging and window creation.
If you just want less complicated CWnd objects you can create a MDI application without the Document/View Architecture. This gives you the CView without the attached CDocument.
Unless you want to be able to use different compliers to compile your code, I would use window wraper classes for my development. They do make life easier.
Good Luck,
Jonathan Craig
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
