Without trying to start a war here , let’s explain what are the main differences between MFC and Juce.
In MFC (except it is only for Win32) :
-=- Each window is an object.
-=- The framework hides (but not too much) the underlying platform. To achieve this, there is a lot of Win32 structure wrappers (which are not useful at all most of time).
-=- MFC intercept each call to the main Win32 procedure to map each Window object with the window handle (HWND). This is done dynamically, the mapping is stored in the TLS (thread local storage).
-=- This also means that there is a lot of things you can not do (like intercepting window creation (WM_NCCREATE), destruction (WM_NCDESTROY), interacting with the thread local storage) without ugly hacks.
-=- So, to allow you to do such things (as it is required for most applications), MFC developers created a lot of hierarchical callbacks (OnCreate, PreCreate, OnInitialUpdate and so on).
Looking from the outside, the constructors are not very useful because the creation, destruction etc, are done mainly in auxiliary methods you must implement (that’s why the ClassWizard does it for you not to forget).
MFC is old and not very well designed, bug-prone due to hidden features in ugly macros. On the opposite, MFC have a huge amount of classes so you should find the right class to do whatever you think of.
Okay, I won’t say that using MFC is like trying to kill a mosquito with a 50mm gun, but I’m thinking it.
In Juce, (cross platform) :
-=- Juce borrows many concept from Java. You should learn Java because it provides some “up-to-date” concepts and designs.
-=- Juce hides the platform specific code so that there is no more need to use wrappers like in MFC.
-=- Juce follows strict C++ standard.
-=- In C++ standard, you should construct an object in the constructor, and destruct it in the destructor. If you have a large amount of objects to constructs in your constructor it is mainly because you haven’t designed your classes well. Group by functionnality in specialized structure or class, simplify your code. It is not Juce’s fault if you code is ugly and large.
-=- If you have errors while constructing, throw an exception like specified in the standard, but don’t rely on “OnPreCreateBeforeRealCreationBeforeConstructorBeforeMalloc” hack included in MFC to handle your errors. This leads to cleaner code when debugging as you don’t have to dig into the MFC hierarchy.
-=- The Windows messages doesn’t exists anywhere else than in Windows. So why recreating a similar concept ?
-=- Any event is dispatched to the right component if it decided to receive it. It should then implement the correct interface (called a Listener, like in Java), and register with the sender component. Unlike MFC, messages are not always send & received, and you don’t have to implement any thing if you don’t need to.
-=- The component looks cool (as it is no more a Win32 default component).
-=- It is very simple to use.
I’ve tried many “platform specific” code (I’m still using MFC, but less often, ATL and WTL for Win32 only development), and many cross platform code.
If you don’t want to change your programming habits, switch to wxWidgets as it is closer to MFC.
If you want a true C++ cross platform GUI code, either choose Qt or Juce. Juce is more fun to use, but Qt is very well supported. They both implement many C++ concept MFC programmer don’t even know of (for example not using macros, but templates).
Don’t start flaming saying that Juce is complex and fatty. If you preprocess a MFC code (I mean expanding the macros), then you’ll see that MFC is largely fatter. Juce doesn’t include any construction in ugly (and not obvious) macros, so the code might looks bigger but it is clearly not the case. (Could you even tell me what the DECLARE_DYNCREATE or DDX_EXCHANGE macro do exactly ?).
With Juce, you know what the code does because it is not hidden.
The demonstration code doesn’t embed many struct because it has to fit in a single file. But you should (must) embed your data in a specialized object, add serialization / construction / destruction / assignement, and then (and only then) the construction code will be simplier. This doesn’t mean it is not there. This simply means it is correctly defined.
I hope you’ll try to understand the concepts above, and re-read the code, you’ll see it is very easy to start with. I’ve posted a ClassWizard like for dialog in the “Useful Tools” section today. Feel free to create the same dialog in Juce and MFC, and compare the code size you’ll see.