The listbox seems to be there but invisible.
The way that I did it before, the listbox was there but invisible.
I could detect clicking on the area where the listbox was supposed to be was not allowing me to click on the main window.
I click where the listbox is blocking other things, but nothing happens.
It is invisible or just blocking my clicks to the main window. I want to see the listbox and interact with it.
A ListBox is just a Window, so if you call ShowWindow using its handle, then it may cover part of your main window. That in turn will receive a WM_PAINT message and redraw itself, which may well have the effect of hiding the ListBox. I am really having difficulty understanding what you are trying to do here. The most common use of ListBoxes is as part of a DialogBox, or CFormView. If you want it as part of your MainWindow then you need to add it into the client zone, and not overwrite it with the main window.
It is the window (a window) itself which is represented by a listbox that I am interested in being able to place in a buffer and then placing that buffer to the screen.
It could be a textbox (created via a window) or some subclassed window from elsewhere like a subclassed browser window or a subclassed game, etc. I want to be able to put all of this in a buffer before placing the result to the screen. Does that help to explain it?
Here is where this issue was discovered:
I noticed that sometimes on some computers that multiple items show up on the screen one at a time slow enough that I and other people detect a lag in the screen being fully created. Memory overloaded, or cpu overloaded, or too much other programs running for smooth response at the screen level. I do not want that. I prefer that my program places everything in a buffer then places that one cohesive buffer to the screen, and not one piece at a time. I can do this with text. I can do this with bitmaps. I should be able to do this with windows (listboxes, textboxes, subclassed outside windows).
I tried. I studied. I tried placing almost randomly attempts to break through my ignorance of how to do this.
I noticed that sometimes on some computers that multiple items show up on the screen one at a time slow enough that I and other people detect a lag in the screen being fully created. Memory overloaded, or cpu overloaded, or too much other programs running for smooth response at the screen level.
I guess that meant that I was disappointed with my current attempt to add a generic window to a buffer and then to be able to put that buffer to the screen (showing the window).
I have been trying to create or subclass a window (in this example a listbox), and place that window (I guess as a child window?) into or on a buffer, and then place the buffer to the screen. It "did not work." meant that I failed in the attempt.
Same goal of adding a listbox to a back buffer and using that. Generally, the listbox is just an example of some window that I can get a handle of in my attempts.
I am still suggesting you are doing this all wrong but I can fix this problem if you really are manually drawing the list.
To me it sounds like the listbox should be a child within some other window and you are just trying to do this in some crazy manual way. If it was child it would draw itself when needed with zero code needed from you. However if you are manually doing it you could try this
Copy all the code in the WM_PAINT function of your listbox and place it inside a function like so
void PaintMyList (HWND Handle_of_ListBox, HDC Dc)
// Paste your current list box WM_PAINT code here
Now replace the PaintStruct stuff and simply us the HDC passed on the interface and use Handle_of_ListBox
where you need a handle .. okay check it all compiles. So we are clear all you are using from the PaintStruct
is the DC and the DC you are to use is declared on that function interface so you can remove all references
to the PaintStruct.
Now use a variant you posted above with the one call change
HDC_of_MainWindow = BeginPaint(hwnd, &ps);
PaintMyList(Handle_of_ListBox, ps.hdc); // <=== Now the list paints on the DC from the paintstruct
This approach, even if you somehow managed to get it to work, sounds kludgy at best.
If your program is causing this much lag, it sounds as though way too much work is going on in the UI thread. The main/primary thread should do little else besides UI-related stuff. Everything else should be handled by secondary threads.
"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
"sounds kludgy" is a start. I can accept that as the beginning of a suggested answer.
I can multi-thread. If you are saying that you know of how to solve this by multi-threading and thus placing a window that is (in this example) a listbox (or some other generic window) to a back buffer, I am ready for that instruction. If you simply did not read my original question and then fired off a general cutting response with no valid logic, then I can understand that and it is ok. I have scanned and responded wrongly myself a few times. If you have a valid solution keeping to answering my first post, then I am ready to read it. If you can this with multi-threading, then please tell me how.
I found this lag in someone else's program that I had nothing to do with coding. I do not recall seeing it in any of my current programs that I wrote. Their program is a really nicely written program that does a lot of things well. But, when their program is running and at the same time some other huge programs (plural) with intense cpu use and intense memory use are running, then I saw a lag that was enough for me to see postings of sections of their program to the screen.
If someone is running my programs then however intense the cpu and memory usage is by any other running programs, I do not want the user to see any lag of sections of my main window being put to the screen. I would prefer that my programs get its work done building a screen buffer before placing anything to the screen.
You guys are great. You seem to have misread what I am asking and yet you still gave an answer that I find useful. Thanks. I could use your suggestion of SetThreadPriority for my screen capture of the listbox (in using a dedicated thread for the capture) if I do not find a way to place the listbox into a buffer. I like this site.
I still would like to be able to put a listbox (or other window) into a graphics buffer.
"I write pure C++ with a thin adapter for Windows". That is one of the most impressive comments that I have read on this and most programming sites within the last year. That reads like an advisable goal.
How would you approach a quest like this as my first post explains?
Victor states that you're not doing anything with MFC, so I must have jumped to the wrong conclusion when I saw your code creating a window. I just run my stuff as a console app that ultimately uses nothing but std::cin, although it can also read commands from a file.
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.
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.
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)
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.
My dwStyle was WS_OVERLAPPEDWINDOW, and it should have been WS_OVERLAPPEDWINDOW | WS_EX_COMPOSITED,. I updated it.
No, it is wrong!
is an extended window style while
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:
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.
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.
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.
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.
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.
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
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.
Last Visit: 9-Aug-20 8:06 Last Update: 9-Aug-20 8:06