Forum

Hi all,

First part of question:

I have tried to compile for the x64 target, but the compile of profuislib in VS2005 pro fails with 77 errors, the first one being:

.\Include\ExtControlBar.h(2109) : error C2555: ’CExtControlBar::OnToolHitTest’: overriding virtual function return type differs and is not covariant from ’CWnd::OnToolHitTest’

Are there any plans to make this 64bit capable?

Second part of question:

I’ve been programming for win32 (of late also win64) for the past 12 years, and to be honest, never found any valid reason as to why use MFC. I always go straight SDK style coding. MFC looks messy and lacks transparency, IMHO. Are there maybe any plans for making profuids accessible from pure SDK style code?

Cheers

- Balt

The x64 platform compatibility is under development right now. So, this feature will be available soon.

You have reason to code something using Win32 API only in case of small applications. For instance, the Miranda (www.miranda-im.org) instant messenger is an application of this type. You have no reason to use Win32 pure coding in any other case. If you take a look at the UI code written in clean C and similar code written with C++ using MFC or ATL/WTL, then you will certainly note that in last case the code is million times easier to understand. That is why MFC is more often used in UI software development than the pure Win32 API.

It doesn’t seem like MS Word, Outlook Express, Acrobat or IE6 are using MFC. In fact, the only MS software I can see using MFC is Visual Studio.

I guess my point is: The marketability of your (really great, don’t get me wrong here!) UI enhancement tools would be multiplied if you offered a bare metal SDK implementation. I’d be more than happy in helping you de-mfc’ise is if you’re interested?

Cheers

- Balt

We agree with you that the software listed in your message is not MFC based :) But this is not a strong argument against MFC. Some people do not like C++ because they does not want to know anything but Visual Basic. Other people have the similar point of view about C#. But as for MFC in comparison with plain Win32 API, we would like to point out that:

- even without MFC, the MFC-like C++ object oriented approach is essential because it allows you to avoid different leaks (memory, handles etc.), streamline the coding, and simply make the development process faster
- MFC is an industry standard, which is easier to use than plain Win32 API, this is the most strong argument in favor of MFC
- coding with MFC is supported with the wizard in Visual Studio 6.0 / 7.0 / 7.1 / 8.0
- MFC is widely distributed and more popular in comparison with plain Win32 API - so, you can find lots of articles, tutorials and source code snippets on the Internet
- using MFC in a big project/application can save memory usage
- using MFC in a small project is also not a problem since there are no big MFC programs for modern computers with 1GB memory
- using MFC in any project provides you with ready-to-use solutions like the document/view architecture, command state updating and others -- this is not available "as is" in Win32 API but is needed in the most of desktop applications

Honestly, we are not very interested in converting Prof-UIS into a plain Win32 API based project because, we have had only two or three requests about this for three years. At the same time, we have many MFC/Prof-UIS related questions every day.