Thread: Are DC Pen handles independant?

O_o

You've stumbled into the world of virtual identifiers.

If you had selected a created a pen--via `CreatePen'--with a specific color, the effects of the `SetDCPenColor' call would not have been seen until you invoked `SelectObject(hDc, GetStockObject(DC_PEN));' and the color of the created pen would remain unchanged.

The `SetDCPenColor'--and related--API does not set the color of the pen currently held by the context.

The `SetDCPenColor' API only mutates the virtual object--here the `Pen'--owned by the context.

(I don't want to confuse you, but I can't think of a better way to explain virtual identifiers.)

You can think of `HTHING' as pointers to elements within an array.

Code:

PEN * global = malloc(sizeof(*global) * maximum_pens); /* whatever */

Each `HTHING' is an identifier--here the address stored by the associated variable--referring to one of the global objects--here the `global' array--as a calculated offset. In other words for this example, the identifier `1' would actually be `*(global + 1)' when evaluated by the API.

Now, that explains a good bit about what `HTHING' does "under the hood".

However, that only covers real identifiers. The API also needs virtual identifiers because some resources are private--not global. We can create virtual identifiers by reserving a given range of values--here we consider negatives. In other words for this example, the identifier `-1' would actually be `*(context->resources[1])' when evaluated by the API.

I've obviously glossed over a lot of stuff, but the "stock objects", in a very general way, work as these virtual identifiers. (Well, I completely fabricated the examples. A real implementation of virtual identifiers is a lot more complex yet safer and more robust.) The `GetStockObject(DC_PEN)' object--the `HPEN' result--is really an identifier that tells the API to use the `HPEN' owned by the device context so not a real `HPEN'.

[Edit]
Actually answering the questions:

1): No. Setting the color of the, internal, pen owned by the context is the expected behavior.
2): No. You can cache shared resource and select them into different contexts as needed. The limiting factor, as for sharing, is that you can't share the same bitmap for multiple contexts at the same time.
3): No. You can do an experiment using created bitmaps--bitmaps are easily muted while fonts and pens need to be created with most attributes fixed--to see this in practice, but the above explanations for virtual identifiers should explain what you are seeing.
[/Edit]

Soma

H* just means a HANDLE, an opaque type that doesn't necessarily map to a physical address. It's internal structure is really irrelevant though, it just represents some allocated resource (in this case a LOGPEN structure plus maybe some ancillary information). Anyway, there's no telling why they decided to do things the way they did, just another one of those oddball idiosyncrasies of the WIN32 API, I guess...