Re: context type: UNDECIDED vs. CHROMIUM vs. NATIVE

Brian,

Thanks for the explanation - that's very helpful.

> The only time a context should be in the UNDECIDED state is when it's
> been created, but has never been made current.  Perhaps the WGL code
> is missing an assignment to set the context's type in wglMakeCurrent.

What if it's never made current!?

Apparently, although it may be "wrong", what many (or at least 2) "real world"
apps do is create a context, check some capabilities, and if it's not up to
snuff, the context is deleted, without ever being made current.

So, stubDestroyContext gets the context and does nothing to it, since the
context type is UNDECIDED, and as a result the window stays up...


**So, what should stubDestroyContext do when the type is UNDECIDED?**


Thanks,
Jon


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click