|
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?
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.
|
|
|
|
|
|
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.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
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.
|
|
|
|
|
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.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
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. 
Raymond Chen's blog[^] is a good read if you don't know about it already.
|
|
|
|
|
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)
|
|
|
|
|
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);
|
|
|
|
|
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
|
|
|
|
|
sub class CStatic class and then on mouse events u update the window in Onpaint handler.
Sudeesh
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
 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
|
|
|
|
|
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......
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 ==========
|
|
|
|
|
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
|
|
|
|
|
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 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Great!
Thanks Zac 
|
|
|
|
|
Hi,
I have a very strange problem:
In filter graph I have 3 filters (among the rest) connected in a row. When I try to
reconnect the first to the second I get a S_OK code that means that it was successful.
When I try to check if the pins are connected right afterwards - I get a E_NOT_CONNECTED
error.
Does anyone have any insight on this? I'd highly appreciate any help.
Thanks.
|
|
|
|
|
if the 3 filters are connected in a row, a->b->c and now you want to connect a->c then I think you need to disconnect the a->b pins before trying to connect a->c pins.
I'm assuming here that you have not 'run' the graph after connecting a->b->c so I'm a little curious why you connect the 3 in a row to begin with
cje
|
|
|
|
|
I have some objects derived from CObject. The topmost non-abstract classes have the
IMPLEMENT_SERIAL (CNewClass,CImmediateBaseClass,VERSION_SCHEMA)
and
DECLARE_SERIAL (CNewClass)
in their respective places. All appears to work well when project set to "Use MFC in a shared dll" but when I try "Use MFC in a static library" I get an error for my IMPLEMENT_SERIAL code sections that says...
NewClass.cpp(4) : error C2039: 'classCImmediateBaseClass' : is not a member of 'CImmediateBaseClass'
NewClass.h(8) : see declaration of 'CImmediateBaseClass'
NewClass.cpp(4) : error C2065: 'classCImmediateBaseClass' : undeclared identifier
Context:
Visual C++ 2003
Any ideas on what I might be missing?
|
|
|
|
|
bob16972 wrote: All appears to work well...
Are you sure? What does the code containing IMPLEMENT_SERIAL() and DECLARE_SERIAL() look like?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I probably should have said bottomost instead of "topmost". It is in the last derived class for clarification.
The base class has virtual functions, a class is derived from it. It has some virtual functions and it's serialization procedure calls the base class first, then it serializes itself. A class is then derived from that and provides implementations for all the virtual functions and it calls the immediate base class serialization method and then it's own. This last class is the only class that has the IMPLEMENT_SERIAL and DECLARE_SERIAL macros.
The serialization process was tested incrementally long ago as it was being built. It preserved all the fields being serialized on the stream. It is doing so today when using "shared" MFC. I was just trying to put it together for deployment and instead of redistributing the MFC 7.1 merge modules (.msm) in my MSI, I thought I'd try something different and statically link MFC in but hence, the errors jumped out. That is where I'm at now.
I may have some fundamental flaw in all of that but it "appears" to work as it always has when using MFC in a shared dll(s). I'm just checking here to see if it's commonplace to statically link, with an application that uses MFC serialization, and not have any problems or whether it's some common mistake that everyone (except me) knows about.
I'm not sure if that helps but wasn't not quite sure what you were getting at...
|
|
|
|
|
Thanks again for your assistance.
Viorel got me going down the road to recovery (I hope) 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
