CodeJock vs. MFC
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=15785
Printed Date: 04 November 2025 at 6:56am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: CodeJock vs. MFC
Posted By: rdhd
Subject: CodeJock vs. MFC
Date Posted: 05 December 2009 at 2:28pm
|
Has anyone done any in-depth comparison of CodeJock to the enhancements made to MFC vis-a-vis ribbon customization? The CJ customization is very limited and the lack of methods to move ribbon elements around and to persist a ribbon is becoming a roadblock to provding customers with the customization abilities they are demanding. The CJ ribbon customization dialog is not an option as it provides little in the way of ribbon customization other than to drag and drop controls.
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.
|
Replies:
Posted By: znakeeye
Date Posted: 05 December 2009 at 3:35pm
|
The MFC enhancement is a joke. I would quit my job if we would ever use it.
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!
|
Posted By: rdhd
Date Posted: 06 December 2009 at 11:22pm
|
I have Office 2010 and the customization there is quite extensive. Add and remove of tabs, groups, controls; reordering, show/hide, save to and read from files. There is not much one cannot customize when it comes to the ribbon. I can hide their entire ribbon and build any number of my own, which I can load at will.
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!
|
Posted By: znakeeye
Date Posted: 07 December 2009 at 9:25am
|
Haven't tried Office 2010 yet. Sounds cool :)
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!
And...
"CJ and BCG have a lot in common"
I'm convinced BCG stole the code. Oleg is the mighty GUI master
 |
Posted By: markr
Date Posted: 07 December 2009 at 11:13am
|
I completely agree with znakeeye here. The MFC controls are just terrible compared to CodeJock. Not just in performance, but also appearance, in my opinion. CodeJock gets a ton of subtle things right that the MFC/BCG stuff misses entirely. These details are extremely important in the aggregate. And although I agree that the .NET design-time experience is very productive (I've used Infragistics, Telerik, and others) - there are still many downsides to writing desktop applications in .NET (including performance and deployment). It all depends on what you're developing, of course, but .NET Framework still imposes a series of trade-offs that aren't always ideal. |
Posted By: rdhd
Date Posted: 07 December 2009 at 2:14pm
|
We integrate with .NET too although it is mostly for add-ins. For example, I have a .NET add-in that has a window that I dock in one of our CJ docking panes. Garbage collection is a primary concern for us. .NET likes to hold onto our objects, like our document object, which can consume hundreds of millions of bytes until they perform the final release of our COM objects when GC runs. So I detect when .NET is inserted into our process and when we close a doc, I load my own .NET library and (try to) force the GC object to release all CCWs. I came up with the steps to try to force a full GC and then ran them by the Microsoft .NET mem management team and they agreed that it was the best shot at forcing all CCWs to be collected (but no promises for the future). I asked that they simply implement IDispose on CCWs and call them whenever a CCW became collectible but was told that com interop was pretty much finished development-wise so the odds of making changes was slim to none.
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.
|
Posted By: znakeeye
Date Posted: 08 December 2009 at 7:21am
|
MFC vs .NET is an interesting subject, so I started a new thread about this: http://forum.codejock.com/forum_posts.asp?TID=15798&PID=55459 - http://forum.codejock.com/forum_posts.asp?TID=15798&PID=55459 |
Posted By: rdhd
Date Posted: 16 December 2009 at 3:17pm
|
znakeeye,
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?
|
Posted By: znakeeye
Date Posted: 03 December 2010 at 8:51am
|
rdhd, here's a late answer :P
Minimal customization. While menu bars have a fixed presentation, many toolbars are quite customizable, allowing users to set locations, sizes, and contents. A ribbon itself is not customizable, but the Quick Access Toolbar provides limited customization.
http://msdn.microsoft.com/en-us/library/cc872782.aspx - http://msdn.microsoft.com/en-us/library/cc872782.aspx ------------- PokerMemento - http://www.pokermemento.com/ |