I hate MFC!!!
-
Anna-Jayne Metcalfe wrote: Try WTL or another framework then I doubt WTL is easier at all. Besides, It's not me who decides :(( :beer:
I find it easier actually. But maybe that's just me. :) Nemanja Trifunovic wrote: Besides, It's not me who decides Hey, know what? I get to be part of these decisions. :rolleyes::-D -- Eventhough the forrest is full of trees, there's still no tree between the trees.
-
Navin wrote: Let's see, you hate MFC, and you hate Linux... what *do* you like? From my CP profile: Enjoyes: C++ coding, reading, movies, sleeping, but most of all the company of his wife and baby daughter. Dislikes: GUI programming, writing documentation, garbage collectors, Open Source zealots. ;) :beer:
Nemanja Trifunovic wrote: C++ coding movies sleeping GUI programming writing documentation garbage collectors Open Source zealots Amen! May I assume that you also dislike Java? Can I be your friend? :-D -- Eventhough the forrest is full of trees, there's still no tree between the trees.
-
I still want some of that smoke though. ;P -- Eventhough the forrest is full of trees, there's still no tree between the trees.
-
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:
-
Stuart van Weele wrote: What exactly is the problem? The problem is that if I want to paint an edit control background at compile time, I should right-click on that control and pick the color from a palette - not to mess with WM_CTLCOLOREDIT. Simple things should be done simply. Stuart van Weele wrote: Granted, the tools are not real CASE tools and the GUIs they create a not flashy, but they get the job done. In a week. Real tools should get the same job done in a day. :beer:
-
Your problem is not MFC. You hate GUI programming too I Love GUI programming. I like++ MFC
Angels banished from heaven have no choice but to become demons Cowboy Bebop
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:
-
.NET isn't much better, in my opinion. That's why I use my own framework built on top of MFC so I only went through the pain once. Now I'm porting the whole thing over to .NET, because it's so lame also! (see my CP articles on the Application Automation Layer). Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka -
Actually, STL isn't that hard to learn at all! Generic Programming and the STL: Using and Extending the C++ Standard Template Library [^] gave me enough Ohs, Ahs and Ahas to get me going. You just need to understand some basic concepts which are, contrary to manys belief, very simple. 1 day is perhaps a bit short, but a week is enough to learn how to extend the STL. A couple of months perhaps to master it. -- Eventhough the forrest is full of trees, there's still no tree between the trees.
>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.
-
Stuart van Weele wrote: What exactly is the problem? The problem is that if I want to paint an edit control background at compile time, I should right-click on that control and pick the color from a palette - not to mess with WM_CTLCOLOREDIT. Simple things should be done simply. Stuart van Weele wrote: Granted, the tools are not real CASE tools and the GUIs they create a not flashy, but they get the job done. In a week. Real tools should get the same job done in a day. :beer:
Nemanja Trifunovic wrote: The problem is that if I want to paint an edit control background at compile time, I should right-click on that control and pick the color from a palette - not to mess with WM_CTLCOLOREDIT. Simple things should be done simply. And you have this universal list of "simple things"? The reality of software is for a class library to anticipate every design decision a developer wants to make it would have to be incredibly huge and likely incredibly complicated. 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. Nemanja Trifunovic wrote: Real tools should get the same job done in a day. Based on what? I've never seen such a tool that creates anything but crap. The computer highway is littered with the carcases of companies claiming to have invented the perfect rapid application development tool. In the end software engineering requires human thought and nothing will ever get around that. (The irony is that many developers here on Code Project, including myself, probably could have developed your UI in a day using nothing but MFC. Yet, I couldn't do the same with OWL, even though I've used it before. I'm simply not an expert in it.)
-
No, you seem to be the only one obsessed with George Bush.:confused:
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.
-
Personally I think MFC is fantastic......and if you dont like it then why dont you just use VB???
DominicG wrote: and if you dont like it then why dont you just use VB??? Are you kidding? MFC is not C++. It is a library, and a bad one. Even Microsoft don't use it much. :beer:
-
Nemanja Trifunovic wrote: The problem is that if I want to paint an edit control background at compile time, I should right-click on that control and pick the color from a palette - not to mess with WM_CTLCOLOREDIT. Simple things should be done simply. And you have this universal list of "simple things"? The reality of software is for a class library to anticipate every design decision a developer wants to make it would have to be incredibly huge and likely incredibly complicated. 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. Nemanja Trifunovic wrote: Real tools should get the same job done in a day. Based on what? I've never seen such a tool that creates anything but crap. The computer highway is littered with the carcases of companies claiming to have invented the perfect rapid application development tool. In the end software engineering requires human thought and nothing will ever get around that. (The irony is that many developers here on Code Project, including myself, probably could have developed your UI in a day using nothing but MFC. Yet, I couldn't do the same with OWL, even though I've used it before. I'm simply not an expert in it.)
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:
-
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:
Nemanja Trifunovic wrote: I don't like GUI programming, and that's exactly why I need something to help me finish it quickly. This not only makes no sense but is why so much software is crap. I don't like SNMP programming, but when I needed to do it a few years back, I took the time to learn all about it and then took the time to write the code correctly. As a result, the core code I wrote hasn't significantly changed in six years.
-
Nemanja Trifunovic wrote: I don't like GUI programming, and that's exactly why I need something to help me finish it quickly. This not only makes no sense but is why so much software is crap. I don't like SNMP programming, but when I needed to do it a few years back, I took the time to learn all about it and then took the time to write the code correctly. As a result, the core code I wrote hasn't significantly changed in six years.
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:
-
Stuart van Weele wrote: What exactly is the problem? The problem is that if I want to paint an edit control background at compile time, I should right-click on that control and pick the color from a palette - not to mess with WM_CTLCOLOREDIT. Simple things should be done simply. Stuart van Weele wrote: Granted, the tools are not real CASE tools and the GUIs they create a not flashy, but they get the job done. In a week. Real tools should get the same job done in a day. :beer:
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
-
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: