C / C++ / MFC

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 2:22

charlieg wrote:
I'm trying to get a handle on is the dialog creation / paint notification sequence of events

I'm actually not too sure what you mean by this.

charlieg wrote:
What I see on the dialog is WHITE when the red should be.

I suspect that that is because you are not handling WM_ERASEBKGND and the default handler is drawing the background (using the background brush which is usually COLOR_WINDOW which is usually white). And that it's not painting red because that region was not invalidated. This is of course just a guess, from the available code.

I notice you are double buffering to reduce flickering. Are you also handling WM_ERASEBKGND and doing nothing but returning 1? Are you "erasing" your window in your UpdateDisplayData() function (bitblting the background color)? Or is this not neccessary in your case.

In your OnTimer handler, do you invalidate the part of your window that needs to be redrawn (or the whole client area if that is the case)? You shouldn't be calling UpdateDisplayData() in your OnTimer handler as CPaintDC (BeginPaint()/EndPaint()) should only be used in response to a WM_PAINT message.

Windows maintains the clip region for your window when you need to do your painting, so if you don't have anything within the clip region (ie. didn't invalidate explicitly or windows didn't invalidate anything for you) then it's not going to actually draw anything to the screen.

charlieg26-Jul-06 3:39

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 3:39

hfry,

hfry wrote:
I'm actually not too sure what you mean by this.

What I'm trying to understand is the initial dialog/window creation sequence and the ramifications on drawing. In a galaxy far away called Unix, they have this beast called X-Windows. A drawing 101 error was trying to draw before something called an expose event. Drawing before this results in all of the drawing going into the bit bucket. Fast forward to today - Windows has it's own little mechanism called the invalid region - if you don't invalidate things, they won't draw. Now, most of my drawing codes does not invalidate anything, it just starts blasting away, and the images show up. My theory is that when a dialog/window is created, everything is invalid, and my drawing appears... just a theory. So, that's why I'm asking how things really work - maybe there is something more subtle.

Okay, so getting to your specific comments:

1) WM_ERASEBKGND - with a couple of very unique situations, I never handle this.
My drawing code regenerates the image in a bitmap. The BitBlt then replaces
the entire region on the window. My rationale was, why bother to erase
something that I'm getting ready to paint over?

FWIW: I added a handler for this message - no effect.

2) As far as "erasing my window" - I simply call InvalidateRect with the same
CRect that I use in the drawing code. Note this this is just the test code
I'm running now. Usually, I do not do an invalidate operation, electing to
draw out of the OnTimer handler. Both *seem* to work (but I have my doubts
Smile | :)

).

Even with relocating the code to the OnPaint handler, the only time the
screen is updated correctly is when I draw directly to it. If I use the
code to fill a bitmap then blit the bitmap, I get white.

I truly appreciate your suggestions and patience. This issue has me a bit Mad | :mad:

Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.

My son's PDA is an M249 SAW.

charlieg26-Jul-06 4:02

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 4:02

OMG!!!

I just found it, and I understand why superficially, but I think my way should have worked. Ignore all the onpaint comments, not directly relevent to the behavior at hand.

Broken code / working code is bolded below.... Now, does someone want to explain to me why I have to create a compatible bitmap from the PaintDC? Is it not logical that if I create a buffering DC with CreateCompatibleDC(PaintDC) should not a bitmap created be compatible as well?
OMG | :OMG:

