|
Imran Farooqui wrote:
And among many reasons of the popularity of JAVA this is also the one.
Did you say this with a straight face ? Popularity of Java amongst whom ? 
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
I mean that complexities involve in MFC and its HUGE learning curve are also some reason that many people looks towards JAVA. (Personally i dislike JAVA as I am a proud CPian). But if you ask one group of students to learn JAVA and other to learn MFC. Then after 6/7 months you give them a mini project. The group of people that learn Java will make this project much more quicker and easily than the people who are learning VC++.
Imran Farooqui
|
|
|
|
|
Imran Farooqui wrote:
But if you ask one group of students to learn JAVA and other to learn MFC
This is not a fair comparison. java is a programming language. MFC is a class library. Tell them to study java and c++, one for each group. or actually tell them all to study both. The ones who dont get good at C++ in 6 months would be bad anyway, so let them learn java 
Let the others then start with MFC or ATL or whatever
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
Imran Farooqui wrote:
And among many reasons of the popularity of JAVA this is also the one
Imran Farooqui wrote:
The main reason is the complexity of MFC and the absence of CodeDOM in VC++.
Java has CodeDOM????
I thought the better java programmers used emacs and linux. It was always the poor ones who used VJ++.
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
Thanks guys.
Christian Graus made a good point. He said, "C++ is a well designed language that is made to be non-restrictive, to leave the design to the programmer. MFC is a framework in which you need to do things the MFC way."
Is API programming *similar* to C++? I thinking the best way for me to learn windows programming is to approach it from *low-level*. In other words, I think I would master it if I can just start coding everything from scratch instead of using classes from MFC. I believe one reason I cannot understand all MFC classes and functions is because I do not know what *they actually do* and how. I am used to designing and implementing my own classes. I prefer to design my own classes for later use, like a personal C++ library. With MFC, I have to not only learn a huge framework of classes, but I have to follow a rule that the design have set. That is very limiting. I do not have problems with the framework. It is the vast number of classes in MFC that makes it difficult for me to see everything that is going on.
For example, I know class X handles a specific job. I can tell instantiate an object X or override class X, but I lack the knowledge of how things surrounding class X relate to it. Moreover, I do not know class X well enough to see its potential.
Kuphryn
P.S. I think I have to change track because I just cannot produce anything with MFC right now. Something has gone very wrong during the last two months of my studying from Prosise's. Part III of his book is about discusses topics beyond basics. So according to his agenda, I should be able to produce result by now.
So that leaves two choice: Jones' or API.
I will most likely try Jones' first. If that too leads me nowhere, then API will it is.
Kuphryn
|
|
|
|
|
Have a look at http://www.codeproject.com/wtl/
I found it easier to learn WTL than MFC first. With MFC I found it hard to get the bigger picture with all the wizards and generated code. WTL is smaller and simpler. I plan to learn MFC 7 though. Note I've only written some simple windows apps.
|
|
|
|
|
I looked at the API code at http://www.winprog.org/tutorial/ and I understood it easily. It looked just like the kind of C++ programming style that I use with my Win32 console programs.
This is weird. MFC code confuses me. There are too many intantiations and function calls. However, I have no idea what those objects and functions do.
I hear Petzold's API is the best. However, it is in C. What is the best *beginnger* API that emphasizes C++?
Thanks,
Kuphryn
|
|
|
|
|
I love C++. I love windows programming, but I just cannot get to a point where I feel confident solving problems and be able to implement the program as windows based.
I will still have hope of working with MFC. I believe I need to start from the beginner of MFC as when I was learning C++ (cout >> "Hello World." Again, MFC will not get any easier. My plan not rely on MFC become easier. Rather, I plan to be ready for MFC.
I decided to buy Richard Jones' introduction to MFC. I know Prosise
s book is the best. However, that does not mean it is the only way to learn MFC. For example, I believe Deitel&Deitel's C++ How to Program is the best book for learning C++. However, it was not the first book I read. By the time I read it, I was able to gain so many insights "advices" that they give because I understood the fundmentals of C++.
I will apply the same learning approach to MFC. I really should learn API first, but I feel MFC is very learnable. It is just that MFC is huge, and so I have trouble focusing and learning everything at once. For example, looking about at C++, I am impress with myself knowing C++ is itself huge. I learned C++ in two months.
Kuphryn
|
|
|
|
|
kuphryn wrote:
For example, looking about at C++, I am impress with myself knowing C++ is itself huge. I learned C++ in two months.
Completely ? Did you understand how iostreams work in that time ( so that you could write your own stream/stream handler for a new class ? Did you know enough about STL that you could write your own containers, iterators and algorithms ? If so, MFC would be a doddle - two weeks tops. If not, then you know what I mean, knowing a subset that makes you able to use a tool is not the same as knowing it, and the former is the cost of entry to start building the latter.
Good luck.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
No way. I did not know C++ competely in two months. That requires time, not because of learning, but because of experience. Experience takes time and effort.
I began programming using OOP in two months, including streams and container (linked list). No, I did not write my own iterators or algorithms (templates?).
Anyways, the coming weeks will the a challenge - one that will determine my future as a quality programmer. Lets do this!
Kuphryn
|
|
|
|
|
im trying to profile my app... i enabled profiling from the project->settings dialog and i did build->rebuild all. then when i tried build->profile, it gave me a PRF1011 saying that it couldnt find the PBO file
can someone explain to me how to fix this?
note: i'd rather not use the command line
>>Roman<<
|
|
|
|
|
Launch from the command line profile.exe and see which application is launched - VC profiling is supposed to work with profile.exe from VC/Bin directory. I've got the same message because the VC was trying to use profile.exe from PlatformSDK / bin / winnt.
|
|
|
|
|
Hi there,
in Winnt, if my recollections hold correctly, if you would right click on a DLL, there was an option to view its export tables and details. Is there an equivalent way or a command that would give you the same option in 2000 or other Microsoft operating systems? (i.e. this is without using the any VS tools)
|
|
|
|
|
I'm not quite sure about that, but this feature may have been implemented using QuickView. Since QV is gone in 2K and later, you're out of luck. Without Depends.exe or other 3rd party app you'll be unable to check imports/exports.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
How can you tell i'm going off on a big message spree?
Anyways...which would be better suited for cross-object communication?
WM_USER is just a define so this seems rather ummm...the crappier of the two approaches. Whats to stop someone from using the exact same WM_USER+1 and now we have conflicting messages...?
RegisterWindowsMessage is much better here becuz it generates unique message numbers, however would need to be stored in a variable somewhere (global) so more than just the class that registered it could use it...
Am I right here...?
So i'm confused...should I use a global with namespace, just WM_USER constants...or local member data and have accessor/mutators for the message...?
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Are you just creating some new control? Or it's something more complicated?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Control from scratch CWnd with multiple child windows.
No IPC or anything, just in process.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
HockeyDude wrote:
Control from scratch CWnd with multiple child windows.
So WM_USER+n will do. And - if you're going to consume the control in MFC apps only - you can abandon message-based communications and use C++ methods instead.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Member functions instead of messages...I dunno if that would be the best solution for the task at hand.
I have parent window and a child window
the child window re-directs it messages to the parent for processing WM_PAINT and so on. for the child to call the parents...i would need to perform upcasts wouldn't I...?
This would be more expensive in CPU time cuz it uses RTTI instead of just sending messages correct..? I know sending messages is the easier route.
I almost have to go the message way...
Thanx
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I'm assuming you're creating a complex control - the one with multiple children hosted in one window. If parent has to take care about painting children, why don't you create a method in the parent called PaintChild and call from within WM_PAINT handler in child window? You don't really need to go low-level and play with messages - with MFC you just don't need to do that.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
CParent::OnDrawView(CDC* pDC) is mapped to WM_DRAWVIEW message, which is sent in the CChild WM_PAINT message.
I could call OnDrawView(CDC* pDC) from the childs WM_PAINT handler, but OnDrawView is protected, not public and it would require and upcast i'm sure, which probably has bigger penalties than ::SendMessage().
Using message maps with protected member functions seem to make for more OOP friendly code I thought. As far as CPU expense is concerned. Even if RTTI used in performing upcasts (which i think is required) doesn't consume more clocks it's harder to program and understand. ::SendMessage is simple.
These are my reasons for designing this way...am I missing something...?
Thanx again!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Do not map OnDrawView to any messages. Just call it directly. If your children are designed to live only inside your own parent, you can safely use static_cast to get the right pointer:
// in CDudeChild::OnPaint
static_cast<cdudeparent *="">(GetParent())->DrawView(dc);
static_cast is a compile-time construct, it does not cause any performance penalty. Even if you use dynamic_cast instead, it'll be faster than sending message - MFC has to walk through message maps to find the handler. If you're still concerned with every nanosecond (which is a mistake - look for perf improvements where it really matters), you can keep a pointer to CDudeParent in CDudeChild.
My general feeling is that you've spent too much time coding Win32 apps over raw SDK 
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Tomasz Sowinski wrote:
static_cast(GetParent())->DrawView(dc);
Your absolutely right...only I think I did it like:
((CMyView*)m_pParent)->OnDrawView();
which are the exact same thing I guess, only static_cast is more explicit I would assume.
However, the reason I must use messages was not just for performance. Trying to keep the 2 classes as versatile and re-useable as possible...calling the member functions directly would kinda break this general rule of thumb wouldn't it...?
But mostly...I absolutely have too...cuz...well OnDrawView is a protected member function.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
|
I don't see how this is possible, i'm missing something here.
If I had:
#define WM_CUSTOMMSG WM_USER+1
class MyClass
{
MyClass(){ }
...and so on
};
BEGIN_MESSAGE_MAP(CView, MyClass)
ON_MESSAGE(WM_CUSTOMMSG, OnCustomHandler)
END_MESSAGE_MAP
If I included this control as well as a third party control which by chance did the exact same thing
WM_USER+1, how would the two seperate, but equal #defines not clash...???
if the WndProc was like this:
WndProc()
{
switch(nMsg)
{
case WM_MYMSG;
break;
case WM_YOURMSG:
break;
}
}
This is why i'm confused...if my app had 2 seperate libs which both did the WM_USER+1 how would my app be able to distinguish which message was really sent...?
Thanx Mike
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
