C / C++ / MFC

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

Tim Smith1-Mar-02 12:51

Tim Smith

1-Mar-02 12:51

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

Don't you just hate when that happens.

Some days the "Obvious Bus" could be parked in front of my house with a beeping horn and I would still miss it.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Michael Dunn1-Mar-02 12:21

Michael Dunn

1-Mar-02 12:21

I don't see what you're asking. Your CWnd-based control (which is entirely under your control (sorry, can't think of a better wording)) can handle any WM_USER+n messages it likes. That is totally unaffected by other controls in the program.
For instance, your app can send WM_USER+1 to your control for one thing, and send SB_SETTEXT (which is WM_USER+1) to a status bar (a totally different control) with no problems.

--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 14:17

Brief & Epsilon emulation in VisStudio.Net?

1-Mar-02 14:17

Hey Mike...thanx for helping me clear that up.

I've got it figured out now...i dunno why it wasn't sinking in...

Thanx again!

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

1-Mar-02 11:10

What happened to Brief and Epsilon editor emulation? Were they
completely removed from VS.NET?

PreTranslateMessage

alex.barylski1-Mar-02 9:34

1-Mar-02 9:34

I'm little blurry about the purpose of PreTranslateMessage so can someone clear it up for me if i'm wrong.

This function allows you to basically emulate the message pump of an SDK program...?

while(GetMessage(&msg, NULL, 0, 0))
{
  TranslateMessage(&msg);
  DispatchMessage(&msg);
}

is basically:

CMyView::PreTranslateMessage(MSG* pMsg)
{
  //You can use this function to dispatch messages to the 
  //proper window or ignore them them altogather
  //Is the following possible
  if(pMsg->message == WM_PAINT)
  {
    if(pMsg->lParam == 1000) //User-defined message
      //Change the message struct attribs a little
    else
      //Ignore the message altogather
  }
}

Do I call DispatchMessage directly from with the PreTranslateMessage() or do I call the default CView::PreTranslateMessage()

Can I change the message a little before sending it off to WndProc...?

Basically in the above code i'm trying to accomplish the following:

1) WM_PAINT message received THEN
2) Check lParam for user-defined value
3) if lParam==VALUE THEN
Change DC to another DC
else
Prevent message from getting to WndProc.

I think WM_PAINT actually can't be stopped until BeginPaint is called, which will remove it from the queue.

I hope I was clear on the effect I am after and I hope even more that someone understands me and can offer suggestions or advice.

Thanx!

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

Re: PreTranslateMessage

Paul M Watt1-Mar-02 10:12

Paul M Watt

1-Mar-02 10:12

Your code segment would work, and yes you could change the message a little, not send it forward at all, or even change the message itself to something entirely different. The main issue is making sure that people who may want to use your class or control in the future understand the behavior.

I should also say, that it is not very wise to send your own WM_PAINT messages, if this is how you intend on getting the user defined value in the lParam. Maybe create your own user defined paint message.

HockeyDude wrote:
I think WM_PAINT actually can't be stopped until BeginPaint is called, which will remove it from the queue.

If you want to stop WM_PAINT message from being sent, you can simply call ValidateRect(hWnd, NULL). WM_PAINT messages are not really entered into the message queue, GetMessage or PeekMessage for that matter will send a WM_PAINT message directly to the target window only when there are no other posted messages left in the message queue.

If you call ValidateRect(hWnd, NULL) after you have performed the painting that you are interested in, then a WM_PAINT message will never be generated.

Re: PreTranslateMessage

alex.barylski1-Mar-02 10:36

1-Mar-02 10:36

Thanx again Kilo.

I've only re-designed the friggen thing about 6 times now...each time it gets better and better naturally.

I always get so far, only to realize it's not possible... Cry | :((

But I think of a better and possibly easier way of doing things. I'm really trying to keep the control packaged nicely, not so much in fear of anyone using my class, but just for the experience. It's easier for me to use also.

It's this one hurdle that is stopping me in my tracks time and time again, causing me to re-think and re-design.

The parent class I want to do all the drawing, but it already draws the control, so any overriden OnDraw will stomp on the control UI. I thought i'd fix this problem by creating a child window which would also provide clipping, whenever the child gets WM_PAINT it would re-direct it to the parent...and i'd use OnErase for the control appearance UI. The approach which I (think) finally decided on, which is IMO Smile | :)

is the best approach, is to just use another virtual function like CParent::OnDrawView() which will respond to the custom message WM_DRAWVIEW sent inside the child's ON_PAINT with the childs CDC* as well

This way drawing can still be done with a virtual function of the parent class. Only problem i'm having now Poke tongue | ;-P

Is how to map a custom message...?

And should I use WM_USER+1 or RegisterWindowsMessage()

Thanx again!

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

Re: PreTranslateMessage

alex.barylski1-Mar-02 10:45