CDisplayData::UpdateDisplayData()
{
CPaintDC dcDialog(m_pParentWindow);
CDC dcBitmap;

BOOL bStatus = dcBitmap.CreateCompatibleDC(&dcDialog);
ASSERT (bStatus);

CBitmap buffer_bm;
CBitmap *old_bm;

// Create an offscreen bitmap for antiflicker buffering...
bStatus = buffer_bm.CreateCompatibleBitmap(&dcBitmap, 100, 100);
bStatus = buffer_bm.CreateCompatibleBitmap(&dcDialog, 100, 100); // this works
ASSERT (bStatus);
old_bm = dcBitmap.SelectObject(&buffer_bm);

// Fill the bitmap with an arbitrary color, and copy it to the screen.
// "RED" is a macro...

dcBitmap.FillSolidRect(0, 0, 500, 100, RED);

bStatus = dcDialog.BitBlt(rc.left,
rc.top,
rc.Width(),
rc.Height(),
&dcBitmap, 0, 0, SRCCOPY);

dcBitmap.SelectObject(old_bm);
}

Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.

My son's PDA is an M249 SAW.

Justin Tay26-Jul-06 4:19

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 4:19

Ah, I didn't notice that when I looked through.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_1cxc.asp[^]

Relevant snippet.

Note: When a memory device context is created, it initially has a 1-by-1 monochrome bitmap selected into it. If this memory device context is used in CreateCompatibleBitmap, the bitmap that is created is a monochrome bitmap.

charlieg26-Jul-06 4:24

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 4:24

Okay, I'm going to go off on a little rant here... the method is called CreateCompatibleBitmap, for God's sake! So the documentation clearly calls out that the bitmap created ISN'T compatible - that makes me feel better?

I think it should be renamed as CreateMostlyCompatibleBitmap()

The only thing worse than no doc is erroneous doc. Suspicious | :suss:

Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.

My son's PDA is an M249 SAW.

Justin Tay26-Jul-06 4:13

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 4:13

charlieg wrote:
What I'm trying to understand is the initial dialog/window creation sequence and the ramifications on drawing.

You could try using a spy application like this[^] to look at the kind of messages that windows generates for your application.

charlieg wrote:
theory is that when a dialog/window is created, everything is invalid

Yes when your window is created everything is invalid.

charlieg wrote:
WM_ERASEBKGND - with a couple of very unique situations, I never handle this.

When windows sees that there is an invalid region (and there are no more messages on the queue) it will generate 2 messages, WM_ERASEBKGND and then WM_PAINT. Windows paints the entire invalid client area with the background brush for you if you choose not to explicitly handle WM_ERASEBKGND.

Windows flicker for 2 reasons. One is when it takes too long to draw and you're drawing directly to the screen, then you can see windows drawing your window piece by piece. The other is when the window gets invalidated too quickly, ie, you keep having a lot of WM_ERASEBKGND and WM_PAINT messages in succession. The default window procedure (if WM_ERASEBKGND isn't handled and you don't return a non-zero value) will paint the entire client area with the background for you. This is usually undesirable if you are trying to eliminate flicker as you first have a white screen, then what you painted, then white again, etc, causing flicker.

charlieg wrote:
Usually, I do not do an invalidate operation, electing to draw out of the OnTimer handler

The problem with this is when your window gets obscured and uncovered by another window. In which case windows will generate a WM_ERASEBKGND and WM_PAINT message. If WM_ERASEBKGND is not handled, the invalid area is painted with the background brush for you. If WM_PAINT doesn't do anything, then you just have the background. If you handled WM_ERASEBKGND and elected not to do anything and WM_PAINT isn't doing anything, then you are left with whatever bits happen to be there on the invalid area of your window. Of course if your timer is fast and you keep painting to the screen, it's unlikely that you'd really notice anything amiss.

charlieg26-Jul-06 4:59

Re: mfc drawing philosophy question - when is the correct time to draw?

26-Jul-06 4:59

All of your comments are dead-on. I'll be going back to clean up some sins of the past next week. Since my timers fire rather rapidly, and my drawing is buffered, the user never notices anything... until I have to slow the timers down ...

I appreciate all your help. I still want to slap silly the CreateCompatibleBitmap coder. D'Oh! | :doh:

Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.

My son's PDA is an M249 SAW.

Justin Tay26-Jul-06 5:34

Convert CString to Unsigned short & Vice Versa

