rdhd, here's a late answer :P

 

 

 

I searched the MSDN and found way too many hits. I eventually gave up trying to find where MS recommends developers not to allow too much customization. Can you be a bit more specific or include some links to such entries?

 

 

We have a very large application that is based on COM and migration to .NET would be no easy task. And the loss of memory management capabilities would probably prevent us from doing so (our early tests showed .NET is a terrible memory manager). We simply could not rely on GC with the huge memory requirements of our application.

 

I don't know which came first, CJ or BCGSoft. But I looked at some BCG stuff a long long time ago before I had ever heard of CJ. MS did say they examined all the current solutions and went with what they thought was the best MFC integration. I assume that means they looked at CJ. But who knows what the decision was really ba$ed on? Our product planning looked into the options and went with CJ (no technical examination that I am aware of). MS told us about the BCGSoft integration but it was not due out within our time frame.

 

The MFC ribbon (based on BCG code) is not common. Try searching the net for its class names, and you'll soon notice that you are on your own. There are a couple of reasons for this, as I see it:

1) Very few choose MFC for new products.

2) Existing MFC projects do not need ribbon UI.

3) Skilled MFC code = great performance. If a ribbon is needed, CJ is the preferred option.

 

Even though I personally prefer the native power of MFC, I think I will soon emigrate to .NET. It's painful looking for 3d party libraries nowadays, only to find that you need .NET.

 

Have you considered using .NET for your application? .NET and Infragistics is... totally awesome!

 

I'm convinced BCG stole the code. Oleg is the mighty GUI master

 

And regardless of what Microsoft may say, what the customers want is what counts and we are being deluged with customer complaints and even the refusal to upgrade to the new UI because of the limitations (I assume the Office team gave in to the same pressure.) So we will provide what the customer wants. I just about have everything Office 2010 has. Unfortunately I may not be able to use the CJ ribbon/command bar persistence unless I can find a way to limit what gets saved (a "delta" from the out-of-box layout). See my "magical ribbon" post for one of the problems I have yet to solve such as the fact that when I save out changes to a CJ ribbon xml file, CJ also writes out a binary rep in the user's app data that is then reread in whenever I load the QAT. I am not reading in a saved xml file to load the ribbon when that happens. Indeed, I am not even saving the ribbon currently displayed on the frame when CJ writes out the binary in the user's app data directory. I'm pretty sure though that I know how to avoid that problem.

 

As for MFC, it has been quite obvious to me for some time that CJ and BCG have a lot in common. That includes some bugs that I find hard to believe are coincidental. In any case, the MFC wizards sure create some nifty UIs for their applications. Plus MFC and BCG is quite integrated. Whichever gives me the easiest path to supply product planning with their wishes will dictate the direction we go.

 

I'm not wedded to MFC or CJ although I have worked with MFC since Visual Studio first came out. I have only worked with CJ since V11. However I have already had to react to a number of changes in CJ where behavior simply changed and that has been disconcerting. Adding new code or setting the value of newly added flags (after debugging) to get back to the previous behavior is not something I have had to deal with in MFC. However bugs that have shown up in common controls as IE evolved is another matter!

 

Regarding ribbon customization; Microsoft specifically recommend Ribbon developers NOT to allow too much customization. Customization of ribbons violates the whole concept of "consistent UI". Search MSDN and you'll see!

 

We currently build using Visual Studio 2008 but do have 2010 beta. So if we drop CJ, we will be using 2010 for the office-style UI.