Win32 Screen Buffering Problem

I'm trying to write a GDI wrapper using Win32:

So I maintain a DC in memory the whole time which is supposed to have my screen shot where I put all my graphics objects, then when its time to paint I always just bit transfer to the real DC. However this doesn't seem to be working, heres the problem



//This does not work:

FillRect(memHDC, Rect, BackBrush);
BitBlt (hdc, Rect.left, Rect.top, (Rect.right - Rect.left), (Rect.bottom - Rect.top), memHDC, 0, 0, SRCCOPY);


//However this does work:

FillRect(hdc, Rect, BackBrush);

//Also this works

SelectObject(memHDC, hBitmap);
BitBlt (hdc, x, y, width, height, memHDC, 0, 0, SRCCOPY);

Why is that?

Instead of writing your own GDI wrapper, why aren't you using GDI+? Don't reinvent the wheel.

From MSDN:


Purpose
GDI+ is a class-based application programming interface (API) for C/C++ programmers. It enables applications to use graphics and formatted text on both the video display and the printer. Applications based on the Microsoft® Win32® API do not access graphics hardware directly. Instead, GDI+ interacts with device drivers on behalf of applications. GDI+ is also supported by the 64-bit Windows® operating system.

Where Applicable
GDI+ can be used in all Windows-based applications. GDI+ is new technology that is included in the Microsoft® Windows® XP and Windows .NET Server operating systems. It is required as a redistributable for applications that run on the Windows NT® 4.0 SP6, Windows 2000, Windows 98, and Windows Millennium Edition operating systems.

Developer Audience
The GDI+ C++ class-based interface is designed for use by C/C++ programmers. Familiarity with the Windows graphical user interface and message-driven architecture is required.

Run-time Requirements
The Gdiplus.dll must be copied to the system directory of the user's computer. For information about which operating systems are required to use a particular class or method, see the Requirements section of the documentation for the class or method. GDI+ is available as a redistributable for Windows NT 4.0 SP6, Windows 2000, Windows 98, and Windows Me. To download the latest redistributable, go to http://www.microsoft.com/msdownload/...psdkredist.htm.

What's New In GDI+?
GDI+ is different from GDI in a couple of ways. First, GDI+ expands on the features of GDI by providing new capabilities, such as gradient brushes and alpha blending. Second, the programming model has been revised to make graphics programming easier and more flexible.

Changes in the Programming Model
The following sections describe several ways that programming with GDI+ is different from programming with GDI.

Device Contexts, Handles, and Graphics Objects
If you have written programs using GDI (the graphics device interface included in previous versions of Windows), you are familiar with the idea of a device context (DC). A device context is a structure used by Windows to store information about the capabilities of a particular display device and attributes that specify how items will be drawn on that device. A device context for a video display is also associated with a particular window on the display. First you obtain a handle to a device context (HDC), and then you pass that handle as an argument to GDI functions that actually do the drawing. You also pass the handle as an argument to GDI functions that obtain or set the attributes of the device context.

When you use GDI+, you don't have to be as concerned with handles and device contexts as you do when you use GDI. You simply create a Graphics object and then invoke its methods in the familiar object-oriented style — myGraphicsObject.DrawLine(parameters). The Graphics object is at the core of GDI+ just as the device context is at the core of GDI. The device context and the Graphics object play similar roles, but there are some fundamental differences between the handle-based programming model used with device contexts (GDI) and the object-oriented model used with Graphics objects (GDI+).

The Graphics object, like the device context, is associated with a particular window on the screen and contains attributes (for example, smoothing mode and text rendering hint) that specify how items are to be drawn. However, the Graphics object is not tied to a pen, brush, path, image, or font as a device context is. For example, in GDI, before you can use a device context to draw a line, you must call SelectObject to associate a pen object with the device context. This is referred to as selecting the pen into the device context. All lines drawn in the device context will use that pen until you select a different pen. With GDI+, you pass a Pen object as an argument to the DrawLine method of the Graphics class. You can use a different Pen object in each of a series of DrawLine calls without having to associate a given Pen object with a Graphics object.

