Neophyte Question(s)

[James]

Complete neophyte to VC++. I do have a base knowledge of how API calls work
and the general structure of these applications, but I'm getting bogged down
with details. Just a few, relatively simple questions.

Using VS2005, if I'm looking to build a "standard" windows app, it appears
my best option is MFC? Gets me drag and drop functionality, etc. In the
event that I had finalized an application using MFC, do I need to distribute
anything other than the EXE file, or is it still unmanaged and framework
free?

Very simple "event handler" type question. I've created an MFC application
which has a dialog. Just called it WinMFC. I want to do something as
simple as changing the background color of the default dialog. There
doesn't seem to be a property, so I assume I have to handle an event like
WM_ERASEBKGND...but where exactly do I handle this? Is this even the right
approach?

Sorry for the ridiculously simple questions, just trying to learn something
new.

Thanks,
James

[Ben Voigt]

"Bruno van Dooren [MVP VC++]" <br**********************@hotmail.comwrote
in message news:9B**********************************@microsof t.com...

>Complete neophyte to VC++. I do have a base knowledge of how API calls
work
and the general structure of these applications, but I'm getting bogged
down
with details. Just a few, relatively simple questions.

Using VS2005, if I'm looking to build a "standard" windows app, it
appears
my best option is MFC? Gets me drag and drop functionality, etc. In the
event that I had finalized an application using MFC, do I need to
distribute
anything other than the EXE file, or is it still unmanaged and framework
free?

It would be free of the .NET framework, but you'd still need the MFC
framework DLLs.

I believe that ATL on the other hand, since it is based on templates which
work at compile time, leaves you with no additional dependencies.

>>
Very simple "event handler" type question. I've created an MFC
application
which has a dialog. Just called it WinMFC. I want to do something as
simple as changing the background color of the default dialog. There
doesn't seem to be a property, so I assume I have to handle an event like
WM_ERASEBKGND...but where exactly do I handle this? Is this even the
right
approach?

Sorry for the ridiculously simple questions, just trying to learn
something
new.

There is nothing wrong with learning something new. :-)

What type of app would you want to build?
Personally, for most types of windows based application, I would use a
Windows Forms application, and program it in C#, not in C++.

Not if you're worried about dependency footprint, which the OP seems to be.

>
I have onyl used MFC for simple dialog based applications. I have never
mastered MFC because I don't really like it.

I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

>
For a large portion of windows app, the WinForms frameword suffices. In
that
case, a lot of the heavy lifting is done for you by .NET.
If you really want to use MFC, you can always visit the MFC newsgroups,
which is -obviously- visited by MFC experts.

For an MFC, you need to distribute only the runtime DLLs, and yes, MFC is
still compiled to native code unless you specify the /clr compiler switch

--
Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

[James]

Ok. So eliminate MFC from my vocabulary, don't have a problem with that. I
guess what I'm really trying to determine is what the true benefit of using
VC++ over C# is. Smaller footprint and CLR independence, but what's a
practical type of application that VC++ would be a better alternative than
C#?

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:Ot**************@TK2MSFTNGP05.phx.gbl...

>
"Bruno van Dooren [MVP VC++]" <br**********************@hotmail.comwrote
in message news:9B**********************************@microsof t.com...

>>Complete neophyte to VC++. I do have a base knowledge of how API calls
work
and the general structure of these applications, but I'm getting bogged
down
with details. Just a few, relatively simple questions.

Using VS2005, if I'm looking to build a "standard" windows app, it
appears
my best option is MFC? Gets me drag and drop functionality, etc. In
the
event that I had finalized an application using MFC, do I need to
distribute
anything other than the EXE file, or is it still unmanaged and framework
free?

It would be free of the .NET framework, but you'd still need the MFC
framework DLLs.

I believe that ATL on the other hand, since it is based on templates which
work at compile time, leaves you with no additional dependencies.

>>>
Very simple "event handler" type question. I've created an MFC
application
which has a dialog. Just called it WinMFC. I want to do something as
simple as changing the background color of the default dialog. There
doesn't seem to be a property, so I assume I have to handle an event
like
WM_ERASEBKGND...but where exactly do I handle this? Is this even the
right
approach?

Sorry for the ridiculously simple questions, just trying to learn
something
new.

There is nothing wrong with learning something new. :-)

