|
Windows Forms is totally object-oriented, as a developer I don't expect to use MFC in .NET
|
|
|
|
|
Windows Forms has been declared dead by numerous sources - internal sources at Microsoft have even declared Windows Forms dead in 1 1/2 years from now.
MFC, despite what some people say, actually had a pretty large facelift with .NET 2003.
MFC is likely to continue to be updated for internal teams (e.g. the Office team has those nifty toolbars and a ton of code invested in MFC - they aren't likely to switch over to .NET any time soon).
|
|
|
|
|
Where did you get the sources from?
I am contemplating about learning Windows Forms and the other .NET technologies. Please post the links to these sources so that those interested (including me) can read more about it. Thanks.
|
|
|
|
|
...If people realize most (not all) of the advantages they say are in .NET, have been in VB6 for years.
Don't get me wrong, .NET has its place. I just wish people would wisen up a bit when hoping on the MS bandwagon du jour.
Jeremy Falcon
|
|
|
|
|
Fox Pro had most of the features too... the advantage of .NET is that is better designed and allows you to construct systems that can adapt easily to unexpected requirements.
|
|
|
|
|
blackmarlon wrote:
the advantage of .NET is that is better designed and allows you to construct systems that can adapt easily to unexpected requirements.
I couldn't agree with you more, but check out *most* of the pro .NET arguments. It's the same old song but with a different tune.
Jeremy Falcon
|
|
|
|
|
You're right on that one...
|
|
|
|
|
Learn to program the right way!!! also most if not all of the functions come with .net, even in v.1.1!!!
IM PROUD TO BE A GMAIL;
|
|
|
|
|
tom_dx wrote:
also most if not all of the functions come with .net
They missed the Toaster function. I had to write one myself.
Jeremy Falcon
|
|
|
|
|
-prakash
|
|
|
|
|
I am running along the same lines lately. I am slowly moving away to MFC to other GUI frameworks such as WxWidgets, so it does not matter if they port MFC over to the .NET resource hog.. 
|
|
|
|
|
I'm starting to use wxWidgets as well. It's nice to know that when I finish my app it'll be able to run on both Mac and Windows. That's two markets to sell to for the price of one.
Oh, and for those that look at every opporuntiy to dis Macs, spare me because I've heard all of it and it's mostly garbage.
Jeremy Falcon
|
|
|
|
|
Or Linux of any kind, that is one of the advantages of WxWidgets, is the potential for cross platform usage.
|
|
|
|
|
"Oh, and for those that look at every opporuntiy to dis Macs, spare me because I've heard all of it and it's mostly garbage."
The Mac Mini - $499 for a hardware and software package deal that has yet to be matched in the PC world (and probably never will be given the price of most PC software).
You've got the right idea here 
(And this coming from someone who has been using Microsoft products since DOS 2.0).
|
|
|
|
|
Anonymous wrote:
The Mac Mini - $499 for a hardware and software package deal that has yet to be matched in the PC world (and probably never will be given the price of most PC software).
Yeah, it's interesting how the Mac OS is half the price of Windows. The hardware does cost more, but it's better hardware more times than not.
Anonymous wrote:
(And this coming from someone who has been using Microsoft products since DOS 2.0).
It just means you're open minded. That's a good thing IMO. I've used MS-DOS since 2.11, and I still like Macs too.
Jeremy Falcon
|
|
|
|
|
Seems to me that Microsoft made a very determined effort to kill MFC. They hardly upgraded it since VC4. Likewise, they've tried hard to prevent WTL from catching on.
As for .NET -- it clearly began as an assault on Java.
I strongly suspect that Microsoft has kept MFC as bad as possible over the past few years so that .NET would look good.
It's really in Microsoft's interest to promote the choice as being .NET libraries versus MFC (no contest there) rather than virtual machine (with a pathetic instruction set that is only really suitable for C#) vs real machine.
Give a dog a bad name, and hang it.
There is no way they would do anything to jeopardise that belief.
|
|
|
|
|
|
I'm not really sure what "porting MFC to .NET" would entail:
A. Add the classes in MFC to the .NET library, perhaps under the Microsoft.Foundation.Classes namespace.
B. Rewrite MFC to use the .NET classes instead of Win32.
C. Extend MFC to include all the .NET classes missing from it.
None of these options seem good to me. Perhaps a better solution is to write a tool that converts MFC source code to C#/.NET.
Regards,
Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
|
|
|
|
|
I like MFC, I use it all the time. I like the fact that I can write small apps that do not depend on the .NET runtime. I say leave MFC as a seperate entity from .NET, but do include it in any future versions of VC++. Maybe in the future, when everyone has .NET installed by default, or we are all on high speed connections so it doesn't take several hours to dl the runtime I may change my mind.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
While it’s true that .net provides an easier (faster, better) way to start programming an application, it enlarges the gap to Windows. By this I mean that Windows still runs (poorly, slowly, ... ) on native C code. The .Net library structure still needs to convert its methods to a win32 call. This will continue to happen until M$ decides to create a new OS with .Net as it base technology, like WinNT, Win2000 who didn't use the DOS kernel to run on.
If M$ want us to use the new .net controls they should make it better (read: do not make me write code to implement standard windows/win32 behavior).
An example is the number-only edit control supported by the win32 OS. With MFC one can easily check this option to implement this. It is also possible to do this in .net but M$ has forgotten to implement this. This is just one example, but there are many situation where the need thrives to implement a forgotten feature with the use of a win32 dll call, just like we all did when we programmed in VB (before .net).
There wouldn’t be a need to support the MFC to .net if the controls it offers could at least do the same thing
codito ergo sum
|
|
|
|
|
|
...Win32 is closer still
Tim Stubbs
|
|
|
|
|
NT Native API is closer yet ...
|
|
|
|
|
Meh, i'm injecting my code into the kernel..
Tim Stubbs
|
|
|
|
|
and me I'm still using MASM to develop me Win32/Win64 PE-ables.
My Blog ^
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
