Paul,

First off, thanks for the help. I appreciate it - even if you're not a
programmer :-p

But based on your knowledge of the zillion ways to design
"error numbers", you know 0x4 and 0x7 are not errors.

In this case, absolutily. Its fed into the SetPixelFormat function, which
is rather unlikely if it would be an error number. Besides, the
ChoosePixelFormat's description mentions it as "the return value is a pixel
format index (one-based) that is the closest match to the given pixel format
descriptor."

And you also know that Microsoft loves GDI and hates OpenGL.

The both of the above are in fact GDI functions. Doesn't mean that they
could not OpenGL at the same time though. :-)

In the order of things, you open a graphics window first.

Currently I'm initializing the OpenGL context in the WM_CREATE event of the
control (which is placed in a dialog). At that moment nothing has been
drawn yet - though the OS should be aware that whatever gets drawn should be
done in the GUI mode. As indicated in the header of the executable.

When you create your HWND, you need to make sure that
it has the CS_OWNDC set for its style."

Just added it, but it doesn't (seem to) make a difference.

"PFD_DRAW_TO_WINDOW ===" [suggests a window needs to be in the picture]

As the end result ? Yes. (as opposed to a(n invisible) memory DC).

And there are articles on doing it the hard way.

Several. I took my cues from a "NeHe productions" tutorial
http://nehe.gamedev.net/tutorial/lessons_01__05/22004/

As for the hard way ? What do you mean ? I'm programming in Assembly,
meaning I have to do /everything/ myself. :-)

Also, I tried tossing in "GDI" in a pixelformat search for
Windows in Google, and these might well be the enumerations you seek.

I cannot verify that. I googled for "#define PixelFormat24bppRGB", and
got several like this:

PixelFormat24bppRGB = 8 | (24 8) | PixelFormatGDI

http://caca.zoy.org/browser/libpipi/...PixelFormats.h

, which are always large, bit(/byte)-mapped numbers (and not just a small,
one-based index).

(Don't you just hate it when MS throw a list with names at you, but
"forgets" to mention the values that they represent ?)

Perhaps if you toss enough of those into Google,
you'll eventually find a gdi.h or something.

:-) See above. I searched some more, but nothing that I get an "Ah HA! So
/thats/ it " feeling with.


Currently I am, in regard to the setting-up of the OpenGL context (and
specifically the ChoosePixelFormat function), at the end of my rope. I have
no idea why it would return different results depending on from which
environment (CLI / GUI) it is started, and thus no idea how to fix it.
And even less why it works for one machine, but not for another (probably
videocard driver related, but thats just a guess)

But after a lot of pondering about a dependable, but at the same time simple
way to get the initialisation of the OpenGL context delayed I got a
brainfart: Though its hackish, it seems to work nicely: Before creating
the "OpenGL dialog" I first create a modal dialog which closes as soon as it
fully created, forcing my program to switch to GUI mode(1). That way the
"OpenGL dialog" itself is never started in CLI mode.

(1) I did first search for a "switch to GUI mode" method/function, but was
unsuccessfull in it. :-\

Regards,
Rudy Wieser