What type of app would you want to build?
Personally, for most types of windows based application, I would use a
Windows Forms application, and program it in C#, not in C++.

Not if you're worried about dependency footprint, which the OP seems to
be.

>>
I have onyl used MFC for simple dialog based applications. I have never
mastered MFC because I don't really like it.

I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

>>
For a large portion of windows app, the WinForms frameword suffices. In
that
case, a lot of the heavy lifting is done for you by .NET.
If you really want to use MFC, you can always visit the MFC newsgroups,
which is -obviously- visited by MFC experts.

For an MFC, you need to distribute only the runtime DLLs, and yes, MFC is
still compiled to native code unless you specify the /clr compiler switch

--
Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

[Bruno van Dooren [MVP VC++]]

Ok. So eliminate MFC from my vocabulary, don't have a problem with that.

I guess what I'm really trying to determine is what the true benefit of
using VC++ over C# is. Smaller footprint and CLR independence, but what's
a practical type of application that VC++ would be a better alternative
than C#?

You would use C++ if
- you need absolute control over runtime behavior (e.g. real-time systems)
- you have to maintain an existing x million line codebase
- you need a very small memory footprint.
- you need to limit external dependencies.
- you need raw performance in specific algorithms
- you need to write device drivers or windows explorer plug-ins.
- you need cross-platform compilation.

I have used C++ for device drivers, interop dlls and realtime apps.

C++ is powerful and flexible, but this comes at the cost of
- being more difficult to learn
- making it very easy to screw up
- needing more time for development, debugging and testing

C# otoh is easy to learn, easy to use and is like a child-safe version of
C++.
personally, I prefer to use C# for GUI style apps, and apps that do not have
a requirement that would make me use C++.
simply because with C#, it is a lot easier to get the job done without
worrying about all the things that C++ makes you think about.
time == money

Don't get me wrong. I love C++, but these days, using C++ for simple apps is
like using assembler to write apps. you can do it, but what's the point?

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[David Wilkinson]

Ben Voigt wrote:

I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

Ben:

What is the basis for this statement? There has no reduction of MFC
support in recent Visual Studio offerings (other than the much less
convenient IDE than in VC6).

And I hear rumors of increased support for native code (including MFC)
in future versions of VC++.

Personally, I am not sure that the entire MC++ and C++/CLI (not to
mention VB.NET) was not misguided. .NET is nice, and C# is a great
language, but the duplication in the three languages (VC, C#, VB) was a
huge effort with somewhat marginal rewards, IMHO.

David Wilkinson

[Bruno van Dooren [MVP VC++]]

Personally, I am not sure that the entire MC++ and C++/CLI (not to mention

VB.NET) was not misguided. .NET is nice, and C# is a great language, but
the duplication in the three languages (VC, C#, VB) was a huge effort with
somewhat marginal rewards, IMHO.

I agree that C++ should not emulate C#. I have no desire to see things like
LINQ in VC++, simply because there is only so much engineering time
available, and it would better be used on native and interop features.
But in order to have the perfect interop tool you really need C++/CLI to
give you access to the .NET framework.
MC++ was indeed one ugly language perversion, but C++/CLI is quite elegant
imo.

it requires a lot of engineering effort, but it is indispensible.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[James]

Thank you, makes sense. Realizing that I'm a C++ neophyte, and assuming I
have the mental capacity to undertake such an endeavor, where would you
recommend I start if I were interested in understanding how to create device
drivers? I realize it's a very large uphill fight, but I have a lot of time
on my hands and I'd like to add it to my list of things I know.

So assume I'm completely competent developing Windows based CLR apps in
C#/VB.NET and I want to start from absolute "Square 1" in VC++ (i.e. I know
what int x; does!), where would you recommend I start? Writing basic
console applications to start? Any good web references for people that have
a general knowledge of programming paradigms but very very little C++
knowledge?

Thanks for your help thus far!

"Bruno van Dooren [MVP VC++]" <br**********************@hotmail.comwrote
in message news:O6*************@TK2MSFTNGP06.phx.gbl...

>Ok. So eliminate MFC from my vocabulary, don't have a problem with that.
I guess what I'm really trying to determine is what the true benefit of
using VC++ over C# is. Smaller footprint and CLR independence, but
what's a practical type of application that VC++ would be a better
alternative than C#?

You would use C++ if
- you need absolute control over runtime behavior (e.g. real-time systems)
- you have to maintain an existing x million line codebase
- you need a very small memory footprint.
- you need to limit external dependencies.
- you need raw performance in specific algorithms
- you need to write device drivers or windows explorer plug-ins.
- you need cross-platform compilation.

I have used C++ for device drivers, interop dlls and realtime apps.

C++ is powerful and flexible, but this comes at the cost of
- being more difficult to learn
- making it very easy to screw up
- needing more time for development, debugging and testing

C# otoh is easy to learn, easy to use and is like a child-safe version of
C++.
personally, I prefer to use C# for GUI style apps, and apps that do not
have a requirement that would make me use C++.
simply because with C#, it is a lot easier to get the job done without
worrying about all the things that C++ makes you think about.
time == money

Don't get me wrong. I love C++, but these days, using C++ for simple apps
is like using assembler to write apps. you can do it, but what's the
point?

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Ben Voigt]

