|
John Cardinal wrote:
I wouldn't want to inflict Doc/View on anyone though, how many times, in how many apps does it truly fit the task at hand? Sure if you're editing documents in an app, but really, how often is that in the big scheme of things?
I love the Doc/View architecture, although I mainly used it with FormView. It suited my development needs very well. And helped to seperate the UI code from the data which was a great help in writing lots of data-entry forms.
John Cardinal wrote:
I much prefer the blank slate approach that you can turn into anything you want, although all our business apps are starting to look a lot like Outlook.
As all my apps have a similar feel to them, I prefer for the boilerplate to be generated by a wizard rather than having to cut and paste apps together. I build a few more wizards if the Visual Studio wizard-addin code didn't rely on a large proportion of black-magic 
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
App Wizard? People actually use that crap? Why not just skip programming all together? It seems that people like to be removed from programming as much as possible, if that's the case why not just quit programming and become a manager? 
|
|
|
|
|
Hey the pay's probably better... Actually i've heard this kind of thing before - remember classwizard? Yes it was horrible but it did shorten the odd task. I hate doing everything by hand when i've done it a million times before.. I spend a good deal of time setting up the IDE with macros and plugins to automate many aspects of programming. Perhaps that makes me less of 'hard core' programmer but i do understand all the code that's been added, and can edit it at will so i see no harm in it..
Tim Stubbs
|
|
|
|
|
Anonymous wrote:
It seems that people like to be removed from programming as much as possible, if that's the case why not just quit programming and become a manager?
Using AppWizard to build a framework windows application is a great time saver. Giving the developer a chance to concentrate on the core product rather than all the boilerplate code that is needed for a modern windows application.
Of course, any MFC developer worth his salt knows how to create an MFC application from scratch and understands the mechanics beneath the AppWizard generated code. Heck, some of us started using MFC before the AppWizard came along and had to build everything from scratch.
If the tool is there, you might as well use it.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
I think that all the smart programmers want to get to the nice caramel core as soon as possible instead of chewing on the more cut and dried part on the outside 
I also got the blogging virus..[^]
|
|
|
|
|
i dont really see how having a wizard can make it all that better.
.net is by default a very easy platform to develop on.
guis are really just drag and drop if
in the same steps it takes to create an app in mfc with the wizard you could have created a new windows form app, drag and drop a taskbar, menubar, toolbar, etc etc onto it
|
|
|
|
|
with a few clicks in vs.net 2003 or 2005 you could get a fully customized app with almost no code at all, if any!! also .net apps are so easy to manage compared to c++ windows apps!! thats why i switched to using C# for my windows applications(desktop), but I still use C++ HEAVILY since I like using C++ to make games, C# just looks bad with dx in my opinion.
IM PROUD TO BE A GMAIL;
|
|
|
|
|
This question must be facetious, who in their right mind would want to see MFC rear it's ugly head again?
I used it for many years and I can only imagine the people most devoted to it are the ones who have a job that depends on their arcane knowledge of something so overly convoluted and complex.
It's time to move on people, let it die.
"In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office."
- Ambrose Bierce
|
|
|
|
|
It's certainly no question of devotion on my part, it's just that 10-15 years of development at my company were based on that and Win32 which equals extreme danger in shifting to a new framework for mission critical apps (in other words, the apps that pay for my sports car!).
Now, we do have a new application that's all .NET here but we have to strap the guy who did it down before he's allowed to talk about the forms designer..
Tim Stubbs
|
|
|
|
|
its funny i happen to be one of those dot not guys surrounding by a bunch of well not really mfc but rather cobol and hardcore g00r00 vbscript jockies.
they fear the framework from what i gather..
change? money? survival of the fitest? who knows .. either way i think we can all agree that .net does have its advantages over its ancestors...
|
|
|
|
|
ancestors? You mean Java 
Tim Stubbs
|
|
|
|
|
I feel the same way about C++ 
|
|
|
|
|
John Cardinal wrote:
I used it for many years and I can only imagine the people most devoted to it are the ones who have a job that depends on their arcane knowledge of something so overly convoluted and complex.
But... VB coders don't care about MFC!  
Heh, yeah, i know what you're saying. While i still do new development with MFC, and maintain a rather large pile of older code, i'll shed no tears at its demise. The move to C# for much new development has drastically reduced the number of "you shouldn't have to know this, but..." questions i answer, not to mention making it much quicker to write and adapt these apps.
It's like having an up-to-date VB, with the added bonus of syntax that doesn't give me flashbacks... 
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Some pro's of MFC versus .NET:
- Startup time for large apps is considerably quicker (since we're not churning away loading countless DLLs from disk..). This is really important for apps starting at logon!
- Memory footprint tends to be considerably smaller (thinking including the runtimes here..)
- The designer in .NET is total rubbish, bugridden and needs to be punished
- Source code. As in, i've got some for the framework as opposed to 'no idea' what .NET is really up to..
- Speed. A contentious issue this but .NET UI-orientated apps feel darn clunky - lethargic compared to an MFC one. And how slow is the debugger?
- Codebase... just a _few_ years more out there..
- Maturity - like it or not MFC is predictable and stable..
- Meglomania. It's my memory, i'll allocate it (and leak it) if i want to.
I think it's easy to get carried away with new shiny microsoft technologies - but it's usually better to sit back, let it mature and settle (version 2.0 for example rejigs tho whole C++ syntax which was SO ferkin horrible in 1.1) before rushing in a porting 10 years worth of work for no appreciable gain. Which is how I see it, as it would take 12 months for us to port out apps to .NET and gain exactly diddly squat (aside from alienating our wives) in return.
It'll be a far more interesting beast with the advent of longhorn.. Of course, our customers PCs will be a lot faster by then too
Don't get me wrong - we are leveraging parts of the framework (Remoting) - but i'd like to see both .NET and it's IDE improve _drastically_
Tim Stubbs
|
|
|
|
|
...people rely on proprietary dependencies such MFC/.NET that will not be supported in the future ?
You *REALLY* want something, fast, efficient, portable and that will be supported for quite a long time ? Then switch all your code in STL/BOOST and use wxWidgets for the UI !
Then you won't have to scratch your head asking yourself how much it will cost you to maintain your software along the ages, without aches I made the switch, read the STL toturials on CodeProject, it's pretty instructive !
Kochise
In Code we trust !
|
|
|
|
|
Not sure if this was meant to be directly relevant to the poll, but if so:
Tim Stubbs wrote:
- Startup time [...] Memory footprint [...] Speed [...]
Adding another layer to a .NET program isn't going to improve that. And if you're writing native code to call from a .NET app, you can already use MFC.
Tim Stubbs wrote:
- The designer in .NET is total rubbish, bugridden and needs to be punished
Which designer? Dialogs/forms? I wouldn't exactly hold up the MFC dialog designer as a model for anything good... most of my MFC dialogs now rely on a code block to control layout, so as to support resizing.
Tim Stubbs wrote:
Codebase... just a _few_ years more out there.
Yeah, i'll agree with that.
Tim Stubbs wrote:
- Meglomania. It's my memory, i'll allocate it (and leak it) if i want to.
Well... Keep in mind, MFC makes liberal use of "temporary objects" to wrap handles and such, by default deleting them during idle processing. It's not full-blown garbage collection, but it does remove a bit of that iron grip you'd normally have on memory management with C++.
Tim Stubbs wrote:
Which is how I see it, as it would take 12 months for us to port out apps to .NET and gain exactly diddly squat (aside from alienating our wives) in return.
Yeah, porting makes no sense at all in most situations. We're having decent luck with doing new app development in C# though, with plans to integrate C++/clr into our main app once that all stabilizes. This has worked well with regards to speeding up development of internal apps, while not wasting resources on the main project.
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Adding another layer? Sorry don't quite follow that one... My point was really that .NET is probably the _least_ relevant tech for lightweight app design.
Designer - forms. And yes, i'd rather use the MFC dialog designer given a choice (and as you say, dynamic resizing isn't that hard..).
Tim Stubbs
|
|
|
|
|
Tim
I was using MFC for over 10 years, the .net framework is where MFC should have tried to go. But lets face it, it never really altered that much over the years since it's release in '91. There are other 'better' frameworks which were far superior - take OWL, I personally would of used it only that there are few jobs in the market place requiring it.
It time to hang up our MFC boots and step into some nice cosy .net boots for the next part of our journey. Notice I've not mentioned C++/C# yet. If you're moving to .net I can strongly recommend C# over managed C++ but hey that just preference. In the long run I can see little or no updates to MFC, which suggests that in the upcoming years the market place will see fewer jobs for MFC. The only way to go is the .net route, Microsoft have invested a hell of a lot of time in creating .net and I'm sure it's not going away.
My Blog ^
|
|
|
|
|
Hey, i'm using .NET now - the gcroot mixed code stuff is actually quite nice - but at the moment i'm only leveraging the more useful bits for our apps. We do have one complete .NET app now and i'm sure we'll continue to add more.
Bring on VS2005 and Longhorn - i think these two releases will make .NET far far more appealing..
Thanks for your comments - i shall give C# a bash (when i get a moment, too much work too little time) as my experience with the current framework and C++ hasn't been too rewarding (it's a kludge atm IMHO)
Tim Stubbs
|
|
|
|
|
norm.net wrote:
the market place will see fewer jobs for MFC.
There has never been a lot of MFC jobs - the market favors Java developers. Anyway, hi norm! It's been a while
Norman Fung
|
|
|
|
|
norm wrote:
hi norm! It's been a while
It certainly has, good we share such a great name ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
My Blog ^
|
|
|
|
|
norm.net wrote:
It certainly has, good we share such a great name
To norm! (all hands on deck raise your glass) 
Norman Fung
|
|
|
|
|
Actually, it is very easy to "port" an MFC application to .NET. Just turn on the /clr switch in your compiler, and the application will compile to IL. Granted, it will still use the Win32 API rather than Windows Forms, but who cares?
The question is: why would anyone port a working MFC application to .NET? Maybe it runs too fast, or consumes too little memory? 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
What the hell kind of computer are you working with? A 386 with 16mb of memory?
Speed and memory are not issues with .net, let's just put that to rest right now. Modern computers come with all the memory needed and I honestly don't see a speed difference and I've developed for years for both MFC and .net.
Maybe if your talking about a tiny little utility application or a game or something, but a large business application bottlenecks much more at things like the sql server, reporting, calculating etc. The application itself isn't a factor whether it's written in .net or MFC.
"In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office."
- Ambrose Bierce
|
|
|
|
|
John Cardinal wrote:
but a large business application bottlenecks much more at things like the sql server, reporting, calculating etc.
That may be the case. But I am not developing "large business applications" and speed and (even more) memory consumption is very important to me. Heck, when I see how .NET code performs on a system with Pentium IV and 2 Gb RAM, it makes me want to cry.
A while ago, our "guru" at the time tried to prototype a machine translation system in C# and found out it was virtually impossible with the way .NET deals with memory. Another coworker had a similar experience with Java.
I had to work with C# as a primary language for a while, and the result was fantastic: it reduced my productivity, but made my programs run slower Thank God, I am back to C++ again (no MFC, though).
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
