Archived

This topic is now archived and is closed to further replies.

JulianSpillane

Win32 API and OGL. Help!

Recommended Posts

Hey all, first I''d like to wish everyone who celebrates it, a Happy Christmas. *laughs* Now, to berate you with my problem. I''m working on a Level Editor in MFC to handle my world files and I''m interfacing it with OpenGL. So, I''ve got everything working individually, but I was wondering if there is any way to interface different MFC classes with others. For example, I have a Frame-inherited class that has both a toolbar and a status bar. The toolbar has such common items as "New", "Open", etc., and then more specific ones such as "Constrain to X axis", and so forth. Now, I''ve got it so that when one depresses the button, it alters a boolian value representing whether or not to constrain to the X-axis. I also have a View-Inherited class that handles the OpenGL display. It all works fine, except for the fact that I can''t interface the variables in the Frame-inherited class with those in the View-Inherited class. I''ve tried putting the toolbar in the same class as the OpenGL display, but I get driver conflicts and such. I was wondering if anyone could shed some light on the subject for me? Thanks in advance!

Share this post


Link to post
Share on other sites
Funny you should mention it, because I''m also working on a MFC/OGL terrain editor

I have seperate windows as well, one CDialog-derived (which is also the main program in the Dialog-based application) and one CFrame-derived class for the OGL rendering. The way mine is set up, all the options that have to do with rendering are in a menu connected with the OGL window. This allows the actual render window to keep track of the variables that other parts of the application, quite frankly, don''t need to know about When I set up the message handles for the menu options, they go straight into the message handler for the OGL window. In other words, the other windows don''t even know about it.

Now you''re talking about sending information between the windows. Well, in my applicaiton, the dialog actually creates the CFrame-derived window manually with a call to Create. Since the dialog then has a pointer to the window, it can update the view by calling something like a SyncData(...) function that updates the data. And by the same token, if the dialog wishes to pass a pointer of itself to the render window via a special function, it may, and this will allow the render window to call functions from the dialog box class. However, mine isn''t designed this way, because the data flow is supposed to into the view only. If you had something like 3D selection that requires the view to send data to the dialog (which I have coined "database", just because that''s what it is ), then you can pass the pointer as mentioned.

In your case, the CFrame-inhereited class is analagous to my dialog box, and your CView is analagous to my CFrame-inherited class. My setup is a bit different from yours, as I have seperate windows created manually by the dialog, while you have a frame window with child views, but I believe passing the data should be similar. Just get a pointer to the children.

If you have any more questions, just ask.

Share this post


Link to post
Share on other sites
Thanks for your help! :D Actually, I decided to convert to a Frame-Dialog interaction because it makes more sense, and your advice helped a lot!

I''ve got one more question. *laughs*

How to properly integrate OGL into a Frame-derived class properly, without flickering.

^^ I''ll pay homage to you if you can help. *laughs*

Share this post


Link to post
Share on other sites
Actually, I''ve got it interfaced rather nicely now, except for one thing:

The OGL window overlaps the toolbar that I have. It''s only temporary, but I was thinking it may overlap the menu aswell. Is there any way to handle both in a stable way?

Thanks!

Share this post


Link to post
Share on other sites
Yeah, the big problem with CFrameWnd windows is that they want to overlap everything. I got my menu to show up fine, but it ate up my status bar, and doesn''t allow any other windows to get in front of it (other windows in the same application, that is). I''m still working on it. I was thinking of replacing WS_OVERLAPPEDWINDOW with WS_CAPTION, WS_SYSMENU, WS_THICKFRAME, WS_MINIMIZEBOX, and WS_MAXIMIZEBOX, which is everything but the WS_OVERLAPPED.

Share this post


Link to post
Share on other sites