C / C++ / MFC

kalberts11-Apr-20 11:36

kalberts

11-Apr-20 11:36

What else would it be? In C, a pointer is an address, nothing more.

In other languages, such as C#, a reference is a the memory address of an object, comparable to a struct, containing not only the values of the members, but also a pointer to another struct, the class object, with pointers to the various member functions. Also in C#, an array reference is a pointer to a "struct" providing the index limit of the array. If you go back to good old Pascal. any string was headed by its length, any array by fields indicating its upper and lower index limits.

Not so with C. For reasons of space efficiency, space couldn't be wasted on such.

If you are programming in C++, a pointer to a class instance is similar: It points to a struct augmented by a reference to a class object (which may in turn have a pointer to a superclass object, with a pointer to an even superer object, and so on up to the very object class with all the attributes common to all objects. When you call a method for some bottom layer object, a search through this hierarchy is made to find method pointer. For virtual methods defined at a high/intermediate level, a pointer may be found at a lower level that where the virtual function is defined, and different (sub)class objects may provide different pointers to their respective implementations of the virtual functions. Static members at various levels of subclassing may be located in the class objects, common to all subclasses.

If you implement an array in C++ as class with an array member, you may of course store the maximum index as another class member and route all accesses through a member function verifying that no access violates the index limit. Roughly speaking, you could say that that's what happening in C# (or good old Pascal). But both for "performance" reasons (don't make any hard tests! You'd be disappointed!) and for backwards compatibility with classical C, an array name is nothing but a pointer (where you don't have to write the *), and a pointer, whether an array name or an explicit one (requiring a * for dereferencing) is nothing but a memory address.

Oldtimers remember the BASIC functions PEEK(address) and POKE(address) for reading/writing any value at 'address'. I am not sure that C compilers of today allow you to read/write the "array element" at 0[address]. In my student days they did. I certainly hope that they do not today... But then again, there is nothing in the C syntax rules prohibiting it, so why shouldn't you use it?

Richard MacCutchan11-Apr-20 23:40

Richard MacCutchan

11-Apr-20 23:40

Member 7989122 wrote:
read/write the "array element" at 0[address]

The compiler will be quite happy, but the hardware will raise an exception at run time (unless you are on an old 8080 level system).

BTW, some excellent explanations in your replies. Thumbs Up | :thumbsup:

kalberts11-Apr-20 12:01

kalberts

11-Apr-20 12:01

Additional comment: In the 1980s, there was an intense discussion about whether a data item should provide information about its type or not. If the data item knows whether it is 8, 16, 32 or 64 bits, float or integer, or whatever, it is represented once, not in every single instruction operating on it. The instruction code would not need different formats (/additional bits) to distinguish between e.g. integer add and floating add. So instructions - of which there are usually a lot more than values - would be a lot more compact, and the risk of interpreting a value in the wrong format significantly reduced.

An essential element of this approach was to store index limits once, with the array. If every array access makes is own check against array limits, the code/data for this check could grow significantly - way beyond what you are aware of when reading the code for a single access. It looks so tempting, 'I do it only when there is a risk of exceeding the array limits, but save the check when there is not'. I am 100% sure that the compiler (or even runtine system) is a lot more clever than you to make that decision. In languages with runtime array (/object) descriptors, it is possible. In C, or C++ in classical C usage pattern, it is quite difficult.

Greg Utas12-Apr-20 0:20

Robust Services Core | Software Techniques for Lemmings | Articles

12-Apr-20 0:20

Member 7989122 wrote:
In languages with runtime array (/object) descriptors, it is possible. In C, or C++ in classical C usage pattern, it is quite difficult.

The proprietary language in which I worked for many years (designed in the late 1970s) had descriptors built in. The compiler knew the size of each array element, and a descriptor was a pointer to the beginning of the array (as in C++) and its size (number of elements). The compiler then generated code to perform bounds checking on an index at run-time.

If the size of the array was known at compile time, a descriptor wasn't needed; the compiler just did bounds checking against the fixed length. Descriptors were used for dynamically allocated arrays or to reference a subset ("slice") of a larger array.

Much more recently, C++ has added std::span[^] to the STL, which does the same thing.

modified 12-Apr-20 9:46am.

leon de boer11-Apr-20 21:51

leon de boer

11-Apr-20 21:51

It is a historic fact, now days on C99, C11 and beyond you might more correctly use a uintptr_t.

All you want really is the address but how big is that address it could be 16bits on a small micro controller, 32 bit on large CPU or 64bits on 64bit cpu. A void* pointer was usually big enough to ensure it had enough bits to point to any valid address on the CPU. So the size of a void* is completely compiler dependent. Back in the day there were also other features a void* could be cast to and from any other pointer without warning. The reason is obvious you want to be able to copy the address to a pointer of type and use normal c pointer functions.

