I have a quick question that hopefully someone intimately familiar with the workings of MFC can answer for me.
I'm writing a content creation tool for my engine. The editor for the Windows version is using MFC and splitter windows to replicate the same kind of interface that rendering software usually provides. Problem is, because it's graphics-API-agnostic and the engine is platform independent (assuming one is using a rendering driver written for that platform), it means each renderer has a set of CView classes (Top, Front, Side, Perspective, kinda thing) for each platform supported by the graphics driver (presently D3D9, and OGL). This itself isn't so much of an issue as it is creating an problem I'm not sure how to get around. The crux of issue is, when you use splitter windows, you make a call to CreateView (for dynamic splitters) through the splitter window object. One of the parameters is usually some form of:
(..,RUNTIME_CLASS(<statically/hardset-class-name here with no quotes>),...);
m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(cSomeClassName), CSize(cr.Width() / 2, cr.Height()), pContext);
It would be a damn shame to have to utilize some brute-force method of if/else or switch/case statements to determine which view class to specify in compile time -- after so much effort has been made to ensure things are as "runtime-flexible" as possible.
Now RUNTIME_CLASS boils down to a macro that basically calls GetRuntimeClass. Ideally, what I would like is to just be able to pass in either a char * or (better yet) an std::string.
m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS("cSomeClassName"), CSize(cr.Width() / 2, cr.Height()), pContext);
But now we're blurring over the lines of compile-time vs runtime. I've seen some stuff that gets closer to what I'm after, by making the passed-in-parameter <instantiated_object_name>->GetRuntimeClass(), but then it implies that the object is created before the call to CreateView???
m_wndSplitter.CreateView(0, 0, Some_InstantiatedObject->GetRuntimeClass(), CSize(cr.Width() / 2, cr.Height()), pContext);
Anyone have any experience in dealing with this kind thing? What did you do to get around it? I would bet big money other engine vendors are not using gargantuan if/else or switch/case statements for every possibility -- For one, that would hardly be elegant and two, the maintainability would be hellish. Are they just not using MFC? (period, end of discussion, full-stop?) But then IF that is the case, what ARE they using? I can't picture them writing their own splitter classes that hook into the APIs of the GDI subsystem of Windows, that alone would be pretty miserable. WxWindows? Embacadero's VCL? QT? (I've heard licensing costs on QT is pretty bad). There's gotta be a way of not using a hardset/compile-time classname to pass through CreateView. Thanks in advance!
Edited by StakFallT, 07 December 2013 - 09:27 PM.