From: Tom Serface on
Hi David,

I was just funning with Ajay. I think he knows me by now. I took a 6 month
Microsoft class on C# a couple of years ago so I know a bit about it,
although I've never done a full desktop application with it. I agree that
it looks elegant and it is certainly easy enough to create simple programs.
I'm not disputing that it has a lot of merit. If you're doing pure .NET
stuff and you don't mind learning another syntax then it is certainly a
better choice, imo, than VB.NET.

Tom

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:dcGPh.11061$JZ3.5218(a)newssvr13.news.prodigy.net...

> LOL, I think C# is much more elegant and lacking of complexity (I mean,
> just read the code, there is no superfluous junk characters in it to
> confuse you, the meaning just leaps out at you), whereas the various C++
> community seems to take great delight in seeing how complicated looking
> they can make the latest syntax.
>
> OTOH, I am reading Advanced C# by Trey Nash which tells of best practices,
> and there is a TON of stuff to learn regarding IDisposable, threading,
> exception handling, etc. before one can claim to be proficient in C#. I'm
> starting to understand why a lot of expert C# programmers say they wish
> WinForms apps weren't so simple, because it makes it easy to do things
> wrong.
>
> -- David
>
>

From: Tom Serface on
Good points on WPF. I sure was enamored by the demos though. I love the
paradigm of separating the code from the user interface. I think that WPF
will catch on quickly as soon as the tools become readily available. Of
course, the tools are expensive so... who knows.

I learned most of what I know from this newsgroup and those that came before
it. Maybe that's my problem :o)

Tom

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:9UGPh.4906$Kd3.1969(a)newssvr27.news.prodigy.net...

> Well, there are a couple reasons for not embracing WPF now. The fact is
> the WPF market is immature. There are no WPF component libraries
> available. The design tools to deliver compelling WPF UI's are still in
> CTP state. OTOH, the WinForms market is quite mature and is currently the
> best way to write Windows UI's, IMHO. And any investment in WinForms
> carries over to WPF as there will be interop components, and the
> methodology is similar (or so I'm told). Secondly, WPF requires .NET 3.0
> which is not redistributed with Vista.
>
>
>> Mike's book is the definitive source in my opinion. I still reference the
>> one from MFC 4 :o)
>>
>
> It's a great book all right, but it really only helped me once. The rest
> of the time I got my knowledge from other sources. Probably because I got
> it after the MFC market had peaked and I had considerable info under my
> belt already.
>
> -- David
>

From: Tom Serface on
Half question and half comment: If I remember right from my short class all
of the libraries (facilities) of .NET are available to both C# and C++
right? So there is nothing C# can do that C++ can't do. The only thing I
remember really missing is Class Designer, but since I didn't use it much I
don't miss it much yet. Also, the data tips things work better in C#, if I
remember, and you didn't have to type as much to get stuff done. There
seems to be a lot of C# sample code on sites like CodeProject and CodeGuru
and third party libraries are starting to pop up. So, you can't really
argue with success. I think Microsoft's idea of improving C++ for native
makes a lot of sense if it wants to stay in the game with C++. Why not have
C++ be the best (since it's really the only logical) way to write "safe"
native programs?

To

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:dcGPh.11061$JZ3.5218(a)newssvr13.news.prodigy.net...
> LOL, I think C# is much more elegant and lacking of complexity (I mean,
> just read the code, there is no superfluous junk characters in it to
> confuse you, the meaning just leaps out at you), whereas the various C++
> community seems to take great delight in seeing how complicated looking
> they can make the latest syntax.
>
> OTOH, I am reading Advanced C# by Trey Nash which tells of best practices,
> and there is a TON of stuff to learn regarding IDisposable, threading,
> exception handling, etc. before one can claim to be proficient in C#. I'm
> starting to understand why a lot of expert C# programmers say they wish
> WinForms apps weren't so simple, because it makes it easy to do things
> wrong.
>
> -- David
>
>

From: Tom Serface on
I'd say we were mostly just darned lucky too. I agree that it isn't
Microsoft's big goal to keep people in the past compatible with people in
the future. However, from what I've heard (and I don't know all the good
juicy NDA stuff) there may be some new things in MFC in the near future.
No, I'm not in charge of rumor control, just hopeful.

You're right on the redistributable front. SP1 really made it difficult for
me to send "just the EXE" to anyone running the version of my software
compiled on a non-SP1 machine even though the DLLs and all are exactly the
same and in the same folder. And the message is lame saying something about
"This program is not compatible"???

Tom

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:JxOPh.12656$Um6.11008(a)newssvr12.news.prodigy.net...
> "MrAsm" <mrasm(a)usa.com> wrote in message
> news:sh0v03h73ibomjik1hde71tnjo22mmn03k(a)4ax.com...
>> I do agree.
>> Backward compatibility in general is an important merit of Microsoft.
>>
>
> My viewpoint is that Microsoft isn't very concerned about backward
> compatibility at all, and even less so now. VC2005 is very different in
> terms of the runtime redist, the manifests, breaking changes to C++ code,
> etc. Their SxS DLL mechanism makes it possible for the Windows loader to
> run *your* app with *their* new DLL's whether you approve it or not,
> breaking the original spirit of SxS. .NET 2.0 has breaking changes as
> well.
>
> I would say the reason MFC has backwards compatibility is there hasn't
> been any forward innovation in years! It is such a lightweight wrapper
> around the OS, and incompatibility at the OS level really shines through.
> And since it's so lightweight, there isn't much chance for it to become
> incompatible.
>
> -- David
>

From: Tom Serface on
I think what makes C# successful:

1. Microsoft really pushes it as being "more cool".
2. They get all of the VS functionality for .NET
3. Microsoft using the excuse that C++ is "too difficult" to do some of the
functionality that C# has so naturally people think C++ is "more difficult"
4. C# gets the "new stuff" a release before C++, at least, which is usually
over a year. Thus C# gets momentum.

What makes C++ successful:

1. C# can't do native
2. .NET still not a speed demon so not suitable for all applications
3. Lots of people were already using MFC/C++

Tom
"MrAsm" <mrasm(a)usa.com> wrote in message
news:gg1v03l392vg71ngr8mnvkl8648o7gl3tv(a)4ax.com...
> On Sun, 01 Apr 2007 04:05:29 GMT, "David Ching"
> <dc(a)remove-this.dcsoft.com> wrote:
>
>>OTOH, I am reading Advanced C# by Trey Nash which tells of best practices,
>>and there is a TON of stuff to learn regarding IDisposable, threading,
>>exception handling, etc. before one can claim to be proficient in C#.
>
> I believe that claiming to be proficient in C# and doing *advanced*
> stuff in C# is absolutely not trivial, and requires studying and
> coding.
>
> C# is not VisualBasic6++ ;-)
>
> MrAsm