Now move forward and look at a uintptr_t this is the C99 definition in stdint.h for portability under XSI-conformant systems

Quote:
"an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer".

It acts like a void* pointer with one safety added the conversion to and back is guaranteed, which never was with void* and occasionally cropped up and you can safely do it on any pointer type.

It also means when you look at it in a debugger it shows as an unsigned integer rather than a pointer which is more in keeping with what it really is ... an address to somewhere in CPU memory space.

In vino veritas

How do I add listboxes to a back buffer and use that?

Calin Negru11-Apr-20 21:47

Calin Negru

11-Apr-20 21:47

Member 7989122 thanks for sharing that.

Quote:
the pointer itself is copied to another pointer

this stuck in my mind

PotatoSoup6-Apr-20 5:57

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 5:57

C++11 or previous.
Not C#.
Not Visual C++.
Not .NET anything.

Hello.

I have the following code. It shows a blank listbox. I would like to be able to use multiple listboxes, etc. and put them in a buffer to show later.

C++

//HWND Handle_of_ListBox; // A global defined earlier.

Handle_of_ListBox = CreateWindowEx(
  WS_EX_CLIENTEDGE, // extended window styles
  L"LISTBOX", // list box window class name
  nullptr,
  WS_CHILD | WS_VISIBLE, // window styles
  MainWindow_Width - 400,   // horizontal position
  MainWindow_Height - 300,  // vertical position
  300, // width
  200, // height
  Handle_of_MainWindow,
  nullptr,
  hInstance,
  nullptr
);

I can use the following to show or hide the listbox in the winmain, but I want to show or hide it in a pre-screen buffer.

C++

//ShowWindow(Handle_of_ListBox, SW_SHOW);
//ShowWindow(Handle_of_ListBox, SW_HIDE);

I use the following to initialize a buffer.

C++

void Initialize_FRONT_BUFFER()
    {
	//    I already created these a globals
	//
	//    HDC	HDC_of_FRONT_BUFFER;
	//    HBITMAP	Canvas_for_FRONT_BUFFER;
	//    int		FRONT_BUFFER_WIDTH;
	//    int		FRONT_BUFFER_HEIGHT;
	//    int		FRONT_BUFFER_Temp;


                // The HDC_of_MainWindow was released in elsewhere. So, get it again.
                HDC_of_MainWindow = GetDC( Handle_of_MainWindow );

                // Create the HBITMAP "canvas", or surface on which we will draw.
                Canvas_for_FRONT_BUFFER = CreateCompatibleBitmap( HDC_of_MainWindow, FRONT_BUFFER_WIDTH, FRONT_BUFFER_HEIGHT );

                if (Canvas_for_FRONT_BUFFER == NULL)
                    {
                        MessageBox(nullptr,L"failed to create Canvas_for_FRONT_BUFFER",L"Error!",MB_ICONEXCLAMATION | MB_OK);
                    }

                // Create the HDC "device context", or collection of tools
                //    and brushes that we can use to draw on our canvas.
                HDC_of_FRONT_BUFFER = CreateCompatibleDC( HDC_of_MainWindow );

                if (HDC_of_FRONT_BUFFER == NULL)
                    {
                        MessageBox(nullptr,L"failed to create the HDC_of_FRONT_BUFFER",L"Error!",MB_ICONEXCLAMATION | MB_OK);
                    }

                // Permanently associate the surface on which to draw the
                //    ("canvas") (HBITMAP), with the "set of brushes" (HDC).

                // "select in" the Canvas_for_FRONT_BUFFER into the HDC_of_FRONT_BUFFER.
                HBITMAP Temporary_HBITMAP = (HBITMAP)SelectObject( HDC_of_FRONT_BUFFER, Canvas_for_FRONT_BUFFER );

                // Delete the "canvas" that the HDC_of_FRONT_BUFFER was going to draw to.
                DeleteObject ( Temporary_HBITMAP );

                /// Release the dc of the main window itself
                ReleaseDC ( Handle_of_MainWindow, HDC_of_MainWindow );
    }

I use the following

C++

void Draw_Something_To_FRONT_BUFFER()
    {

        int W=FRONT_BUFFER_WIDTH;
        int H=FRONT_BUFFER_HEIGHT;

        StretchBlt(HDC_of_FRONT_BUFFER, 0, 0, W,  H, HDC_of_Something, 0, 0, W,  H, SRCCOPY);   

    }

Then I put it all to the screen with

C++

