Re: MFC Migration/Integration

Joe,

Thanks for the reply and offer of a simple, six-click solution. I
apologize for pooping on mom's living room carpet -- somebody suggested
I cross post my somewhat frustrated question on MFC
Integration/Migration here in the MFC homeland. Don't take the
hopefully constructive criticism below too seriously, I'm not really
trying to pile it higher and deeper (PHD) with malicious intent. Okay
maybe it's not constructive, but it is intended to humorously expose
some areas in MFC and its documentation that might be improved.

To answer your question, I do appreciate that MFC is much easier to use
than raw Win32 programming, but I still maintain the documentation (and
teaching) of MFC could be improved.

One problem right out of the box is that you seem to have the good
version of VS 2003 and its default help and I have the bad version. I
say this because your version has a "frame control" on the toolbox.
Here's my toolbox component list: Check Box, Edit Control, Combo Box,
List Box, Group Box, Radio Button, Static Text, Picture Control,
Horizontal Scroll Bar, Vertical Scroll Bar, Slider Control, Spin
Control, Progress Control, Hot Key, List Control, Tree Control, Tab
Control, ... + 5 more. Now as a beginner, I would guess that the
simplest of these to use to draw a colored frame/background would be
the flat, simple looking Group Box, but when retrieving its rectangle
and drawing it there seems to be a reserved area on top that doesn't
correspond to the dialog editor drawn border. I'm guessing that this
is because it is derived from CButton and is more complex than needed.
So...let's try the Picture Control. It does expose an irrelvant color
property, despite my assumption that it is not VB. Even though the
Win32 API is indifferent to my choice of colors, I can draw a colored
frame and perhaps even a background with a little more digging.
Searching for help on Picture Control, a basic member of my toolbox,
gives as the number one ranked topic "MFC ActiveX Controls: Using
Pictures...." So, to use this basic toolbox item, I appear to have to
build an activeX control. Maybe somewhere they'll explain the
properties of the Picture Control, but maybe not. Help topics below
this careen off into VB and C# (despite the Visual C++ filter setting),
obviously not helpful.

Suppose I decide that the Picture Control properties are self evident
and don't need any explanation. So, I'll attempt to use the Picture
Control to display a picture (I am a brilliant thinker). Easy, just
set Accept File to TRUE. Done ... opps where is the file setting that
it is accepting. Well, the Picture Control is not for whimps,
somewhere you can find how to specify in code what to load, but good
luck in your quest. Okay, let's try to load a more friendly ActiveX
picture control. Here's an ActiveX picture control that looks
promising: Microsoft Forms 2.0 Image. Yes it works -- just specify
the Picture property to load the picture. This is probably from the
eye-candy side of the Microsoft family, but they are a bit cross-eyed.
If I am not hallucinating, this control has two interesting properties
side by side: "disabled" and "enabled". Praise to Zeus that they are
set consistently, but what would happen if they were both set to true??
I do know, through the thoughfully provided documentation, that if
they were both set false, world-wide, all VB programmers would feel a
painfull pin-prick in their interpreter.

Enough documentation bashing, I could provide many more even though
I've only been working on this about a day. While I am impressed with
the power of the squiggle tutorial and the automatic generation of
complete document-centric applications, I need to move on to inductive
user interfaces where one click on heart and flower shaped buttons
that are grouped in pastel colored backgrounds give immediate results
-- six clicks is too many -- I'm simply lazy, arrogant and impatient.

As to not needing to worry about those greyed out macros, I'm not so
sure. Supposing that I wrote perfect code, never needing to start the
debugger, and ignoring all the other sins of macros, I would be a happy
camper --- letting the MFC wizards take full responsibility for that
area. However, the MFC wizards don't clean up after themselves and
leave ungreyed #define ID = xxx in header files and other related
wizardly code hanging around in many unexpected places. Maybe not so
bad, but even the compiler hates the MFC wizard and refuses allow the
program to run without cleaning the mess up. The MFC class wizard also
seems prone to infinite loops and likes to assign identical IDs to
different items. True, sometimes it objects to identical IDs, but not
always. Is this identical item ID business an MFC technique or not?