26-Jul-06 5:34

Well, it probably means that the function is creating a bitmap compatible to the bitmap selected in the device context that you passed in. Yeah kinda bites, I'm also guilty of assuming what functions do based on their names instead of checking the docs. Poke tongue | ;-P

Raymond Chen's blog[^] is a good read if you don't know about it already.

JBAK_CP25-Jul-06 13:00

JBAK_CP

25-Jul-06 13:00

I have a CString variable that has a port address that needs to be converted to an unsigned short....I'm using the _outp(short, int) to communicate to an i/o port. I tried doing a 'atoi' on the string, but I end up with a 0.

For the second part I would like to convert the address(short) back to a string.....

I apperciate the help.
Thanks,

-------------
CString test = "0xF03";
test.Remove(' " '); //Remove the quotes

unsigned short x = atoi(test);

_outp(x,0x81); //Need this to be _outp(0xF03, 0x81)

Re: Convert CString to Unsigned short &Vice Versa

Justin Tay25-Jul-06 13:15

Bitmap associated with a static control

25-Jul-06 13:15

arunkk1 wrote:
test.Remove(' " '); //Remove the quotes

Unless you actually have CString test = ""0xF03""; there are no quotes to remove.

arunkk1 wrote:
unsigned short x = atoi(test);

atoi() does not understand integer strings written in anything other than base 10.

Use strtol() instead.
unsigned short x = strtol(test, NULL, 16);

Convert back
test.Format("0x%X", x);

cphawk25-Jul-06 12:09

cphawk

25-Jul-06 12:09

Hello,

I have developed an application that uses a bitmap associated with a static control using CStatic::SetBitmap. When displaying the image in the client area:

1. I would like the ability for the user to select an area of interest (via a transparent rectangle).
2. Be able to move and rubber band the rectangle similar to CRectTracker. The rectangle should not be able to be moved or resized out of the CStatic client window.
3. Report the coordinates of the rectangle with respect to the client area coordinates (i.e. top left, bottom right).

Does anybody have Visual C++/Studio sample code that would do this?

Thanks in advance,

PJP

Re: Bitmap associated with a static control

sudeesh26-Jul-06 2:40

sudeesh

26-Jul-06 2:40

sub class CStatic class and then on mouse events u update the window in Onpaint handler.

Sudeesh

Can't find files

jimNLX25-Jul-06 11:52

jimNLX

25-Jul-06 11:52

I have a solution that contains several projects. Most of these projects use files that are common between them all.

I would like to only have the common files in one place so that I only have one version of them. Thus if one of the common files is changed all of the projects that use it will be updated/compiled again.

Any help with this would be very much appriciated.

Thanks,

Jim

Re: Can't find files

Justin Tay25-Jul-06 13:22

TabCtrlSSL tab control code

25-Jul-06 13:22

Put all your common files in one directory, and set your projects to look in that directory. Configuration Properties >> C/C++ >> Additional Include Directories. Or you could set it in VC++ Directories.

BuckBrown25-Jul-06 10:18

BuckBrown

25-Jul-06 10:18

Hi,
This is for anyone familiar with the TabCtrlSSL code.

