|
Rohde wrote:
Why is MFC considered bad OOP?
rotfl.
What apart from the mess of macros, the half baked serialization, the thin wrapper around a functional api, some of the bizarre choices for base classes, strange naming conventions and the fact that it is old, and that C++, and programming in general have matured since MFC was first released. Oh. And the documentation, I don't want to bag MSDN, it's comprehensive, but it's a bloody side harder to navigate around than the Java API documentation.
Rohde wrote:
What API would you recommend for a good solid client side window app (Java is not an option).
C#. Java is pretty much dead in the water as far as I'm concerned.
If it has to be C++, you're pretty much stuck. You probably need to know at least a little MFC to get your head around WTL which is far more readable IMO.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
MFC was designed when OOP was just starting. The VC++ compiler back then was bad, did not support
the full C++ standard and the STL was not yet designed.
So MFC is full of crude hacks to circumvent the copiler bugs. It sports its own set of containers (with a flawed design) instead of using the STL ones.
Newer frameworks usually have better OO design.
But I can't help you which one to choose. I do not know enough of them.
Rohde wrote:
Lastly, does MFC have a steep learning curve?
If you know Win32 before, it is just a thin wrapper. But for starting, it may be sometimes puzzeling. But OTOH, you get more books and articles for help than you ever can read.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
Rohde wrote:
Why is MFC considered bad OOP?
One thing that was not mentioned by the others, is that views rely on being hosted in a frame. In a true OO heirarchy, this is not important - classes do not rely on where they are being used. A class should be self-contained - it should not rely on other classes unless the two are specifically used together, like a list view with a header control. But even in this case, the header control has no idea that it is being used inside a list view.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
One thing that was not mentioned by the others, is that views rely on being hosted in a frame. In a true OO heirarchy, this is not important - classes do not rely on where they are being used.
This is just one example out of a frightening number which shows that the MFC designers 1) didn't understand OOP methodology and 2) didn't even understand the features of C++.
Classes are inherited from other classes without taking advantage of polymorphism in obvious cases (see the mess of Create functions in objects derived from CGDIObject).
A reliance on macros to make their message mapping nonsense functional should have been a signal that they needed to START OVER and try again.
Why is CPropertySheet on a different branch of the class hierarchy chart than CDialog? I quote from the documentation: Objects of class CPropertySheet represent property sheets, otherwise known as tab dialog boxes.
I know a lot of the idiocy of MFC is directly inherited from the idiocy of the Windows API, but there is much that is brand new MFC flavored idiocy.
|
|
|
|
|
David Kentley wrote:
This is just one example out of a frightening number which shows that the MFC designers 1) didn't understand OOP methodology
That's understandable. OOP methodology was not very well developed when MFC was first written. Retaining compatibility means that what they originally wrote had to be kept.
David Kentley wrote:
A reliance on macros to make their message mapping nonsense functional should have been a signal that they needed to START OVER and try again.
Aaaah. That one's easy to explain  . MFC was written before the MS compiler supported templates. I'd like to see you implement message maps without using macros or templates  . And once it was written, it had to be kept for compatibility reasons.
David Kentley wrote:
Why is CPropertySheet on a different branch of the class hierarchy chart than CDialog?
Because in the Win32 API, property sheets are not tabbed dialogs. They are completely separate. Sure, you could inherit CPropertySheet from CDialog, but you'd have to replace the entire behaviour of the class - not exactly a prime candidate for inheritance.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
Aaaah. That one's easy to explain . MFC was written before the MS compiler supported templates. I'd like to see you implement message maps without using macros or templates
Hmmm, how would you implement message maps with templates? AFAIK, WTL also uses macros for message maps. "OO aproach" would be to use some form of Observer pattern, but it would introduce some performance penalty.
|
|
|
|
|
Nemanja Trifunovic wrote:
Hmmm, how would you implement message maps with templates?
Using .NET-style delegates with functors. I'm in the middle of an article on this at the moment. Hopefully I'll have it finished in the next couple of days.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That's a good idea! Write an article on your C++ delegate. Then other people besides just the GUI Library group can use it.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
how do i get a cild windows position relative to its parents position?
in a dialog application
|
|
|
|
|
This code will retrieve the position of the child in client co-ordinates of the parent (i.e. top-left corner of the parent window is location 0,0).
CRect rc;
pChild->GetWindowRect( rc );
pChild->GetParent()->ScreenToClient( rc );
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
 Hey everyone I'm trying to write a dialog based program using MFC App Wizard and everything is going good but I need to have the program generate a notepad like window with text and a print and save option when the user clicks on a button. How do I do this? I was trying out WinExec ( "NOTEPAD.exe", SW_SHOWNORMAL ); but I cannot figure out how to send the text the user entered in the dialog window to the notepad. Please can someone help me out?
