Re: How do I add listboxes to a back buffer and use that? - C / C++ / MFC Discussion Boards

PotatoSoup wrote:
How to do it?

Simple, make the ListBox a child of the main window and size it to the client area. That is the standard Windows paradigm that has worked since the 1990s. No need for complicated backdoor processing or multiple device contexts. The ListBox will happily repaint itself whenever necessary.

SOLVED (partially).

I did not need to add listboxes to the back buffer for my program to be basically usable at this time, but I still would like to know how to add listboxes to a back buffer if it is possible as I requested in my *original* post. For that no one here helped me at all in the least.

I did get help getting past a problem, and that was a partial solve. I explain now:

Thank you Richard MacCutchan. If the code is not working, then go back to the basics and debug from there. Thanks, Richard MacCutchan.

Microsoft's CreateWindowExA function (winuser.h) - Win32 apps | Microsoft Docs[^] , which is their page for CreateWindowEx, states: (my underlining)

Quote:
With WS_EX_COMPOSITED set, all descendants of a window get bottom-to-top painting order using double-buffering. Bottom-to-top painting order allows a descendent window to have translucency (alpha) and transparency (color-key) effects, but only if the descendent window also has the WS_EX_TRANSPARENT bit set. Double-buffering allows the window and its descendents to be painted without flicker.

I should have already had that in my code. I looked and it was not there.

From Microsoft: (my underlining)

Quote:
HWND CreateWindowExA(
DWORDdwExStyle,
LPCSTR lpClassName,
LPCSTR lpWindowName,
DWORD dwStyle,
int X,
int Y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
);

My dwStyle was WS_OVERLAPPEDWINDOW, and it should have been WS_OVERLAPPEDWINDOW | WS_EX_COMPOSITED,. I updated it.

Note to future readers: Do not forget to use this WS_OVERLAPPEDWINDOW | WS_EX_COMPOSITED, together when needed.

I found it myself. But, you all did help. I would like to give you all a "+" for your help.

Some of you helped in off-topic replies that were logical to consider when debugging in general. I have found that debugging is almost more important than coding. Thus, for each and every one of you, I thank you.

Thank you codeproject.com .

Thank God for allowing me to find the answer.

modified 9-Apr-20 15:15pm.

PotatoSoup wrote:
My dwStyle was WS_OVERLAPPEDWINDOW, and it should have been WS_OVERLAPPEDWINDOW | WS_EX_COMPOSITED,. I updated it.

No, it is wrong!

WS_EX_COMPOSITED

is an extended window style while

WS_OVERLAPPEDWINDOW

just a window style.
It seems to you "the problem is solved", buut it is only because the value of WS_EX_COMPOSITED is the same as the value of WS_CLIPCHILDREN!
So you should rewrite your sentense to be:

Quote:
Note to future readers: Do not forget to use this WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN, together when needed.

I am thinking about forcing the effect to get past my not knowing how to buffer a created (or subclassed) window, in this case a simple listbox.

I would like some valid comments on what I am thinking about trying next.

When the listbox's (it is just an example of a generic window) information changes, do a screen capture of the listbox.

Then when my main window changes, bitblt that screen-captured listbox to the buffer that I build before replacing the main window to the screen.

I do not want to do it this way.

I am concerned that I might have to create a new listbox window each time that I need to update the listbox and I do not want to have to do that. If the listbox is rarely updated then this might not be so bad, but if the listbox is updated often then that might mean creating a new window for the listbox often. I really do not want to do that. And, as you have noticed (hopefully) this is not about a listbox only. It is about any window like it, just that I am using a listbox as an example.

I am looking for valid observations and valid suggestions.

Please.

I think that David Crow's suggestion was actually valid. Maybe I read his response too quickly and dismissed it too quickly. Sorry. I think that, in a dedicated thread, I can do a screen capture of just the part of the screen where the listbox is and save that for when it is needed. Thanks David Crow.

modified 6-Apr-20 18:20pm.

You do not need to recreate a new listbox window NOT EVER, you can simply change the contents of the window by exchange messages and then asking the existing listbox to update. It works that way for every windows type. You see that in standard file open dialogs the directory names change in the listboxes and they aren't making new listboxes.

Anyhow I gave you reference of a fairly complex listbox example on the post below for you to look at just look at main.cpp

So you seem to be deeply confused about something with Windows.

I am half thinking you may be talking about an Undo/Redo function for a window but not know to call it that. If you are trying to do that it is done by creating a history structure and you are creating a history window.

In vino veritas

Not exactly Following what you are trying to do so can I provide a reference sample
GitHub - LdB-ECM/ListPlay: Windows ListBox Sample[^]

That has a gradient and icons etc as sort of a complex example .. so can you explain what you are trying to do better.

I don't understand why you would capture the screen image like not ever it's always faster to just draw stuff or hide/show stuff.

Perhaps describe or draw a rough image of what you are trying to do on screen.

In vino veritas

modified 7-Apr-20 3:27am.

Thank you.

Your referenced Main.cpp (and accompanying files) is Visual Studio.

Hours of fighting with yet another visual studio mess and my dog might as well have been chewing on the keyboard.

I have forced yet another visual studio mess to compile with no visual studio installed. I looked through it's logic and the referenced program is no use to me.

All that I found unique from my code was some subclassing that I can already do and some transparencies that I can already do. I see no use in either of those and any of the referenced visual studio pseudo-code addressing my *original* question.

