C / C++ / MFC

Re: Beginning MFC (Prosise) Part III - Now What? :: C++

2-Mar-02 9:12

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

rob bakes2-Mar-02 9:33

rob bakes

2-Mar-02 9:33

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.

Re: API

valikac2-Mar-02 10:19

2-Mar-02 10:19

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

Starting Over

valikac3-Mar-02 14:02

3-Mar-02 14:02

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

Re: Starting Over

Christian Graus3-Mar-02 14:12

Christian Graus

3-Mar-02 14:12

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.

Re: Starting Over

valikac3-Mar-02 15:55

Re: profiling...help me out?

3-Mar-02 15:55

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

profiling...help me out?

Roman Nurik1-Mar-02 12:22

Roman Nurik

1-Mar-02 12:22

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<<

pba_2-Mar-02 4:34

pba_

2-Mar-02 4:34

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.

DLL Export Table viewing question

RK_20001-Mar-02 11:25

RK_2000

1-Mar-02 11:25

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)

Re: DLL Export Table viewing question

Tomasz Sowinski1-Mar-02 11:32

WM_USER+1 vs RegisterWindowsMessage

1-Mar-02 11:32

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

alex.barylski1-Mar-02 11:10

1-Mar-02 11:10

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

Tomasz Sowinski1-Mar-02 11:15

1-Mar-02 11:15

Are you just creating some new control? Or it's something more complicated?

Tomasz Sowinski -- http://www.shooltz.com

alex.barylski1-Mar-02 11:29

1-Mar-02 11:29

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

Tomasz Sowinski1-Mar-02 11:34

1-Mar-02 11:34

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

alex.barylski1-Mar-02 12:16

1-Mar-02 12:16

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

Tomasz Sowinski1-Mar-02 12:23

1-Mar-02 12:23

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

alex.barylski1-Mar-02 14:25

1-Mar-02 14:25

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!

Smile | :)

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

Tomasz Sowinski2-Mar-02 1:31

2-Mar-02 1:31

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 Big Grin | :-D

Tomasz Sowinski -- http://www.shooltz.com

alex.barylski2-Mar-02 8:57

2-Mar-02 8:57

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

Michael Dunn1-Mar-02 11:36

Michael Dunn

1-Mar-02 11:36

It's your own control, so just use WM_USER. Message IDs used by other controls have no effect on yours.

--Mike--
Best score on the mini-putt game: 30
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.

alex.barylski1-Mar-02 12:02

1-Mar-02 12:02

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 Smile | :)

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

Tomasz Sowinski1-Mar-02 12:16

1-Mar-02 12:16

Message is handled by the control - so when it receives (WM_USER+n) it will know exactly what's going on.

Tomasz Sowinski -- http://www.shooltz.com

alex.barylski1-Mar-02 12:21

1-Mar-02 12:21

of course...duh...why didn't I see that in the first place...

The messages are internal to the parent and child classes (control). I think I finally got it...thanx

Cheers

Smile | :)

"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr