Best book for learning MFC/VC 7.1 for developing rich GUI apps ?

[Alfonso Morra]

Hi,

I am a C/C++ developer of quite a few yesrs, although I am relatively
new to Windows (Unix background). I am about to begin work on a project
that would require me to develop several GUI rich frontend applications.

I would like to hear from developers ou there if there is a book they
would recommend, to help me hit the ground running - i.e. a book that is
NOT an introductory text on programming/C++ but rather one that dives
straight in and shows how to create front ends (possibly widgets etc) -
using the VC IDE, one that covers all I need to know about MFC to start
working on a real world application. A bit of a tall order. But your
recoomendations would be appreciated.

tx

 

[David Lowndes]

I am a C/C++ developer of quite a few yesrs, although I am relatively

new to Windows (Unix background). I am about to begin work on a project
that would require me to develop several GUI rich frontend applications.

I would like to hear from developers ou there if there is a book they
would recommend, to help me hit the ground running - i.e. a book that is
NOT an introductory text on programming/C++ but rather one that dives
straight in and shows how to create front ends (possibly widgets etc) -
using the VC IDE, one that covers all I need to know about MFC to start
working on a real world application.

Alfonso,

Have a look at Jeff Prosise's Programming Windows with MFC book and
Charles Petzold's Programming Windows for the core SDK aspects of
Windows.

Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave

 

[Alfonso Morra]

Alfonso,

Have a look at Jeff Prosise's Programming Windows with MFC book and
Charles Petzold's Programming Windows for the core SDK aspects of
Windows.

Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave

Hi Dave,

Thanks for the feedback. Good question. My reluctance to move to .NEt is
based on the information (which could be inacuurate) I have gathered so far:

1). It is "not secure" as far as IP is concerned - code is easily
reversible from binaries
2). I HATE the fuss of interoperatability between "managed code" and
"unmanaged code" - pretty much all of my logic is in C/C++ libraries -
really, all I need is to know how to create a GUI frontend for my
libraries - I like .NET GUI capabilities but I don't like the fact that
my binaries can be easily converted to source (even with obfuscation).

3). I don't want to learn a new language - (C#)

If I can be convinced that these objections can be overcome without too
trouble than I may consider using .NET

 

[Andre Kaufmann]

[...]
Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave

Hi Dave,

Thanks for the feedback. Good question. My reluctance to move to .NEt is
based on the information (which could be inacuurate) I have gathered so
far:

1). It is "not secure" as far as IP is concerned - code is easily
reversible from binaries

Well, IL code can be easier reengineered as native code, since you have
additional information about classes, variable names etc. .
Native code hasn't, except if you have the debug information too ;-).
For that purpose there are obfuscators, e.g. dotfuscator integrated in
the VS Studio IDE. It will obfuscate all variable and class names in the
code so that it's nearly unusable anymore.

But if you use Managed C++, or better C++/CLI, you will normaly mix
native code with .NET code. Such code compiles (normally) to a mixed
binary. If you compile such code you'll get a mixed binary. Mixed native
and managed code. By the way the C++ compiler is the only one which can
compile mixed binaries.

Since you normally call only into the .NET framework or use simple
wrapper classes i think the recompilation problem is neglectable.

2). I HATE the fuss of interoperatability between "managed code" and
"unmanaged code" - pretty much all of my logic is in C/C++ libraries -
really, all I need is to know how to create a GUI frontend for my
libraries - I like .NET GUI capabilities but I don't like the fact that
my binaries can be easily converted to source (even with obfuscation).

See above. Your native source code will still be compiled to native
code. If you are using the GUI as a simple wrapper only i wouldn't care
about recompilation.

3). I don't want to learn a new language - (C#)

You mustn't. It would be C++/CLI (VC++ 8.0) which i strongly recommend
to use instead of the deprecated Managed C++.
It doesn't use that ugly double underscore keywords, since it's an ECMA
standard and scheduled for ISO standardization.
Although it's easier to interoperate with native code now,
C++/CLI code is still managed code and you have to deal with
interoperability issues. There are currently some restrictions mixing
native and managed classes, with which you will have to deal till the
next C++/CLI version, which are currently solved using (existing)
wrapper classes.

Although I like C++/CLI very much, I tend to use C# as language for my
managed GUI's, calling my native code through P/Invoke or COM Interop.
Just because of the compilation times ;-) and I'm much more productive.
Additionally I'm forced to separate GUI code from native (logic) code.