void Draw_From_FRONT_BUFFER_To_MainWindow()
    {

        HDC_of_MainWindow = GetDC( Handle_of_MainWindow ) ;

        // Now copy the FRONT_BUFFER to the MainWindow.
        BitBlt
            (
                HDC_of_MainWindow,	// destination buffer, in this case the front buffer.
                0,                  // Horizontal start for drawing.
                0,	                // Vertical   start for drawing.
                FRONT_BUFFER_WIDTH,       // Width to draw.
                FRONT_BUFFER_HEIGHT,       // Height to draw.
                HDC_of_FRONT_BUFFER,  // SOURCE buffer.  We are taking from that back canvas.
                0,                  // Horizontal start copying from.
                0,		            // Vertical   start copying from.
                SRCCOPY             // Just want a straight copy.
            );

        ReleaseDC( Handle_of_MainWindow, HDC_of_MainWindow ) ;

    }

I want the listbox to be added to the front buffer (this is not the screen). It is a collection of buffers that I am combining then later placing them to the screen.

Why does the following not work? It works without the ShowWindow part added. It does not show the listbox this way. What should I be doing to put the listbox in the buffer? I do not want to put a final buffer to the screen and then (after that) put the listbox to the screen. I want it all in the buffer and then the buffer alone to be put to the screen.

C++

void Draw_Something_To_FRONT_BUFFER()
    {

        int W=FRONT_BUFFER_WIDTH;
        int H=FRONT_BUFFER_HEIGHT;

        StretchBlt(HDC_of_FRONT_BUFFER, 0, 0, W,  H, HDC_of_Something, 0, 0, W,  H, SRCCOPY);   

        //This does not show up.
        ShowWindow(Handle_of_ListBox, SW_SHOW);

    }

How do I add listboxes to a back buffer and use that?

Thanks.

Richard MacCutchan6-Apr-20 6:21

Richard MacCutchan

6-Apr-20 6:21

Painting information to the screen should be in the WM_PAINT handler. If you do it in other parts of the program then you will not always get the correct information in the display.

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 6:46

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 6:46

Do you mean like this?

C++

case WM_PAINT:
    {

        PAINTSTRUCT ps;

        HDC_of_MainWindow = BeginPaint(hwnd, &ps);

        Draw_From_FRONT_BUFFER_To_MainWindow();

        ShowWindow(Handle_of_ListBox, SW_SHOW);

        EndPaint(hwnd, &ps);


        return 0;
    }
break;

I tried that already.

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.

Richard MacCutchan6-Apr-20 7:04

Richard MacCutchan

6-Apr-20 7:04

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.

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 7:26

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 7:26

Before I go any further. Thank you for your help.

I am using a listbox just as an example.

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.

How to do it?

Victor Nijegorodov6-Apr-20 8:24

Victor Nijegorodov

6-Apr-20 8:24

PotatoSoup wrote:
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.

First of all remove the calls such as

C++

ShowWindow(Handle_of_ListBox, ...);

from the WM_PAINT message handlers.

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 8:43

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 8:43

OK.

I put things back they way they were.

Now i have tried using

SetFocus(Handle_of_ListBox);

But that did not work.

I can tell that something is still there because I can not click on that area of the main window.

Victor Nijegorodov6-Apr-20 8:49

Victor Nijegorodov

6-Apr-20 8:49

PotatoSoup wrote:
Now i have tried using
SetFocus(Handle_of_ListBox);
But that did not work.

I'll ask you again: define "did not work." Suspicious | :suss:

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 11:07

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 11:07

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.

"did not work." = "I failed at this again."

leon de boer6-Apr-20 21:06

leon de boer

6-Apr-20 21:06

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

case WM_PAINT:
    {
        PAINTSTRUCT ps;
        HDC_of_MainWindow = BeginPaint(hwnd, &ps);
        Draw_From_FRONT_BUFFER_To_MainWindow();
        PaintMyList(Handle_of_ListBox, ps.hdc); // <=== Now the list paints on the DC from the paintstruct
        EndPaint(hwnd, &ps);
        return 0;
    }
break;

In vino veritas

modified 7-Apr-20 3:30am.

Re: How do I add listboxes to a back buffer and use that?

David Crow6-Apr-20 8:59

David Crow

6-Apr-20 8:59

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

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 11:31

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 11:31

"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.

Thank you for asking.

Greg Utas6-Apr-20 12:39

Robust Services Core | Software Techniques for Lemmings | Articles

6-Apr-20 12:39

Perhaps SetThreadPriority if you're concerned about competing with CPU pigs?

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 12:52

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 12:52

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.

Greg Utas6-Apr-20 12:55

Robust Services Core | Software Techniques for Lemmings | Articles

6-Apr-20 12:55

I'm sorry, but that's all I can offer. I write pure C++ with a thin adapter for Windows, so I've never done MFC things. I just tossed it out there because it seemed to address your most recent post.

Re: How do I add listboxes to a back buffer and use that?

PotatoSoup6-Apr-20 18:58

Re: How do I add listboxes to a back buffer and use that?

6-Apr-20 18:58

"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?

Thank you.

Greg Utas7-Apr-20 0:05