I believe these problems are related to MFC being one step above the
Win32 API (long live VMS!!) and written in an era when C was in it's
infancy (and macros were as powerful as the language itself). At some
point, there will be a high level MFC library with access to
object-oriented techniques (MFC Version 8 with Windows Forms??). Until
then, I admire the perserverence it takes to learn and teach MFC.
Thanks for all the help (since there is not very much in the MFC
documentation)!

Regards,

Dave


Joseph M. Newcomer wrote:
> Define how MFC seems "difficult to use" and "poorly documented". It is much easier to use
> than raw Win32 programming, and its documentation is extensive.
>
> CStatic is most definitely on the toolbox: for example, as a frame control, which is a
> well-known static control. Using MFC requires a certain literacy in how Windows works,
> which is not gained by using VB, which hides most of the reality by providing a lot of
> "eye candy". The frame color is irrelevant. This is not an issue of MFC: MFC is a direct
> reflection of the underlying Win32 API here, and therefore it provides no more capability
> than Windows itself does. You are perhaps mistaking Windows for the very fancy set of
> facilities that VB puts on top of Win32. Those abilities in VB are fictions, not directly
> supported in the Win32 API, so there is no reason to expect they are supported in MFC.
> CStatic never had an ability to set a background color. VB provides a very fancy control
> with VB properties, and you have obviously confused this high-level interface with the
> facilities Windows supplies. So the concept of "background color propertty" cannot be
> "exposed" because the concept does not exist. Don't confuse Visual Basic with Windows
> Programming at the API level.
>
> Apparently, you expect to learn MFC in a less than a day. I just spent a week teaching
> MFC. You really have to spend more than a day on the subject.
>
> If you want a background color, subclass CStatic and write an OnPaint handler that does a
> FillSolidRect. This takes, let me see,
>
> 1 Subclass CStatic
> 2 Add a COLORREF member that represents the color
> protected:
> COLORREF color;
> 3 Add a method which "exposes" the "background color property"
> public:
> void SetBackgroundColor(COLORREF c) { color = c; Invalidate(); }
> 4 Add an OnPaint method, and fill in its contents:
> CRect r;
> GetClientRect(&r);
> dc.FillSolidRect(&r, color);
>
> You're right, this is incredibly complex: about six mouse clicks, typing the name of your
> new class, adding one variable, one line of method call, and three lines in the OnPaint
> hander. Hmmm. Yep. Unbelievably hard. Must be my PhD that makes it look so simple.
>
> The point about the greyed out macros is that you don't HAVE to worry about what they do.
> In fact, you can be a highly effective MFC developer and notice them once every few
> months. Apparently color schemes for syntax highlighting offend you.
>
> I learned MFC a decade ago. It took me three days of doing the Scribble tutorial, and two
> weeks later I delivered a prototype app, which we then enhanced to production quality.
> You'll probably have a lot more luck if you spend a few days studying how to build apps
> instead of feeling resentful that MFC doesn't look like VB.
> joe
>
>
>
> On Fri, 28 Oct 2005 12:01:07 -0700, "daveboyd" <daveboyd@xxxxxxxxxxxxxx> wrote:
>
> >Hi!
> >
> >I have an MFC application that is under development in VS2003 and frankly
> >MFC seems difficult to use and poorly documented -- I frequently find the
> >only way to get example code is on the Internet, not in the huge, mosly
> >useless "MSDN Library". For example, I was advised to use CStatic for
> >drawing some color frames / backgrounds, but CStatic isn't on the Toolbox and
> >for those related components such as Picture, limited frame colors and no
> >background color property is exposed -- drawing a colored background takes a
> >PhD in MFC (greyed out macros everywhere -- yuck!!).
> >
> >How can I gracefully migrate the unmanaged C++ MFC GUI and business logic to
> >integrate with C++/CLI (and C#) and Windows forms. Unfortunately, I'm stuck
> >with production quality requirements that eliminate VS 2005 for this
> >development cycle. Should I wrap the old C++ code and use a C# application
> >or vise-versa? Should I re-write the MFC GUI, which consists mostly of
> >customized user drawn buttons, or should I wait for MFC with Windows Forms
> >classes -- any suggestions to alleviate my VS2003/.NET 1.1 restriction would
> >be appreciated.
> >
> >Thanks for any advice!
> Joseph M. Newcomer [MVP]
> email: newcomer@xxxxxxxxxxxx
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

.