|
Heh... there's probably a joke to be had here, something about replacing wizards with sorcerers... but yeah. It should be easier.
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Shog9 wrote:
Heh... there's probably a joke to be had here, something about replacing wizards with sorcerers... but yeah. It should be easier.
Back in the dark ages. A couple of us built a wizard to generate some code (DB wrappers I think - can't remember). Anyway the other engineer was a big Terry Pratchett / Discworld[^] fan. So he named the wizard 'Rincewind[^]' after the inept wizard of the Discworld stories. 
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Excellent.
Loading DB Wrapper Wizzard...
File is read-only! ohshitohshitohshitohshitohshitohshitohshitohshit
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
|
Ummm...I can do the same in about 30 seconds in c# if it made any sense to do so.
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 always thought it was a bit of a silly design that was parroted by too many developers not really taking the time to consider the task at hand when they developed their app. So many apps were shoe-horned into that style of thinking when it really didn't apply to them at all.
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.
"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
|
|
|
|
|
Yeah doc/view was mostly useless - but i don't think most developers stuck to it in any great sense (certainly true for myself for the past 10 years or so).
However, he does have a point, the wizards (and the rest of IDE) needs a lot of work yet...
Tim Stubbs
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
