OpenGL in COM/ATL

Quick question for all of you. Has anyone attempted/succeeded at implementing and OpenGL-based controls in a COM/ATL style control?

Please exclude MFC based ActiveX controls from this list, as I’ve already done that myself. There’s a couple inherent disadvantages I’ve found with doing it the MFC route, particularly the message handling.

I’m not totally familliar with ATL or COM at this point, but I’m willing to learn.

– Question comes to mind… if I’m interested in COM for my 3D… then why not just use D3D! Heh heh heh… don’t go there.

Siwko

Wow… I actually found an example of what I’m looking for, and of all things, Microsoft provided it.

Anyway…

If anyone else has any more info, let me know.

Siwko

Hi Siwko !

Not that I am really interested in COM (I hate it since I tried D3D and MS Agent with those little characters who speak !), but could you give me the link to the example you found ?

Best regards.

Eric

P.S.: what problem did you have with an MFC ActiveX control and message handling ???

Originally posted by Eric:
Not that I am really interested in COM (I hate it since I tried D3D and MS Agent with those little characters who speak !), but could you give me the link to the example you found ?

Sure.

http://msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/_core_atl_samples_index.htm

That link is to the MSDN ATL samples page, and more specifically to what you want:

http://msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/_sample_atl_opengl.htm

P.S.: what problem did you have with an MFC ActiveX control and message handling ???

Actually, its message handling in general. What I’d like to be able to do is reuse a CWnd-derived OpenGL class as the view in place of the COleControl-derived ActiveX class. This is where the mappings go bad. You physically have to map any important UI-based messages down to the view. However, even some of those don’t work (keypresses and such).

I “can” and have written the control as the OpenGL output, however, all of the baggage that ends up within the *Ctrl class is enormous.

I figured I’d give ATL a try, not only to try to solve this mapping problem, but to eliminate some of the baggage. The nice thing about using an ATL ActiveX control over an MFC ActiveX control is that it is much more compact. Better yet, you’re working with the Win32 SDK at that point rather than the MFC constructs, which is a bit more naturally suited to OpenGL. The drawback is that you have to have some limited knowledge of COM, and you have to familliarize yourself with a few of its constructs (such as DRAWINFOSTRUCT or whatever).

Another thing I am not certain of with ATL controls is whether or not the DC you get is very stable. When you add a control to the project, there is an option of “Normalize DC”, which I think does just that. But there is no “global” m_hDC or anything as such. You have to do a GetDC() anytime you need it.

There are a few other issues too, that I have to try out - the example MSDN provides destroys the RC every time and creates a new one when the control is resized. This is obviously bad for using display lists, as the display lists would have to be regenerated every time you resize the window (though, for a fullscreen app, that shouldn’t be a problem - you only resize once).

Other thoughts on this, which you may be able to answer…

Is there a way to have an ActiveX control go fullscreen non-windowed for OpenGL? I’m assuming that this would involve something like creating a new window on the desktop, and setting it to full screen. This applies to ATL as well.

I don’t know all of these answers, and thats what I’m trying to learn. Currently, I don’t know enough about Windows to answer my questions. But that’s why I’m here.

Siwko