I hate MFC!!!
-
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:
-
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 -