I am using Viusal Studio 6.0 MFC. I downloaded the code for the tab control class CTabCtrlSSL and implemented it. Everything seems to be working fine except that the app does not appear to process the command messages. I had an existing dialog IDD_DIALOG_1 with button controls. I created a second dialog called IDD_DIALOG_TAB and placed a tab control in it. I created a variable for the control called m_ctrlTab of type CTabCtrlSSL. Then in the OnInitDialog() function of my TabCtrl class I call m_ctrlTab.AddSSLPage(("Tests"), nPageID++, IDD_DIALOG_1); If I click on any of the buttons in the IDD_DIALOG_1 (displayed as tab page 1) then the CTabPageSSL::OnCommand() function is called. If I click on OK or CANCEL buttons then the "return GetParent()->SendMessage (WM_COMMAND, wParam, lParam);" in the CTabPageSSL::OnCommand() function is called and returns a value of 1 and the application exits as I would expect. If I click on any other button then the "return GetParent()->SendMessage (WM_COMMAND, wParam, lParam);" function is called with wParam of 1022 (the IDD_DIALOG_1) but the function the button is supposed to invoke never executes. I have tried various handles from GetParent(), GetOwner(), GetParentOwner() but the SendMessage() function will return a value of 0 for these other buttons. I am not a Windows programmer so I am not very familiar with parent child relationships. The way I see it the dialog IDD_DIALOG_1 is a child of the tab dialog IDD_DIALOG_TAB. If anyone sees something obvious I could use some help on this.

Thanks,

Buck

Precompiled header error

Jay0325-Jul-06 8:41

Jay03

25-Jul-06 8:41

I get the error listed at the bottom when I try compiling a source file which absolutely has no syntax errors. This has something to do with the precompiled header. I just learnt that precompiled headers are used for performance to speed up the compilation. If a header file is used in many different source files, precompiled header (.pch) file will be created the first time this header file is compiled and the next time this header file is called in a differnt source file, it will stop compiling and directly use the .pch file. Knowing that, what relationshop does precompiled header have with stdafx.h. Why are stdafx.h used for? When I tried creating a project in Visual Studio 2005, stdafx.h and stdafx.cpp were automatically created. Can someone explain what is going on here please...... Confused | :confused:

Thanks,
Jaysan

BUILD LOG

------ Build started: Project: winsock, Configuration: Debug Win32 ------
Compiling...
ObjectRoot.cpp
c:\documents and settings\aravinth\desktop\objectroot\objectroot.cpp(299) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
Build log was saved at "file://c:\Documents and Settings\Aravinth\Desktop\ObjectRoot\winsock\winsock\Debug\BuildLog.htm"
winsock - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Zac Howland25-Jul-06 8:53

Zac Howland

25-Jul-06 8:53

When using precompiled headers, anything that comes before #include "stdafx.h" is considered a comment. The file doesn't have to be named "stdafx.h", but if you create your project using the wizard, it will be. Stdafx.h is where you add common header files to gain this compilation optimization. Make sure that the first #include is "stdafx.h".

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: Precompiled header error [modified]

Michael Dunn25-Jul-06 8:56

Michael Dunn

25-Jul-06 8:56

When the compiler is processing a CPP file (other than stdafx.cpp) it looks for the line
#include "stdafx.h"
and at that point, loads the saved state from the PCH file. (This is, btw, why anything you write before that include gets ignored.) If for some reason you can't include stdafx.h but want that CPP file to use the PCH, you can use
#pragma hdrstop

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

Jay0325-Jul-06 9:58

Jay03

25-Jul-06 9:58

Are #include "stdafx.h" standard in the sense that you don't have to modify anything in the file after its created for you when you create a new project in Visual Studio 2005?

What could be the problem when I compiled a source file when I got the following error

------ Build started: Project: winsock, Configuration: Debug Win32 ------
Compiling...
ObjectRoot.cpp
c:\documents and settings\aravinth\desktop\objectroot\objectroot.cpp(299) : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
Build log was saved at "file://c:\Documents and Settings\Aravinth\Desktop\ObjectRoot\winsock\winsock\Debug\BuildLog.htm"
winsock - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Could it because the precompiled header feature was on without including stdafx.h (#include "stdafx.h")

Thanks boys

-- modified at 16:01 Tuesday 25th July, 2006

Zac Howland25-Jul-06 10:02

Zac Howland

25-Jul-06 10:02

Jay03 wrote:
Could it because the precompiled header feature was on without including stdafx.h (#include "stdafx.h")

Yes. If your project settings say that you are using precompiled headers, but you don't include stdafx.h, you will get that error.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac