SFML window in MFC

[Somnia]

Hi,

I want to use MFC as an editor for my game. Has anyone had any success in integrating an SFML window into MFC? I've seen that it's possible to do use OpenGL in a class that inherits from CView as in this project:

http://www.codeproject.com/KB/openGL/glenabledview.aspx

I'm a bit clueless about windowing and such so I'm not sure where to begin in doing the equivalent for SFML.

[Laurent]

Passing the handle of your MFC view to a SFML RenderWindow (or Window) should be enough.

Code: [Select]

sf::RenderWindow sfmlView(mfcView.GetSafeHwnd());

By the way, if you can choose, don't choose MFC. This is the worst library you can use for GUI stuff.

[Somnia]

Hi,

Cheers for the quick reply, seems to be working fine.

As for MFC, I know it's not the best but I have three years professional experience with it so i think I can be quite productive with it in spite of it's foibles. The only other GUI I'd be motivated to learn is .NET, but I'm worried about how to integrate that with my C++ engine. I know it can be done by wrapping things in a managed DLL, but I feel a bit tentative about doing that. (I don't know if anyone has manged to get SFML rendering in a C# .NET app in this way.)

[Laurent]

I don't know if anyone has manged to get SFML rendering in a C# .NET app in this way

Yes, it works too.

[T.T.H.]

Code: [Select]

sf::RenderWindow MyRenderWindow(GetSafeHwnd());
Drop dead simple. The last week I replaced the old *cough* DirectX5 based *cough* render engine with SFML within "my" application at work, a 180.000+ lines of code monster with multiple views and dockable toolbars all based on MFC, and I am surprised how simple that task was.

[Tank]

180.000+ lines MFC code and it still runs? SCNR

[T.T.H.]

5 years and counting. And somewhen I'll even move it from VS2003 to VS2010  :mrgreen:

[Tank]

You must be a masochist.

[TheMiss]

Passing the handle of your MFC view to a SFML RenderWindow (or Window) should be enough.

Code: [Select]

sf::RenderWindow sfmlView(mfcView.GetSafeHwnd());

By the way, if you can choose, don't choose MFC. This is the worst library you can use for GUI stuff.

Why do you think MFC is the worst gui lib?

And what is the (best) alternative?

I just want to know your opinion  

because I don't know too much about it.  :oops:

[Laurent]

MFC is old, complicated, and has an ugly public API which is just a thin wrapper around Win32 calls -- I find Win32 calls cleaner than MFC. And not portable of course (Windows, Visual C++ only).
It's an old thing that should have died a long time ago, but unfortunately it is still used in many products (many companies cannot afford switching to another GUI library).

The best alternative depends on what you need. If you like having a complete framework that provides almost anything that you'll need to build your application, Qt might be the best choice. wxWidgets is not bad too, but still not as good as Qt (which is owned by Nokia and developed by hundreds of trolls). If you prefer something more lightweight, there is FLTK; I never tested it.

[TheMiss]

OK, I see.

Thanks for your suggestion.  

[Nexus]

In the wide world of C++, there are also less known GUI frameworks like gtkmm, Ultimate++ or VCF. The latter is one of the few libraries that uses native widgets. A further alternative is AlgierLib, which is currently ready for Windows, but the developper plans to port it. Maybe you can have a look at those libraries, so that your choice is at least not too easy.

By the way: I don't know wxWidgets well, but from what I've heard and seen, this library uses ancient C++ from times before the standard in 1998 (no modern features, but lots of macros). Just read their style guide. :shock:

Don't use C++ templates
Don't use C++ exceptions
Don't use RTTI
Don't use namespaces
Don't use STL
Don't declare variables inside for()
Don't use nested classes

[Somnia]

Yuk. Although MFC might not be much better when it comes to using modern C++. Quite a few classes use LPCSTR type things for example, although it does at lease use exceptions. This might not be rational but I'm comforted a bit by the fact that MFC has been used to make loads of commercial apps, even if the devs hated every minute of it.

But anyway my choice is made now. But I seem to have run into a problem. If I have a dialog with an SFML wnd inside it and then try and to create another modal dialog from within this one then the program hangs. If I hide the SFML window before calling DoModal then it works fine. Can anyone think why that would be?

It's not so critical obviously I can just make the dialogs modeless, or hide the window as I said, but it'd be nice to solve anyway.

[Laurent]

By the way: I don't know wxWidgets well, but from what I've heard and seen, this library uses ancient C++ from times before the standard in 1998 (no modern features, but lots of macros)

So as many libraries that were created a long time ago. Qt has the same list of limitations : almost no templates, no exceptions, they have their own RTTI system, their own string/container/stream/... classes, etc.

[Nexus]

So as many libraries that were created a long time ago. Qt has the same list of limitations : almost no templates, no exceptions, they have their own RTTI system, their own string/container/stream/... classes, etc.

You are right. The pre-preprocessor is another point. However, there are still some more modern alternatives (see my post). But these libraries probably have other disadvantages...

Anyway, I think the most important thing is to widely separate GUI and application logic, so that a potential replacement of the user interface wouldn't break the whole code.