GLUT and MFCIs there anybody with experience of wrapping (or converting) GLUT application to MFC-based one?

The problem with GLUT coexisting with MFC is that both GLUT and MFC take over the main event loop completely that leaves no control of it to the programmer. In that sense, they both compete for the event loop... Anybody had any experience in this?[Flying (11-4 23:54, Long long ago)] [ 传统版 | sForum ][登录后回复]1楼

hi, what i am doing now is exactly what u saidit is working well currently on both GLUT and MFC.

What I suggest is that you let MFC handle the main loop. I guess you let the GLUT do the loop to do some animation that will refresh the scr. If that is the case, you can search for CView->OnTimer, SetTimer, KillTimer.

Hope the above can do some help[maserati (11-5 11:06, Long long ago)] [ 传统版 | sForum ][登录后回复]2楼

(引用 maserati:hi, what i am doing now is exactly what u saidit is working well currently on both GLUT and MFC. What I suggest is that you let...)Thanks. But maybe you didn't quite get my idea.From your description, it seems that you are not using GLUT the way my existing code base uses it.

I suppose you are only using some wrapper functions in GLUT that provides easier graphical control and display, and use MFC in the large part for your main application.

However, the situation I'm facing now is that:
1) We already have a fairly large code base, whose base API wrapper in on GLUT. This means that all our event handling, input handling (not for all devices, only for keyboard and mouse), etc. are tighted down to GLUT.
2) As we are going one step further for a different application, we need to use the code base, but also need the power of 2D GUI by MFC.

In fact, we have through of two ways, but both of them seem quite problematic, and therefore I'm posting the question here.
Option 1:
Continue the development using our 3D GUI toolkit. But the toolkit we have in the code base provides only a restricted set of widgets that may not fulfil all our GUI requirements in the new applications.
Option 2:
Abstract away the API wrapper, and provide another implementation for the set of interfaces that are based on something other than GLUT, say DirectInput. But this will incur a fairly bit of start-up cost as we'll have to re-work on the API wrapper that everything else is based on, and is quite large and complicated in terms of source code maintenance.

Thanks a lot for your comments. Do you have any further thoughts on this?[Flying (11-5 11:21, Long long ago)] [ 传统版 | sForum ][登录后回复]3楼