I hate MFC!!!
-
So subclass the damn thing - give it a color method - and put it in your toolkit for alter use. This would take about 15 min - once. Richard I must have liberty Withal, as large a charter as the wind, To blow on whom I please. As You Like It. Act ii. Sc. 7. William Shakespeare
If I need to subclass every "damn thing" in MFC that pisses me off, than I'd rather develop my own framework. :beer:
-
Joe Woodbury wrote: A bigger reality is that there is no need to "paint an edit control background" unless you really like creating non-standard interfaces that your users will hate. The edit control background is just an example - probably a bad one, but I think you get the point. Joe Woodbury wrote: And you have this universal list of "simple things"? Heck, UI "programming" is drawing on the screen. Don't make a science of it. :beer:
Nemanja Trifunovic wrote: but I think you get the point. No, I don't. Nemanja Trifunovic wrote: Heck, UI "programming" is drawing on the screen. Don't make a science of it. Unadulterated bullshit. UI "programming" is every bit an engineering displine as any other aspect of software development. And since it's what the user sees and perceives as the software, if it isn't the most important aspect, it's pretty close.
-
KaЯl wrote: Your problem is not MFC. You hate GUI programming too I don't like GUI programming, and that's exactly why I need something to help me finish it quickly. Therefore, MFC is a part of the problem. :beer:
MFC are not that easy to learn, there are a lot of tricks to discover, but they are so powerful : If your target is to design a simple and basic GUI, not a real application in my sense, use VB instead, or even XML. If it's more evoluate, you could consider using Delphi. French proverb of the day : Un mauvais ouvrier a toujours de mauvais outils "Bad workers have always bad tools" :rolleyes:
Angels banished from heaven have no choice but to become demons Cowboy Bebop
-
Nemanja Trifunovic wrote: but I think you get the point. No, I don't. Nemanja Trifunovic wrote: Heck, UI "programming" is drawing on the screen. Don't make a science of it. Unadulterated bullshit. UI "programming" is every bit an engineering displine as any other aspect of software development. And since it's what the user sees and perceives as the software, if it isn't the most important aspect, it's pretty close.
Joe Woodbury wrote: Unadulterated bullshit I really think you have a problem. Joe Woodbury wrote: UI "programming" is every bit an engineering displine as any other aspect of software development. No it isn't. It has more to do with art than with engineering. Joe Woodbury wrote: And since it's what the user sees and perceives as the softwareit isn't the most important aspect, it's pretty close. And I still can't see how a good tool can hurt in making GUI. :beer:
-
MFC are not that easy to learn, there are a lot of tricks to discover, but they are so powerful : If your target is to design a simple and basic GUI, not a real application in my sense, use VB instead, or even XML. If it's more evoluate, you could consider using Delphi. French proverb of the day : Un mauvais ouvrier a toujours de mauvais outils "Bad workers have always bad tools" :rolleyes:
Angels banished from heaven have no choice but to become demons Cowboy Bebop
KaЯl wrote: French proverb of the day : Un mauvais ouvrier a toujours de mauvais outils "Bad workers have always bad tools" There is a Serbian proverb that says pretty much the same, but it is less polite ;P :beer:
-
I've worked with C# and VS.NET 2002 and found out that, while much better than MFC + VC 6. it still requires too much messing with simple, tedious things (like manually adding event handlers). Besides, .NET based desktop applications are not (yet) an option IMHO. :beer:
What is so difficult about selecting the control, opening the properties tab, clicking on the lighning-bolt icon at the top to switch to event view, then selecting the event and double-clicking to add a default named event handler code segment? Granted one must still write the logic to handle the event in the function, but I really don't think the wizard exists yet that could predict my intentions or read my mind....:confused: Some ideas are so stupid that only an intellectual could have thought of them - George Orwell
-
What is so difficult about selecting the control, opening the properties tab, clicking on the lighning-bolt icon at the top to switch to event view, then selecting the event and double-clicking to add a default named event handler code segment? Granted one must still write the logic to handle the event in the function, but I really don't think the wizard exists yet that could predict my intentions or read my mind....:confused: Some ideas are so stupid that only an intellectual could have thought of them - George Orwell
Rob Graham wrote: What is so dificult about selecting thew control, opening the properties tab, clicking on the lighningbolt icon at the top to switch to event view, thn selecting the event and double-clicking to add a default named event handler code segment. It is not dificult. It is tedious and time-consuming. :beer:
-
Joe Woodbury wrote: This not only makes no sense but is why so much software is crap. What is your problem? I'm NOT a GUI programmer, and I DON'T make desktop applications for the "outside world". I just need to develop an in-house tool in a reasonable amount of time - shorter than I needed for the development of the core functionality. Is it so unreasonable? :beer:
Nemanja Trifunovic wrote: Is it so unreasonable? Yes. Because you didn't learn the tool instantly so you blame it for your shortcomings. This isn't to say MFC doesn't have it's flaws, every class library does, but blaming the tool isn't going to get you anywhere or make you a better developer. Furthermore, As I stated elsewhere, UI development is an engineering discipline and good UI development will often take as much time, sometimes more, than the core logic. Given your ignorance of UI development it is very likely you are making your tool far more complicated than it need be. Finally, just because a tool or product is for in-house use, those users should not be treated any less professionally as a commercial customer.
-
Nemanja Trifunovic wrote: Is it so unreasonable? Yes. Because you didn't learn the tool instantly so you blame it for your shortcomings. This isn't to say MFC doesn't have it's flaws, every class library does, but blaming the tool isn't going to get you anywhere or make you a better developer. Furthermore, As I stated elsewhere, UI development is an engineering discipline and good UI development will often take as much time, sometimes more, than the core logic. Given your ignorance of UI development it is very likely you are making your tool far more complicated than it need be. Finally, just because a tool or product is for in-house use, those users should not be treated any less professionally as a commercial customer.
Joe Woodbury wrote: Because you didn't learn the tool instantly so you blame it for your shortcomings. Like I said, I've been using MFC for 5 years for UI stuff. Joe Woodbury wrote: Furthermore, As I stated elsewhere, UI development is an engineering discipline Joe Woodbury wrote: Given your ignorance of UI development it is very likely you are making your tool far more complicated than it need be. Again, I'm an engineer, not an UI designer. :beer:
-
Joe Woodbury wrote: Unadulterated bullshit I really think you have a problem. Joe Woodbury wrote: UI "programming" is every bit an engineering displine as any other aspect of software development. No it isn't. It has more to do with art than with engineering. Joe Woodbury wrote: And since it's what the user sees and perceives as the softwareit isn't the most important aspect, it's pretty close. And I still can't see how a good tool can hurt in making GUI. :beer:
Nemanja Trifunovic wrote: No it isn't. It has more to do with art than with engineering. As long as you believe that, you will fail. UI Design is actually more related to the craft of printing than art. It also requires a strong understanding of human factors, a definite science, and psychology, another definite science. UI Programming requires some understanding, and a great deal of respect, of the discipline of UI Design, but also requires a very strong understanding of software engineering, the API set and the tools involved. Nemanja Trifunovic wrote: And I still can't see how a good tool can hurt in making GUI. We have one, it's called MFC. And, as other people have pointed out, if you just want to prototype or do a one off, there is VB, Delphi and many other tools. (Even just gussying up Access with VBA may be sufficient.)
-
Nemanja Trifunovic wrote: Why there is no good RAD tool for C++? There is - it's called C# :D cheers, Chris Maunder
Beware. They will call you an ignorant fool who can't use MFC. ;) :beer:
-
It took me one day to develop the "logic" with STL, and now I'm working on damn UI for almost a week. Why there is no good RAD tool for C++? No wonder there are so many VB users. Die, MFC, die!!! :mad: :mad: :mad: :beer:
Nemanja Trifunovic wrote: Why there is no good RAD tool for C++? There is - it's called C# :D cheers, Chris Maunder
-
It took me one day to develop the "logic" with STL, and now I'm working on damn UI for almost a week. Why there is no good RAD tool for C++? No wonder there are so many VB users. Die, MFC, die!!! :mad: :mad: :mad: :beer:
i'd use .NET if it wasn't so g-ddamn slow.. it took about 5 seconds to load a C# program i made for calculating NFL QB passer ratings... all it was was a bunch of text boxes and a button MFC is fast but not very customizable unless you know it VERY Well.. i still don't know it VERY well after using it for a long time i'm curious about WTL.. from what i hear its better than MFC i need a real, standardized, GUI and app. framework Borland C++ Builder was also just as slow
- Roman -
-
How about a post with GWB using STL to write software to work out how much oil there is in Iraq ;P Elaine The tigress is here :-D
He couldn't do it. He'd choke on CPRetzel O.K. It's bad I admit it but it's late Anthony www.TonysOpenSource.pwp.blueyonder.co.uk
-
i'd use .NET if it wasn't so g-ddamn slow.. it took about 5 seconds to load a C# program i made for calculating NFL QB passer ratings... all it was was a bunch of text boxes and a button MFC is fast but not very customizable unless you know it VERY Well.. i still don't know it VERY well after using it for a long time i'm curious about WTL.. from what i hear its better than MFC i need a real, standardized, GUI and app. framework Borland C++ Builder was also just as slow
- Roman -
Roman Nurik wrote: it took about 5 seconds to load a C# program i made for calculating NFL QB passer ratings And how long did it take to load the second time? cheers, Chris Maunder
-
If I need to subclass every "damn thing" in MFC that pisses me off, than I'd rather develop my own framework. :beer:
make one and post it here :-D My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
-
Is it legal in Sweden? :omg:
Angels banished from heaven have no choice but to become demons Cowboy Bebop
No sir. But if it's that good, then what the heck? ;) -- Eventhough the forrest is full of trees, there's still no tree between the trees.
-
Robert Vista wrote: No, you seem to be the only one obsessed with George Bush Is it wrong to post about GWB? Come on he is the World leader... Current headlines are focused on Saddam and Bush only. No offense but what else you are expecting in the Lounge? ;) Kant Sonork-100.28114 Don't :beer: and Drive.
Sex, drugs, rock and roll?:-O
-
Nemanja Trifunovic wrote: Why there is no good RAD tool for C++? There is - it's called C# :D cheers, Chris Maunder
Chris Maunder wrote: There is - it's called C# The only failing I see with C# at this time is the unavailiabilty of the runtime on user desktops. If I write an application using MFC I usually statically link it, I know it "adds" more size to the executable but I can be assured that it will run on the users system without some weird external DLLs be present (well most of the time at least :) ) I have been reviewing C# and I would really like to use it, but for desktop applications distributed as shareware I do not feel that it is there yet. I would hate to tell people they need to download a 20Meg runtime installer to use my application especially if these people are on dial up. Once the runtimes become readily available on user machines then great, but remember Visual Basic it was out for awhile, and people where still downloading the visual basic runtimes to run VB apps. I'm hoping that C# or the .NET runtime will be more readily available so I can deploy desktop shareware apps using C#, from what I have read and the limited reading materials I have on the subject it looks like a great language, built for easy "Windows" development. Code4Food ---- "There is no try; only do or do not" -Yoda
-
>A couple of months perhaps to master it. Mastery of the STL to me implies the ability to use all parts of it with ease and the innnate understanding of why certain choices were made in its design. The same goes for C, C++, MFC, etc.... It took me about a year to get the hang of all the container classes, and probably another year or so before I added a custom container type. I rarely use the multiset and multimap container, and I've never used the heap container. find, find_if and for_each are algorithm staples, but I've never used any of the set_ functions, nor have opportunities for search_n, mismatch, and the others I cannot remember. I can't imagine someone obtaining the experience to use these items efficently in just a few months. Heck, I can't even imagine the average programmer needing them all in a few months. There's more to mastery than pressing F1.
Richard Melton wrote: Mastery of the STL to me implies the ability to use all parts of it with ease and the innnate understanding of why certain choices were made in its design. To use all parts of it with ease requires experience with the library. Just like any other library as you mention. The design choices can be picked up in a book or two. I dare say the design of STL is MUCH easier to understand than that of MFC for instance. MFC is a behemoth! I remember those long nights with MFC Internals.. :eek: Richard Melton wrote: I can't imagine someone obtaining the experience to use these items efficently in just a few months. Heck, I can't even imagine the average programmer needing them all in a few months. There's more to mastery than pressing F1. Which is why programmers should read an excellent book on the topic such as the one I referenced. Anyone who passed a university course in datastructures and algorithms shouldn't find anything surprising in STL. STL can be a real time saver - if you know how to find what you're looking for that is. -- Eventhough the forrest is full of trees, there's still no tree between the trees.