I'm writing this program for Windows CE on an x86 processor single board pc. I didn't really see anything that explicitly states that GDI+ available for that platform? plus i didn't really know GDI+ was the greatest thing since sliced bread which is what it sounds like; i'm new to programming win.

I'm starting to really see the limitations of CE in the graphics world for x86. Since I'm not on an ARM platform, which is the uP that most CE programmers work on (pocketpc), I'm finding that many graphics engines are not available to me.

I wonder this would work on XPembedded?

Terms you are using in your post are slightly confusing that is (I think) why Thingol responded with lengthy post.

Quote:

---

Originally Posted by niceguyeddie

I'm trying to write a GDI wrapper. . .

---

From a code snippet it does not look like wrapper. It looks like you are using straight Windows GDI.

Quote:

---

Originally Posted by niceguyeddie

I'm writing this program for Windows CE

---

and yet in your previous posts you have mention:

Quote:

---

Originally Posted by niceguyeddie

Re: Win32 Screen Buffering Problem

---

Quote:

---

Originally Posted by niceguyeddie

using Win32:

---

You do not need GDI+ for task like that. Platform SDK that you are using is sufficient to do the task.

As how to resolve your problem, you probably do not copy content of the graphic into memory DC. It is not enough to create compatible bitmap; you have to fill it with data from some source and that is not shown in your post. Could you post code that you use to manipulate bitmap?

Quote:

---

I'm writing this program for Windows CE on an x86 processor single board pc.

---

Ohoh, Windows CE is a different beast. There's no GDI+ or other amenities available for Windows CE, I guess.
I've seen a Windows CE in a single-processor x86 board, and it is being used for a small terminal with 16 keys and a touch-screen.
I don't know if your configuration can run the .NET Compact Framework (and use the good new VB.NET for .NET Compact Framework), for instance.

Window CE has own GDI and supports (with some limitations) almost the same graphical output as Win32 platforms. Basically Windows CE do not supported is coordinate mapping. But you can draw text, rotate text and draw shapes the same way as in desktop versions of windows.

I am not sure why you are referring to .NET since you do not need it to develop applications for CE. Since 1999 (or earlier) m$ released a toolkit for CE that can utilize VS 6.0 and supports multiple releases of CE.

JohnCz, yes CE has its own GDI, it's a striped down version of the normal win32 from desktop version but I don't think you can rotate text easily. Now maybe with this GDI+ you can easily. Looks like .NET Compact Framework has only some GDI+ stuff:

heres something from MSDN

What's available?
Due to the resource constraints, there is no full GDI+ support in the .NET Compact Framework. As you may know, the services of GDI+ fall into the following three broad categories:

2-D vector graphics
Imaging
Typography
Of the 2-D Vector Graphics in the .NET Compact Framework, only the core drawing primitives like Ellipse, Line, Image, Polygon, Rectangle, String, Fill Ellipse, Fill Polygon, Fill Rectangle, and Fill Region are supported by the Graphics object.

In the Imaging category, the Bitmap class doesn't support image manipulation (at the bit level) or saving the bitmap to file. Additionally, the double-buffering that's supported by the .NET Framework through ControlStyles is not available either.

The Typography category is concerned with the display of text in a variety of fonts, sizes, and styles. GDI in the .NET Compact Framework provides support for this task, except for the usage of any sub-pixel anti-aliasing.




Here's the thing - in this embedded system i need to sample data from transducers reliably. Its a safety monitor, so that if pressure gets to high in something it will do something. I wasn't using .NET because you don't know when its going to do garbage collection, etc.. theres unknowns. With win32 there isn't.

I'm going to look into integrating high priority win32 threads with a .NET user interface maybe.

I do not have emulator installed, but this sample I wrote should be virtually identical to what you need to code.
I capture screen into dc and later BitBlt it into a window.