MFC's future
-
And the funy thing that the highly paid and the most valuable people working in my organization are the ones who back 15-20 years ago wrote some proprietary server stuff on very popular and cutting edge back then VAX/VMS... using Pascal!!! Gues what -- they are still in charge... The real kicker is when .net is standard on every PC. At that point who wouldn't use it for little utilities etc when it compiles to a tiny 5k program. I'm amazed when a fairly sophisticated business app compiles to only 100kb in total for .net. It's great that way. Sure, however I was waiting for MFC4 to appear on every PC for 6 years now. Looks like it happened!... That's why alot of MFC guys are not in a hurry to move to VC7 -- wait another 6 years for MFC7 to be deployed?! 100KB business applcation? How much resources are in it? Or maybe resources under .NET became smaller? "Hello world" -- 12 bytes --> that's how large your ideal EXE should be, assuming Notepad is installed? How large is CLR man?... Check this out if haven't done yet... Also, check your IE size that suppose to deploy your 100k EXE... MFC is just loaded with too much crap that it has accumulated over the years from win 3 days to now and it's become so byzantine and archaic by modern standards that it just has to collapse eventually under it's own weight. So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... That's not the point and you know it. I don't have a single diskette in this office, I *do* however download software from the internet. That's the whole point. If you forsee a rewarding career as a maintenance programmer, I'm not going to tell you that's wrong, to each his own. I just prefer to be working on new things, learning new things etc. ------------
-
I agree that the winforms controls are nice, but I can also code a ui much quicker in MFC - due to these main reasons: 1) document templates 2) commandui 3) command routing 4) shell integration 5) document/view support ... This is not to mention the fact that anything I can't do in MFC has been done by somebody, some place and surely posted on some Web site. WinForms is just too new to have that kind of support. Can I hack any of these features with WinForms? Sure. But why should I move to something until it proves to be better than what I currently have? I guess it comes down to user base issues. My clients are accustomed to what we as MFC devs can produce and the timeline it takes us. I can't justify taking longer in order to use a new tool when I can't quantify why the new tool will help them as end-users. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen SigvardssonI really don't understand this, perhaps it's because we develop client server database apps primarily, but there is undoubtedly no question that winforms or several orders of magnitude faster than mfc. I don't know about dancing paper clips etc but for a meat and potatoes client side application I just can't agree. ------------
-
Tom Archer wrote: I would be one of those people. As someone that is on the various betas, I can't be specific. However, I can tell you that I wouldn't have spent the past number of months writing a book on extending MFC if I thought MFC were going away. You are so close to becoming my hero. :)
Tom Welch wrote: You are so close to becoming my hero. :) I should come up with my own theme song... Coder-man, coder-man Does whatever a guru can. Spins an app, any size Right before your very eyes. Look out! Here's comes the coder-man.... Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
Shog9 wrote: MFC-only coders will live on for years in maintenance roles and in their own projects, *looks at resume, notices no .NET-related technologies listed* Aww CRAP! ;P I prefer to wear gloves when using it, but that's merely a matter of personal hygiene [Roger Wright on VB] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. [Rich Cook]
-
I really don't understand this, perhaps it's because we develop client server database apps primarily, but there is undoubtedly no question that winforms or several orders of magnitude faster than mfc. I don't know about dancing paper clips etc but for a meat and potatoes client side application I just can't agree. ------------
John Cardinal wrote: I don't know about dancing paper clips etc but for a meat and potatoes client side application I just can't agree I don't about the remark on assistants as I've never used them. However, I was lead programmer on the object team for Peachtree Office Accounting. I don't know how much more "meat and potatoes" you can get than accounting. Also, the clients that I generally work for are companies that want absolutely everything custom drawn. They have teams of graphics designers that specifically don't want the app to look like all others. In a situation like that, I'm going to be much more productive working with an established ui framework that has a ton of support; rather than a new and unproven forms package. Don't get me wrong. I'm not saying WinForms isn't a decent package. What I am saying is that when faced with extremely challenging UI requirements and a tight deadline, I'd go with MFC today. In the future that very well might change. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
John Cardinal wrote: I don't know about dancing paper clips etc but for a meat and potatoes client side application I just can't agree I don't about the remark on assistants as I've never used them. However, I was lead programmer on the object team for Peachtree Office Accounting. I don't know how much more "meat and potatoes" you can get than accounting. Also, the clients that I generally work for are companies that want absolutely everything custom drawn. They have teams of graphics designers that specifically don't want the app to look like all others. In a situation like that, I'm going to be much more productive working with an established ui framework that has a ton of support; rather than a new and unproven forms package. Don't get me wrong. I'm not saying WinForms isn't a decent package. What I am saying is that when faced with extremely challenging UI requirements and a tight deadline, I'd go with MFC today. In the future that very well might change. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen SigvardssonTom Archer wrote: object team for Peachtree Office Accounting Peachtree! I've been dealing with them lately. We wanted to integrate with them and it turned out they have the most archaic 3rd party developer support of any accounting software we've ever dealt with. They only have one company licensed to do 3rd party integration. Tom Archer wrote: the clients that I generally work for are companies that want absolutely everything custom drawn. They have teams of graphics designers that specifically don't want the app to look like all others That's quite different from what I've been doing I can see where you become very quick at customized GUI's using MFC. By meat and potatoes I meant exactly the opposite: a standard GUI business application, nothing fancy. I guess that it's just a matter of time before all those things your used to doing quickly in MFC for unique UI's will be available in WinForms. I've been most impressed though with just the basic "guts" programming speed, SQL server, web stuff, business objects etc. ------------
-
Tom Archer wrote: object team for Peachtree Office Accounting Peachtree! I've been dealing with them lately. We wanted to integrate with them and it turned out they have the most archaic 3rd party developer support of any accounting software we've ever dealt with. They only have one company licensed to do 3rd party integration. Tom Archer wrote: the clients that I generally work for are companies that want absolutely everything custom drawn. They have teams of graphics designers that specifically don't want the app to look like all others That's quite different from what I've been doing I can see where you become very quick at customized GUI's using MFC. By meat and potatoes I meant exactly the opposite: a standard GUI business application, nothing fancy. I guess that it's just a matter of time before all those things your used to doing quickly in MFC for unique UI's will be available in WinForms. I've been most impressed though with just the basic "guts" programming speed, SQL server, web stuff, business objects etc. ------------
John Cardinal wrote: Peachtree! I've been dealing with them lately. I have no idea what they're up to now. I was there '95 - '96. John Cardinal wrote: I've been most impressed though with just the basic "guts" programming speed, SQL server, web stuff, business objects etc. Oh ok. Then hell, we're saying the same thing - only differently! I would agree with you then. The main advantage that MFC has over .NET (to me anyway) is the advanced UIs I can build with it. For "meat and potatoes" UI and great class support, the BCL is easily better. That's why I wrote the Extending MFC book. I'm not about to give up the power I have with the UI stuff, but I recognize that by flipping a project setting I also get all the productivity enhancements afforded by the various BCL classes. Now if WinForms were to provide the same sort of UI that I can get with MFC, then I'd have to seriously consider doing MC++ only. However, I don't see that happening for a couple of years so until then I'll take the combination of the two in order to enjoy the best of both worlds. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
igor1960 wrote: So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... That's not the point and you know it. I don't have a single diskette in this office, I *do* however download software from the internet. That's the whole point. If you forsee a rewarding career as a maintenance programmer, I'm not going to tell you that's wrong, to each his own. I just prefer to be working on new things, learning new things etc. ------------
Nobody against "working on new things, learning new things etc"... But your original message was stating that MFC is crap, wasn't it?... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
Nobody against "working on new things, learning new things etc"... But your original message was stating that MFC is crap, wasn't it?... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: But your original message was stating that MFC is crap, wasn't it? Not at all! What I said was this: MFC is just loaded with too much crap that it has accumulated over the years from win 3 days And I think you can agree at least partially. ------------
-
igor1960 wrote: But your original message was stating that MFC is crap, wasn't it? Not at all! What I said was this: MFC is just loaded with too much crap that it has accumulated over the years from win 3 days And I think you can agree at least partially. ------------
-
Christian Graus wrote: so VB and MFC will become poor second cousins to C# sooner rather than later. Unless some of the existing MFC devs give up their egos ;-) and decide to use Managed C++ to mix MFC with the .NET BCL :-) Nish
"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies My book :- Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
No disrespect to your fine book, but that's still a hack, designed to help people leverage existing skills. I'm sure it will be a valuable way to extend the life of MFC, but it won't save it from the scrap heap. Christian NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma Anonymous wrote: OK. I read a c++ book. Or...a bit of it anyway. I'm sick of that evil looking console window. I think you are a good candidate for Visual Basic. - Nemanja Trifunovic
-
Navin wrote: And if you want to write cross-platform, you can't use MFC anyway... you'll need wxWindows, VCF, Qt, etc., or program in Java. .NET / CLI is being ported to *nix http://www.go-mono.com/[^] Can Mac's be far behind? ------------
Rotor already has a implementation for OS X , but is not commercial. - Kannan