If I can be convinced that these objections can be overcome without too
trouble than I may consider using .NET

I think creating a WinForms GUI is much easier than with MFC. But if you
have to use native code you will have to deal with interoperability
issues and have to decide if the productivity gain of WinForms is worth
the additional interoperability issues.
For me - mostly it is.

If not, perhaps available native C++ RAD GUI frameworks integrating into
the VS IDE might be another valuable alternative for you, e.g. QT4 ?

Only downside:
You might be forced to change the framework in the future since the
future of Windows application with GUI frontends is definitively
managed. And since MFC and WinForms will allow you mixing native and
managed GUI components, i don't know if the alternative native GUI's
will allow it too in the future.

Hard decision to make.

Andre

 

[Alfonso Morra]

[...]
Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave

Hi Dave,

Thanks for the feedback. Good question. My reluctance to move to .NEt
is based on the information (which could be inacuurate) I have
gathered so far:

1). It is "not secure" as far as IP is concerned - code is easily
reversible from binaries

Well, IL code can be easier reengineered as native code, since you have
additional information about classes, variable names etc. .
Native code hasn't, except if you have the debug information too ;-).
For that purpose there are obfuscators, e.g. dotfuscator integrated in
the VS Studio IDE. It will obfuscate all variable and class names in the
code so that it's nearly unusable anymore.

But if you use Managed C++, or better C++/CLI, you will normaly mix
native code with .NET code. Such code compiles (normally) to a mixed
binary. If you compile such code you'll get a mixed binary. Mixed native
and managed code. By the way the C++ compiler is the only one which can
compile mixed binaries.

Since you normally call only into the .NET framework or use simple
wrapper classes i think the recompilation problem is neglectable.

2). I HATE the fuss of interoperatability between "managed code" and
"unmanaged code" - pretty much all of my logic is in C/C++ libraries -
really, all I need is to know how to create a GUI frontend for my
libraries - I like .NET GUI capabilities but I don't like the fact
that my binaries can be easily converted to source (even with
obfuscation).

See above. Your native source code will still be compiled to native
code. If you are using the GUI as a simple wrapper only i wouldn't care
about recompilation.

3). I don't want to learn a new language - (C#)

You mustn't. It would be C++/CLI (VC++ 8.0) which i strongly recommend
to use instead of the deprecated Managed C++.
It doesn't use that ugly double underscore keywords, since it's an ECMA
standard and scheduled for ISO standardization.
Although it's easier to interoperate with native code now,
C++/CLI code is still managed code and you have to deal with
interoperability issues. There are currently some restrictions mixing
native and managed classes, with which you will have to deal till the
next C++/CLI version, which are currently solved using (existing)
wrapper classes.

Although I like C++/CLI very much, I tend to use C# as language for my
managed GUI's, calling my native code through P/Invoke or COM Interop.
Just because of the compilation times ;-) and I'm much more productive.
Additionally I'm forced to separate GUI code from native (logic) code.

If I can be convinced that these objections can be overcome without too
trouble than I may consider using .NET

I think creating a WinForms GUI is much easier than with MFC. But if you
have to use native code you will have to deal with interoperability
issues and have to decide if the productivity gain of WinForms is worth
the additional interoperability issues.
For me - mostly it is.

If not, perhaps available native C++ RAD GUI frameworks integrating into
the VS IDE might be another valuable alternative for you, e.g. QT4 ?

Only downside:
You might be forced to change the framework in the future since the
future of Windows application with GUI frontends is definitively
managed. And since MFC and WinForms will allow you mixing native and
managed GUI components, i don't know if the alternative native GUI's
will allow it too in the future.

Hard decision to make.

Andre

Thanks for your input Andre. There are many pros and cons on both sides.
However, when all is said and done, the balance (for me) lies with
C++/"old school" MFC. After a little further research, trhis book looks
interesting : "Visual C++ Mfc Programming by Example", I'll borrow it
first, and if its useful, I'll buy it.

Many tks

 

[Eddie Pazz]

You'll definitely want to buy "The MFC Answer Book" by Kain. It's one of the
most helpful books I've seen once you've learned the MFC basics.

David Lowndes wrote:

[...]
Since you're just starting, many people will ask why you're not
considering starting from the .Net framework - which is where most of
Microsoft's efforts are today. So, have you considered that?

Dave