Please do not send me any more Visual Studio mess.

Thank you for attempting to help. It is not your fault that visual studio is so far from Stroustrup's genius.

Back to the original issue:

When I create a window in C++ and place a bitmap in the background and place buttons and listboxes, etc. on that window, it can compile and I can see these.

When I do similar but use a buffered background where I place a bitmap and then place the buffer to the screen then place buttons and listboxes, etc. on that window, it can compile but my child windows are invisible as soon as I click on any thing in the main window for any change of that main window.

Maybe I might have explained the original issue better, maybe?

But, you offered help, and that was nice and I thank you.

You are making a mountain out of a molehill.

First it was pre-compiled in the debug directory, you didn't have to compile anything
Second main.ccp is stock standard C++ code will compile on any C++ windows compiler
Third you can also just rename main.cpp to a main.c file remove a couple of "::" and it would compile on any C windows compiler

What I do now know is your level of programming knowledge which is useful if you want me to try and help you.

So basically I am reading your bitmap paint is drawing over the top of the listboxes and other windows, it would be useful to see the original code that creates the parent window. I am basically thinking you are trying to draw a bitmap where the coloured gradient occurs on my sample is that correct? Notice my listboxes draw over the top of that gradient and I could turn it to a bitmap if that helps you. I might throw up a sample doing that, note I will put just the main.c and the exe this time.

Update: new sample that draws the beatyy.jpg image under the listboxes .. is that what you are trying to do?
Just run the pre-compiled exe file to test
GitHub - LdB-ECM/ListPlayBmp: Windows list with background Image sample[^]
Or the more generic example
Windows_Samples/ListJpg1 at master · LdB-ECM/Windows_Samples · GitHub[^]

Anyhow lets take a couple of stabs at this

1) Check you have the WS_CLIPCHILDREN flags set on the parent window ... read what it does
Window Styles (Winuser.h) - Win32 apps | Microsoft Docs[^]

2.) If all else fails because you really have cocked something just invalidate them after you paint the background (that probably means after EndPaint in your WM_PAINT message handler).
Here hwnd refers to the handle of the child listbox window etc

InvalidateRect(hwnd, NULL, TRUE);

This explains why it forces the redraw to happen but don't use it unless you have to because it will cause the listbox to flash as it redraws and is a horrible hack.
InvalidateRect function (winuser.h) - Win32 apps | Microsoft Docs[^]

Now if you have to use 2 you have a horrible structural issue with your code and I will try to explain how to fix it because we need to get the bitmap background draw much earlier on in the paint process.

In vino veritas

modified 8-Apr-20 4:59am.

Because you are still doing it wrong. Creating Windows applications that correctly display bitmaps, textboxes, listboxes etc., is standard and works all round the world. If you want multiple controls in a single Window then you must place them alongside, not on top of, each other. The best way to do that is to use a Dialog which is designed for exactly that purpose.

PotatoSoup wrote:
...and place buttons and listboxes, etc. on that window...

Are you adding these controls at runtime?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

He is doing it runtime, go to his first post you can see he is inserting the ListBox into the main window, that code will be in the WM_CREATE of a window or WM_INITDIALOG of a dialog.

I assumed in his rather crazy round about way what he was asking is to paint the ListBox to a memory DC rather than the screen DC.
He seems to be calling HDC "buffers" see his names ===> HDC_of_FRONT_BUFFER
Anyhow that is easy you just use the WM_PRINTCLIENT message which you subclass onto a class and handle it.
WM_PRINTCLIENT message (Winuser.h) - Win32 apps | Microsoft Docs[^]
You use that mainly for printing a screen capturing of a window or remote terminal programs where you need to send the screen data.

So I gave him an example that does that, but he either doesn't understand or he is doing something really strange.

In vino veritas

I'm glad you understood it. I was just rolling rocks to see what crawled out.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

I`m trying to build a barebones MFC app. I`m used to C# Forms, but I`m having a tough time in MFC though.
I`m creating a new MFC app in the New Project dialog and in the Wizard I pick Dialog based app as app type. However after creation I can`t open the resource (in the resource view) to fill it with controls.

I have not used MFC for years, and I would not recommend it for any new projects. As to the problem, it is difficult to guess what the issue is without more details.

it`s a totally fresh project, no edits after pressing the `Finish` button in the create app wizard/dialog. I`m expecting to be able to add new controls from ToolBox but obviously something is missing...

I do not think MFC apps make use of the Toolbox. If you double-click the resource file (projectname.rc) in Solution Explorer, it should open the Resource Editor where you can add the various controls to your dialog.

fearless_ wrote:
... after creation I can
t open the resource (in the resource view) to fill it with controls.</blockquote><br />
Define "can
t open the resource".
If you open the resource View then what do you see in it?

fearless_ wrote:
... after creation I can`t open the resource (in the resource view) to fill it with controls.

Define "can`t open the resource".
If you open the resource View then what do you see in it?

I don`t see the resource. I probably just need a mere WinMain.

modified 6-Apr-20 9:59am.

fearless_ wrote:
I don`t see the resource.

I already told you where to find it, or you can just use the View menu item to open the Resource View.

Sorry my wording is wrong, I can`t see the designer.

What designer are you referring to?

the screen area where the dialogs are assembled.

In have explained twice already, open the resource view, either from the View menu, or use Ctrl+Shift+E.

I got it, but only after you closing and opening the project again. Sorry for making ripples over nothing.