I saw your code. I can now underststand clearly what is your intention. Lets rephrase: You have a tab control in a dialog. In the tab control's display area you want to display a dialog that is bigger than the display area. You use a scroll bar to scroll the content of the dialog. You have a background image in that dialog, and you want that image to remain in one place and only the controls to move when the dialog is scrolled. In your code there are two problems that cause flickerind. A small problem and a big problem. The small problem is the line: BOOL ret = CDialog::OnEraseBkgnd(pDC); in the CChild2::OnEraseBkgnd function. When you call that function, your picture will be erased with the default brush (defined in the WNDCLASS). Then you paint back your picture on the screen. The erasing and repainting will cause flickering. The solution is simple, delete that line and return TRUE when finishing the CChild2::OnEraseBkgnd function. The big problem is that when you scroll the window you move the background (up or down) and after that repaint the background back to it's old position. Because of that, your picture moves up and down quickly and that causes another flickering. This problem is difficult because you MUST scroll the window, and after that you MUST repaint the background image. The solution is to change fundamentally the way you do the job Instead of having one dialog with controls in it and a picture in the background, you will need two windows, one dialog box with all the controls in it having a transparent background, and another window with the picture placed behind your dialog. The transparent dialog will alow you to see the picture in the other window. When you scroll your dialog, the picture will not move because it's in the other window, so there is no need to repaint it. In order to make the dialog transparent, you need to create it with the style WS_EX_LAYERED, then call the SetLayeredWindowAttributes function. These are new features, the VS 6 doesn't know them. But the function is in the user32.dll file and the WS_EX_LAYERED is defined as being 0x00080000 . If you know how to call a function from a dll you can solve the problem. I found your problem challenging and I made a project with the technique I described. There is no flickering at all. If you let me know your email address I will send you the full project.

Your blog is in Chinese, a language most of us don't speak. From your code you ommitted the most important part, the OnPaint function. Not knowing what you have there I can only give you general advises. If you have a picture in the window, when you paint the background you delete the picture, and after that you paint it again. That will cause flickering. Repaint the background only in the portions where there is no other graphics. Basically make sure that during a repaint of the window, every pixel is repainted only once. Never clear anything from the window. Just overwrite. Double buffering is the best, just don't forget, dont delete anything from the screen and don't repaint the background where it's not necessary. Only overwrite. Do not use ScrollWindow to scroll the image, repaint everything to the nev position. If your window is partially covered by another window, the portion of the image scrolled out from under the other window will be black (or whatever the background color is). If you're trying to scroll the controls form a dialog box, you don't need graphics processing. Each control in the dialog is a window. Obtain a CWnd* pointer to each of them using GetDlgItem, then move the control using MoveWindow. Frankly I think scrolling controls is a very unusual way to deal with dialogs. If you have too many controls you should consider using multiple dialog boxes, or maybe, a property page.

Look at BeginUpdateResource.

Quote: "You're wrong (after all MFC developers are skilled people). Try the following code..." You mix MFC with non-MFC, your sample has nothing to do with the MFC framework. I can only hope you'll not compile the release version without fixing an error signalled in the debug phase so I hope you'll not get a runtime error. Thank you for your remark that "invalid pointers references cause runtime errors not assertions (ASSERT it's only a debug tool to intercept such occurrences)". In return, I want to offer you an advice having the same value: If you want to fill a glass with water you shouldn't hold it upside down because the glass will not fill.

modified on Saturday, May 17, 2008 10:49 PM

I'm an old school programmer too, I still use NULL for handles and pointers and 0 for other numeric values but that's not the point. "if(p)" is easier to write and also easier to understand instantly what it means. I'm sure the generated code is the same because the code optimization will elliminate the pointless evaluation of the logical expression from "if(p == NULL)". But if it may be still somehow acceptable for numeric variables it's absolutely absurduous when used on boolean variables. The result of the evaluation of the logical expression from an if statement is a logical value TRUE or FALSE. Code sample:

BOOL b;
... use b ...
if(b == TRUE)

The if statement wants a boolean value, b without any strings attached to it, IS A BOOLEAN VALUE ready to be passed to that statement by writing simply "if(b)". Instead some programmers asks for an additional evaluation of a logical expression. Luckily the compiler is smarter and eliminates that nonsense during the code optimization.

From CMainFrame to CMainFrame (same source and destination) send a WM_COMMAND message: SendMessage( WM_COMMAND, ID_FILE_SAVE_AS, 0);

modified on Sunday, May 11, 2008 6:54 AM

If the target window is a top level window you can install a hook (see WH_SHELL) to be notified about destroying top level windows. But frankly, no matter what technique you use, you can be never sure. If everything looks ok and you send a message to that window, the window still can be destroyed in the same moment(almost the same). Or while is processing your message. Simply there is no way to prevent a foreign window from beeing destroyed anytime. The only thing you can do is to implement thoroughful error processing, verify the effects of each of the messages sent and check regularly if the handle is still for the same window and not reused for another one. Working with a foreign windows is something similar to working with dialog boxes. You can never be sure what stupidity will a user type in an edit box so you have to check everything. I think a window beeing destroyed exactly in the very moment when you need it, is a very rare occurence. Just make sure to limit to minimum the damages of such an event. If your software stops abruptly and hours of the user's unsaved work are gone, that's unacceptable. If the only thing that happens is an error message "Internal error, please repeat the last command", that's acceptable, even if it's not desirable. Even the best software fails sometimes. The only question is how it fails: disastruously or gracefully ?

Let's start with the smallest problem. If you're paid based on number of characters you type then the line "if (this != NULL)" is perfect. Otherwise, it's enough to write just "if (this)". But that's not what bothers you. You leave your readers in the dark, not everybody can guess your point. And your point is that it's absurduous to check the validity of the pointer INSIDE the function. Because that function is a class member, you can call it only having a valid pointer to an instance of that class. If the pointer is invalid, the call will fail and the execution of the function will not even begin. More specifically, a call like pObject->LogID() will fail with ASSERT if pObject is invalid. The call will execute the function only and only if pObject is valid. To check later, in the function, the validity of pObject (locally known as "this") makes no sense. But as I said earlier, if you're paid based on the number of characters you type, that line is perfect for you.