Which window are you creating inside constructor? It is not a good idea to create a window before the object is fully initialized. Constructor is called when you create an object. Once object is created, then you should create a window.
CWnd* obj = new CWnd();
My guess is you are getting assert at CClientDC dc(this); because 'this' does not point to a valid window because your Create function never succeeded.
In wizard generated code, do you see CSingleDocTemplate object being created anywhere? may be in InitInstance? If yes, then read about that function on msdn. it's the place where view, frame etc are created. You can put a breakpoint in framewnd c'tor and before CSingleDocTemplate.
Having said all that, as far as I have understood your problem, you just need to do this:
In your wizard generated view class, create a CString variable "CString m_strText;"
in your CMyView constructor, put m_strText = "Hello";
and inside your CMyView::OnDraw, draw the text to screen.
Maybe you didn't get my phsyco babble but the previous code works perfectly as long the application is created manually using the method shown. The only portion of code that I'm trying to use is the code under "Virtual Window Stuff" the Create function in that is working fine if not I wouldn't get a window.
My problem is with App-Wizard generated MFC single document application. However I have a kind-of-solution but for what ever reason the background of the view goes black so I have to change the text color and text background. Not quite what I'm after yet.
Check out the code below it works quite well.
I think this is how it works;
A bitmsap is created to hold the content of the device context.
draw stuff is added to the bitmap in memory then pasted to the view when I call ShowIt().
I had to use a message handler or other function to create the "virtual window" (memory DC). The problem is It doesn't stick around like this I have try and keep everything in the bitmap and recreate the memory DC each time before I draw.
Source File Stuff
void Ccom_testView::OnLButtonDblClk(UINT nFlags, CPoint point)
// Get the extents of the screen
maxX = GetSystemMetrics(SM_CXSCREEN);
maxY = GetSystemMetrics(SM_CYSCREEN);
if (m_bmp.m_hObject == NULL)
m_bmp.CreateCompatibleBitmap(&dc, maxX, maxY);
// This does not do what it should. Expect a white background.// Program Still starts with a black background
CBitmap* pOldBitmap = memDC.SelectObject(&m_bmp);
CBrush* pOldbkBrush = memDC.SelectObject(&bkBrush);
// Had to set text color manually
memDC.SetTextColor(RGB(0, 200, 100));
wsprintf(str, "Hello World");
memDC.TextOutA(point.x, point.y, str, strlen(str));
CPaintDC dc(this); // device context for painting// TODO: Add your message handler code here
// dc.BitBlt(0, 0, maxX, maxY, &memDC, 0, 0, SRCCOPY);// Do not call CView::OnPaint() for painting messages
// CDC memDC;
CBitmap* pbmOld = NULL;
pbmOld = memDC.SelectObject(&m_bmp);
dc.BitBlt(0, 0, maxX, maxY, &memDC, 0, 0, SRCCOPY);
Header File Stuff
class Ccom_testView : public CView
CFont m_SystemFont, m_AnsiVarFont;
protected: // create from serialization only
Ccom_testDoc* GetDocument() const;
virtualvoid OnDraw(CDC* pDC); // overridden to draw this viewvirtual BOOL PreCreateWindow(CREATESTRUCT& cs);
virtual BOOL OnPreparePrinting(CPrintInfo* pInfo);
virtualvoid OnBeginPrinting(CDC* pDC, CPrintInfo* pInfo);
virtualvoid OnEndPrinting(CDC* pDC, CPrintInfo* pInfo);
virtualvoid AssertValid() const;
virtualvoid Dump(CDumpContext& dc) const;
// Generated message map functionsprotected:
afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point);
afx_msg void OnPaint();
Comments or suggestions would be great. Even better yet a better way to do it.
Basically the LButtonDblClk function is using TextOut to put "Hello World" on the screen at the cursors position. The intention is to have the output accumulate on the screen and remain on the screen when resized, minimized or covered by another window etc...
I tried recreating the bitmap each time by changing the conditional statement at the beginning of LButtonDblClk if(!= NULL)delete the bitmap and just have the bitmap created each time the problem with that is the output does not accumulate on the screen.
I will try what you have here to see if my results can improve. Again this code is working, it just paints the background black and I am having trouble figuring out why that is, I have been messing with this same project for a while, maybe I'll try generating a new one and see what happens.
I am puzzled why this is so difficult to solve, although I have not written alot of code I have been doing it for a long time and the programmer has always had to take care of refreshing the screen and keeping the output(text, graphics etc..) on there theirself, at least I have. So what does a novice have to do to get the information or at least a clue to the solution. This cannot be stumping the programming gurus here in this forum, no way.
Make your painting function (i.e. ShowIt() ) accepting as argument, a CPaintDC instead of creating its own device context.
Never call directly your paint function (or other drawing code, use instead InvalidateRect and UpdateWindow to force the painting happen).
inside the button handler just set a flag (a member variable of the class) and use it to conditionally call your painting function inside OnPaint
void Ccom_testView::OnLButtonDblClk(UINT nFlags, CPoint point)
// don't put drawing stuff here
// the following calls force the window re-paint
CPaintDC dc(this); // device context for paintingif (m_showit)
void Ccom_testView::ShowIt(CPaintDC & dc)
// use the passed dc for drawing
Hope it eventually makes sense.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
Actually this makes alot of of sense, I have a better time making sense of things than I do communicating them in a way that makes sense, if that makes sense .
Seriously I think this is going to work for me once I get it implemented properly. I have always been week at passing perameters and therefore I avoid it and never think about the possibilities. I have alot to learn but I'm not going to give up.
Thank you very much for your help, I have learned a great deal just in the communications, that's asside from the code information.
Try [^vc++ in 21 days^] It will give you very good idea of mfc in 2 or 3 days. it's the shortest and most effective way known to me to learn about mfc. it may be a bit dated but the concepts are same and you don't need to spend big bucks to purchase it from nearby second hand bookshop or if you are really smart, you can find an ebook floating around somewhere in this cyberspace. (i know no one likes to spend money on buying fat and boring technical books)
I like to learn and books are good way to start... I accually own the predecessor to that book "C++ in 21 days" which I found to be quite good. I also found "MFC From the Ground Up" which is a great book if you are compiling using Visual C++ 6.0, it seems like things are done non-stansard though, you have to change alot things around to get them to compile and run from the VS2005 that I have now. It's really a good thing Microsoft made it difficult to go back to old version of compiler, cause I would have and not learned what I have. Man and I'll tell you from A novices perspective that upgrade has caused me more pain than I ever imagined I could get from writting my simple code. I think there is a new book out something like MFC from the ground up for VS2005, if that's the case I would really like to get a copy of that.
It's people like you and Pallini that make me come here when I need help. You folks are awesome keep up the good work and thank you.
Okay I am trying to lock CD drive (F: here) with the code shown. But DeviceIoControl is returning "error 87: Parameter not correct". Please someone help me. I cannot find out which parameter is incorrcet.