Stopping MFC flicker
Thomas Zeisluft
Hi Jeff,
>Does anyone know a way to keep an MFC app from flickering when it is resized?
>I've tried a number of combonations of styles and looked at a bunch of the
>example apps and all of them have an annoying flicker when the window is
>resized.
>
>I noticed that VC 5.0 is an MFC window but does not suffer the same problems,
>anyone have any ideas?
You can handle WM_ENTERSIZEMOVE andWM_EXITSIZEMOVE. You should set a
flag to disable your OnDraw code when you get the enter message and
reset it on exit. Probably you have to invalidate your view then too.
ThomasZ [MVP]
Roger Onslow
Also off-screen drawing to a bitmap help avoid flicker in general.
NOTE: The WM_ENTERSIZEMOVE etc and how to use it is explained in MS KB
article as follows...
How to Override Full Drag
Article ID: Q121541
Creation Date: 09-OCT-1994
Revision Date: 29-SEP-1995
The information in this article applies to:
Microsoft Win32 Application Programming Interface (API) included with:
- Microsoft Windows NT versions 3.5 and 3.51
- Microsoft Windows 95 version 4.0
Windows NT version 3.5 introduces full drag, which allows you to see the
entire window moving or resizing instead of seeing just an outline of the
window moving or resizing. You can enable full drag by running the Desktop
Control Panel applet and selecting the Full Drag checkbox.
When you resize a window with full drag enabled, the application will
receive numerous messages indicating that the window is resizing. (You can
verify this with Spy.) If this has undesirable effects on your application,
you will need to override the full drag feature in your application.
When the moving or resizing starts, the application receives this message:
WM_ENTERSIZEMOVE (0231)
When the moving or resizing finishes, the application receives this message:
WM_EXITSIZEMOVE (0232)
The above messages act as a notification that the window is entering and
exiting a sizing or moving operation. If you want, you can use these
notifications to set a flag to prevent the program from handling a WM_PAINT
message during the move or size operation to override full drag.
Roger
Thomas Zeisluft wrote in message <34523e03...@msnews.microsoft.com>...
Jeff Fisher
Roger,
Thanks for the info on the kb article. Do you have any ideas on handeling the
drawing of controls I don't do anything with? For example, event the toolbars
flicker and I don't do a thing with those.
TIA
Jeff
Jeff Fisher
Thomas,
Thanks for the info.
> You should set a flag to disable your OnDraw code
How would I handle the redrawing for the controls in the view that I don't
paint myself? For example, I have a TreeView and a ListView, but I don't
override these controls. How would I go about handeling these.
The flickering is so bad even the toolbars seem to move around. I've checked a
couple of commercial apps and they suffer the same thing. I guess I'm not
alone. :-(
Jeff
Gordon Walker
On Tue, 28 Oct 1997 22:54:54 EST, Jeff Fisher <jfi...@megalink.net>
wrote:
>The flickering is so bad even the toolbars seem to move around. I've checked a
> couple of commercial apps and they suffer the same thing. I guess I'm not
>alone. :-(
My MFC app does not exhibit flickering the toolbars when I resize it.
What are the commercial apps that do this?
--
Maranatha
Gordon Walker (remove underscore for email)
* Send NO unsolicited email *
Justin Rudd
Missed the original thread, so I'll reply here.
The flicker he is describing is when the CFrameWnd derivative erases it
background. the code for CFrameWnd::OnEraseBkgnd will check for an
active view...if it has one...it doesn't erase because MFC assumes that
the view ( or a window with the AFX_IDW_PANE_FIRST id ) will take up
whatever room is left. If there is no active view it just calls Default
which erases the entire background.
Since I missed the original thread I don't know what your programs UI
layout looks like. If you are using the default MFC framework it should
call CFrameWnd::SetActiveView for you. If you create the view
yourself...you have to tell the frame window that it will use the view
you just created as the active view.
If anybody is interested in seeing this flicker...generate an SDI app
with splitter support. In OnCreateClient call
CSplitterWnd::CreateStatic. Now pass in 2 runtime classes of CDialog's
not CViews ( CSplitterWnd will try to do a SetActiveView if you pass in
a CView derived class ). Resize the window...when you do this you
should get A LOT of flicker, everywhere, behind the status bar, toolbar,
etc.
If anybody is interested I can post a sample here.
Justin Rudd
Stingray Software
Visit http://www.stingsoft.com/ for demos of our 100% MFC Products
Jeff Fisher
Ok, I'll see what effect that has.
Thanks
Jeff
Jeff Fisher
Gordon,
The apps I looked at were, StarTeam Version control, and the version of MS
Front Page that comes with Visual Studio. Both Flicker badly when resized.
Also, any of the example programs I run exibit the same thing.
The thing that gets me is that Visual Studio is rock solid, and if you resize
Explorer it doesn't flicker either. I thought it was maybe my machine, but
I've noticed this on at least one other computer I work on.
Jeff
Jeff Fisher
Justin,
You pretty much summed it up. I've got an app that is similar to Explorer and
has splitter support. I'm using form views that contain a TreeView and a
Listview control respectively.
At this point I've pretty much just left the default stuff that gets created
with appwizard, however I've drived a new splitter window so that I can get rid
of the ClientEdge look. I thought maybe that was causing the flicker, so
that's why I started really looking at the other apps. They all seem to do it.
So you think if I force the ID of the first form view to AFX_IDW_PANE_FIRST
it would stop the flickering? Having moved to MFC from OWL not too long ago
I'm not up on all the ins and outs yet.
Thanks
Jeff
Justin Rudd
Jeff,
If you are using views ( form views in your case ) that should happen
for you. After creating your views ( which I will assume you create
with CSplitterWnd::CreateView ), you might try calling
CSplitterWnd::SetActivePane. This will test the CWnd pointer that is
contained in the pane. If it is a CView derived class it will call
GetParentFrame()->SetActiveView with your pointer. If it isn't a CView
derived class it will emit a trace statement.
Also...since you are using a form view, beware. They cause lots of
flicker and it flickers so bad it could make the tool bar look like it
is flickering. Are you sizing the tree view and list view to the entire
size of the form? If this is the case, look at the levels of erasing
and painting you are doing.
1) Left Pane - Form View erases and paints
2) Tree View erases and paints.
3) Right Pane - Form View erases and paints
4) List View erases and paints.
You might try using CTreeView instead of CFormView and CTreeCtrl.
As for forcing an ID, no you can't do that. The Splitter window will
create one with that ID for you. Take a look at the code for
IdFromRowCol for how the splitter window comes up with ID's for its
panes.
The first thing I would do if I were you, is determine, do I need
CFormView classes? If you really do need these classes, you might
consider taking over erasing yourself. For erasing you would just get a
series of rects and erase only those portions. That way the area behind
the tree wouldn't get erased.
HTH,
Justin Rudd
Stingray Software
Visit http://www.stingsoft.com/ for demos of our 100% MFC Products