|
|
|
|
|
When you say "Notepad like window" do you mean that you are required to execute a seperate application like notepad? If so, I don't know how you can tell a given program to paste the text into a control.
If you just need the functionality of Notepad, create a second dialog within your app and just put a large edit control on that dialog. THen you can attach a menu to that dialog box with File...Save and File...Print.
You can use the common dialog boxes to do most of your work.
|
|
|
|
|
I just need the functionality of notepad. I'll try and add a second dialog to my app, but I've never done anything like that before, anyone know of any good step by step tutorials? I recent bought the book "Programming Windows with MFC" by Jeff Prosise, but I'm still having difficultly.
|
|
|
|
|
I am attempting to reindex my recordset. To do that, I'm issuing a pSet->m_strSort = "[Field]" command followed by a pSet->Requery() command. The requery command brings up a "Too few parameters. Expected (1)" error message. Does anyone know how that message may come about and the workaround for it? Thx,
Ralf.
|
|
|
|
|
It usually means you have something wrong in your query string. More than likely, you have mispelled a column name in your sort string.
Tony Fontenot
I love deadlines. I like the whooshing sound they make as they fly by.
-Douglas Adams
|
|
|
|
|
This usually happens as a result of an error in your DoFieldExchange function. As an example, if you're using parameters then m_nParams needs to be set to the correct number.
Cheers,
Tom Archer
Inside C#,
Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
|
I am ALMOST 100% sure that I used to be able to do this, but for quite some time now, if a variable is declared as static, I cannot view it in the watch window while debugging using VC6.
For example, in the following function:
void someclass::somefunc()
{
static BOOL beenhere = FALSE;
if (!beenhere) {
beenhere = TRUE;
}
}
While stepping through the program in debug mode, I cannot watch beenhere. I can watch any of the other variables, so long as they're not static.
Anyone else seen this? I don't use static variables very often, but it is very irritating in a few cases.
|
|
|
|
|
just move that static variable to your class and make it not static
|
|
|
|
|
Marissa182 wrote:
just move that static variable to your class and make it not static
That is the way I normally like to make things. But there are certain instances when a static variable is what seems to make the most sense.
Even so, though, it seems like a silly restriction to not be able to watch static variables. Has anyone else run into this, or is there something odd wrong with my installation?
|
|
|
|
|
Print in VC6 ?
I used ODBC (CDatabase,CRecordset) to open "Product" table in my database file >> and I want to print this table >>
Is there a way to print easily ?
and a question
these declarations are different ?
1) CMyClass o1,o2,o3;
2) CMyClass *p1,*p2,*p3;
which decleration is flexibler (fast run and use less memory)
when I should use a object like *p1 or o1
thank you very much![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
second point first...
2) only declares pointers to objects ... not objects themselves (just in case u didnt realise that) ... pointers to objects take less memory than the objects themselves but since the objects have to exist to get a pointer to them u actually have the object size + pointer size if u store a pointer to the objects ... i guess it depends on what u need to do with the objects and how u want to do it
printing in mfc (since ur using crecordset etc) is a tricky thing to get right ... there are lots of articles here on cp ... check out the 'printing' section
"there is no spoon"
biz stuff about me
|
|
|
|
|
Hi all
This is all plain vanilla C. So no wise ass C++ answers. Thanx.
typedef bool (*HANDLER)(void*,...);
Now is it possible to assign a "templated" function? Eg
bool expect(const char* str);
HANDLER HAHA = expect("HAHA");
What other options can I exercise? IOW I need to pass a pointer to a templated function pointer? But how?
CHeers
leppie::AllocCPArticle(Generic DFA State Machine for .NET);
|
|
|
|
|
|
Could someone EXPLAIN what the : operator is designed to do. The line of code I'm looking at is...
m_nBmihAlloc = ((hGlobal == NULL) ? crtAlloc : heapAlloc);
The specifics of this code shouldn't be important. I just want to know what the : is for.
Thanks to whomever can help.
JD
|
|
|
|
|
The operator is actually ? : , it's the only trinary (three-argument) operator in the C/C++ language. If the test before ? evaluates to true, the value of the statement is the expression on the left of :, if the test is false the value is on the right of :. The example code could also be written as:
if (hGlobal == NULL) {
m_nBmihAlloc = crtAlloc;
} else {
m_nBmihAlloc = heapAlloc;
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