"David Wilkinson" <no******@effisols.comwrote in message
news:O7**************@TK2MSFTNGP03.phx.gbl...

Ben Voigt wrote:

>I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

Ben:

What is the basis for this statement? There has no reduction of MFC
support in recent Visual Studio offerings (other than the much less
convenient IDE than in VC6).

The fact that a gazillion new APIs have been introduced in Win32 without
being added to MFC. The fact that MFC can't support the 2006 look-and-feel.
The fact that MFC hasn't kept up with the C++ standard and as a result is
far less efficient than template and native-exception-based frameworks.

Given that development of WTL, the intended replacement for MFC, seems to
have been dropped, I don't see a high likelihood of further MFC improvements
either.

>
And I hear rumors of increased support for native code (including MFC) in
future versions of VC++.

Personally, I am not sure that the entire MC++ and C++/CLI (not to mention
VB.NET) was not misguided. .NET is nice, and C# is a great language, but
the duplication in the three languages (VC, C#, VB) was a huge effort with
somewhat marginal rewards, IMHO.

David Wilkinson

[Ben Voigt]

"James" <mi*******@gmail.comwrote in message
news:OJ**************@TK2MSFTNGP03.phx.gbl...

Thank you, makes sense. Realizing that I'm a C++ neophyte, and assuming I
have the mental capacity to undertake such an endeavor, where would you
recommend I start if I were interested in understanding how to create
device drivers? I realize it's a very large uphill fight, but I have a
lot of time on my hands and I'd like to add it to my list of things I
know.

So assume I'm completely competent developing Windows based CLR apps in
C#/VB.NET and I want to start from absolute "Square 1" in VC++ (i.e. I
know what int x; does!), where would you recommend I start? Writing basic
console applications to start? Any good web references for people that
have a general knowledge of programming paradigms but very very little C++
knowledge?

If you want to do device drivers:

Definitely start with some number crunching and bit twiddling, a console app
is best for this.
Then write some code for microcontrollers like Microchip's PIC or the
Rabbit, where the system is small enough to easily understand and you get
some practice with interrupt handling.
Also write some multi-threaded user-mode Win32 code and use interprocess
communication to get data between a processing app and a front-end display.
And use only the pure Win32 API (kernel32, user32), no wrapper frameworks.
Then you will be ready to try some kernel-mode drivers.

[David Wilkinson]

Replies inline:

Ben Voigt wrote:

The fact that a gazillion new APIs have been introduced in Win32 without
being added to MFC. The fact that MFC can't support the 2006 look-and-feel.
The fact that MFC hasn't kept up with the C++ standard and as a result is
far less efficient than template and native-exception-based frameworks.

Yes it's true there have not been too many improvements. But it's not
like what happened to VB6 (RIP). MFC still provides the application
framework, and the great thing about it is that it can seamlessly call
the underlying Windows API. You can wrap new API's in your own classes
if you wish. Take the file dialog for example. I'm sure everybody thinks
they could have done a better job than the CDocManager/CFileDialog
fiasco in MFC. Now's your chance ...

Given that development of WTL, the intended replacement for MFC, seems to
have been dropped, I don't see a high likelihood of further MFC improvements
either.

Was WTL the intended replacement for MFC? I didn't know that. Even as it
is I have thought of looking into WTL, but I just have so much invested
in MFC. I know MFC has a lot of warts, but I know most of them by now.

David Wilkinson