win32 & OpenGL

ok…first off this is a win32 problem…
not really an opengl problem - but i am
constructing a new windowing wrapper lib for
use with opengl.

EnumerateDisplaySettings()
requires that you
set the dmDriverExtra member to indicate the size, in bytes, of the additional space available to receive private driver data.

what i want to know is simply…how can you
determine this value - or is this for use
with the cbWndExtra field of WindowClass???

Any help would be great…ive looked on
the microsoft dev site…but im still non
too sure about this…

thanks,
Matt.

EnumerateDisplaySettings()
requires that you
set the dmDriverExtra member to indicate the size, in bytes, of the additional space available to receive private driver data.
I don’t believe you have to set any of the fields of the DEVMODE structure before calling EnumDisplaySettings(). This field is not even set by the function. It sets the following fields.
dmBitsPerPel
dmPelsWidth
dmPelsHeight
dmDisplayFlags
dmDisplayFrequency

Ok thanks man…

  • its hard to know what exactly is & is not
  • supposed to happen…according to MSDN you
    have to set this field…hehe…guess not.
  • sorry if posting this topic is annoying…
    & not really an opengl issue…jst i really
    needed some feedback.

thanks again, now back to coding

Note that some drivers will write beyond the DEVMODE structure even if you don’t have extra space there. What I do is allocate a struct which adds another 1024 bytes after the DEVMODE and cast that to DEVMODE*, which works around these driver bugs.

cheers m8…

  • i was sure there was a problem…i had
    allocated xtra memory in my old cold…i think
    about 6k… & this fixed the problem…

shame microsoft didnt document this very
well.

hehe…i will go back & modify my new code +
add 1k to 2k to the struct…lol this is
all kinda messed up

many thanks,
matt.

Originally posted by jwatte:
Note that some drivers will write beyond the DEVMODE structure even if you don’t have extra space there. What I do is allocate a struct which adds another 1024 bytes after the DEVMODE and cast that to DEVMODE*, which works around these driver bugs.

Whose drivers do that? Just curious …