Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11168 > unrolled thread

Style question - calling default from several places

Back to article view | Back to comp.lang.c++

Contents

  Style question - calling default from several places Paul N <gw7rib@aol.com> - 2011-10-31 13:27 -0700
    Re: Style question - calling default from several places Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-10-31 22:15 +0100
      Re: Style question - calling default from several places Paul N <gw7rib@aol.com> - 2011-11-01 15:25 -0700
        Re: Style question - calling default from several places Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-11-02 08:16 +0100
    Re: Style question - calling default from several places Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-01 11:44 +0000
      Re: Style question - calling default from several places Victor Bazarov <v.bazarov@comcast.invalid> - 2011-11-01 10:02 -0400
        Re: Style question - calling default from several places Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-02 03:25 +0000
          Re: Style question - calling default from several places Victor Bazarov <v.bazarov@comcast.invalid> - 2011-11-02 08:35 -0400
            Re: Style question - calling default from several places Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-03 18:32 +0000
    Re: Style question - calling default from several places jgk@panix.com (Joe keane) - 2011-11-03 15:46 +0000

#11168 — Style question - calling default from several places

I have a style question. In my code, I have a function that receives
messages, and deals with some of them while passing others on to a
further function. For instance:

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam)
{

  switch (message) {
    case WM_CREATE:
   // stuff here
  default:
    return DefWindowProc(hWnd, message, wParam, lParam); } }

Now, some of the other messages require me, in some circumstances, to
also pass the message on to DefWindowProc either after, or instead of,
dealing with it in my function. Obviously one way to do this is to
simply call DefWindowProc there as well. But I was wondering if there
was a neater way. One way would be to use a goto; a second way would
be to set a flag if I want DefWindowProc to be called and then have

if (flag) DefWindowProc(...)

after the switch. Possibly there's also a way, like Duff's device,
using big "if"s that span the case labels... Anyhow, would anyone
recommend any of these techniques, or are there any other alternatives
I've missed?

Thanks for any thoughts.
Paul.

[toc] | [next] | [standalone]

#11169

On 31.10.2011 21:27, Paul N wrote:
> LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
> LPARAM lParam)
> {
>
>    switch (message) {
>      case WM_CREATE:
>     // stuff here
>    default:
>      return DefWindowProc(hWnd, message, wParam, lParam); } }
>
> Now, some of the other messages require me, in some circumstances, to
> also pass the message on to DefWindowProc either after, or instead of,
> dealing with it in my function.

Typical problem of the old style window procedures with daisy chained 
handlers.


> Obviously one way to do this is to
> simply call DefWindowProc there as well. But I was wondering if there
> was a neater way.

    switch (message) {
      case WM_CREATE:
        // stuff here
        break;
      case WM_COMMAND:
        // stuff here
        return 0;
    }
    return DefWindowProc(hWnd, message, wParam, lParam);


Marcel

[toc] | [prev] | [next] | [standalone]

#11182

On Oct 31, 9:15 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
> On 31.10.2011 21:27, Paul N wrote:
>
> > LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
> > LPARAM lParam)
> > {
>
> >    switch (message) {
> >      case WM_CREATE:
> >     // stuff here
> >    default:
> >      return DefWindowProc(hWnd, message, wParam, lParam); } }
>
> > Now, some of the other messages require me, in some circumstances, to
> > also pass the message on to DefWindowProc either after, or instead of,
> > dealing with it in my function.
>
> > Obviously one way to do this is to
> > simply call DefWindowProc there as well. But I was wondering if there
> > was a neater way.
>
>     switch (message) {
>       case WM_CREATE:
>         // stuff here
>         break;
>       case WM_COMMAND:
>         // stuff here
>         return 0;
>     }
>     return DefWindowProc(hWnd, message, wParam, lParam);

Thanks Marcel. This is indeed a different way of doing it. The snag is
that, at present, most of the cases end in "break" and then end up at
a "return 0;" after the switch. To make the change I would have to
change every one of them - and then remember to do the same for any
new cases I added later. Which seems a bit of a high risk of me
messing it up. But I'll give it a bit more consideration.

Paul.

[toc] | [prev] | [next] | [standalone]

#11188

On 01.11.2011 23:25, Paul N wrote:
> Thanks Marcel. This is indeed a different way of doing it. The snag is
> that, at present, most of the cases end in "break" and then end up at
> a "return 0;" after the switch. To make the change I would have to
> change every one of them - and then remember to do the same for any
> new cases I added later. Which seems a bit of a high risk of me
> messing it up. But I'll give it a bit more consideration.

It's your choice.

I prefer to pass any complicated message processing to a dedicated and 
strongly typed, private member function. This keeps the message 
procedure small and clear. Furthermore this often ends up with something 
like
   return MyXYHandler((int)mp1, (bool)mp2);

Of course, other handlers may return void and you still need the return 
0 to keep the compiler happy.


Marcel

[toc] | [prev] | [next] | [standalone]

#11177

On Mon, 2011-10-31, Paul N wrote:
> I have a style question. In my code, I have a function that receives
> messages, and deals with some of them while passing others on to a
> further function. For instance:
>
> LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
> LPARAM lParam)
> {

Speaking of style, one easy way of increasing readability would be to
give meaningful names to those types, those parameters, and that
function.  They may not be under your control, but I have to say they
are among the worst I've seen.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#11178

On 11/1/2011 7:44 AM, Jorgen Grahn wrote:
> On Mon, 2011-10-31, Paul N wrote:
>> I have a style question. In my code, I have a function that receives
>> messages, and deals with some of them while passing others on to a
>> further function. For instance:
>>
>> LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
>> LPARAM lParam)
>> {
>
> Speaking of style, one easy way of increasing readability would be to
> give meaningful names to those types, those parameters, and that
> function.  They may not be under your control, but I have to say they
> are among the worst I've seen.

For those who don't dabble in Windows API and messaging: the meaning of 
'wParam' and 'lParam' varies widely depending on the _value_ of 
'message'.  Hence the generic names.  It's been like this for some 
thirty years, and I have never seen anybody manage to improve on that 
much, or even enough for a mention.  Some frameworks, like MFC, attempt 
to lay out some structure over that system, and not totally 
unsuccessfully, methinks, but for a generic message handler like the one 
described by the OP there is no real hope.  Perhaps the OP should look 
into using one of those frameworks...

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#11185

On Tue, 2011-11-01, Victor Bazarov wrote:
> On 11/1/2011 7:44 AM, Jorgen Grahn wrote:
>> On Mon, 2011-10-31, Paul N wrote:
>>> I have a style question. In my code, I have a function that receives
>>> messages, and deals with some of them while passing others on to a
>>> further function. For instance:
>>>
>>> LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
>>> LPARAM lParam)
>>> {
>>
>> Speaking of style, one easy way of increasing readability would be to
>> give meaningful names to those types, those parameters, and that
>> function.  They may not be under your control, but I have to say they
>> are among the worst I've seen.
>
> For those who don't dabble in Windows API and messaging: the meaning of 
> 'wParam' and 'lParam' varies widely depending on the _value_ of 
> 'message'.  Hence the generic names.  It's been like this for some 
> thirty years, and I have never seen anybody manage to improve on that 
> much, or even enough for a mention.  Some frameworks, like MFC, attempt 
> to lay out some structure over that system, and not totally 
> unsuccessfully, methinks, but for a generic message handler like the one 
> described by the OP there is no real hope.  Perhaps the OP should look 
> into using one of those frameworks...

I've never used these APIs (obviously) but I think I would break out
of the crazy world of UINT and void* (if that is what's behind WPARAM
and LPARAM) as soon as possible.  I.e. call my own functions with more
specific types as soon as I see what the callback is about.

The inner structure (or lack thereof) of WndProc() seems less important.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#11198

On 11/1/2011 11:25 PM, Jorgen Grahn wrote:
> On Tue, 2011-11-01, Victor Bazarov wrote:
>> On 11/1/2011 7:44 AM, Jorgen Grahn wrote:
>>> On Mon, 2011-10-31, Paul N wrote:
>>>> I have a style question. In my code, I have a function that receives
>>>> messages, and deals with some of them while passing others on to a
>>>> further function. For instance:
>>>>
>>>> LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam,
>>>> LPARAM lParam)
>>>> {
>>>
>>> Speaking of style, one easy way of increasing readability would be to
>>> give meaningful names to those types, those parameters, and that
>>> function.  They may not be under your control, but I have to say they
>>> are among the worst I've seen.
>>
>> For those who don't dabble in Windows API and messaging: the meaning of
>> 'wParam' and 'lParam' varies widely depending on the _value_ of
>> 'message'.  Hence the generic names.  It's been like this for some
>> thirty years, and I have never seen anybody manage to improve on that
>> much, or even enough for a mention.  Some frameworks, like MFC, attempt
>> to lay out some structure over that system, and not totally
>> unsuccessfully, methinks, but for a generic message handler like the one
>> described by the OP there is no real hope.  Perhaps the OP should look
>> into using one of those frameworks...
>
> I've never used these APIs (obviously) but I think I would break out
> of the crazy world of UINT and void* (if that is what's behind WPARAM
> and LPARAM) as soon as possible.  I.e. call my own functions with more
> specific types as soon as I see what the callback is about.

That's exactly what those (MFC et al.) frameworks do.  They define their 
own generic handler and inside they have a rather large and convoluted 
switch statement to dispatch the message to specific handlers that are 
all declared with more specific types of arguments with more meaningful 
names and often re-wrapped into more specific values of more meaningful 
types (both Windows-SDK-defined and newly introduced by those frameworks).

> The inner structure (or lack thereof) of WndProc() seems less important.

Well, "WndProc" has been the workhorse of the Windows messaging API, and 
it's how we all used to write Windows applications before those complete 
frameworks came to be.  It's primitive.  It's simplistic.  It gets the 
job done.  Keep in mind, Windows was running on a personal computer, in 
real memory mode...  As for programming, it was often recommended to 
write your own class framework, but the basis was still the WndProc 
functions (which you had to introduce in order to tie into Windows UI, 
etc.)  Absence of structure was not a concern at all because the purpose 
was clear and the method was simple to grasp and easy to follow AFA 
implementation goes.  Besides, there were so many examples, and they all 
looked very similar to what Charles Petzold put in his book^.

But I have digressed...

V

^ - Programming Windows by Charles Petzold, Microsoft Press, 1988.
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#11247

On Wed, 2011-11-02, Victor Bazarov wrote:
> On 11/1/2011 11:25 PM, Jorgen Grahn wrote:
>> On Tue, 2011-11-01, Victor Bazarov wrote:
...
>> The inner structure (or lack thereof) of WndProc() seems less important.
>
> Well, "WndProc" has been the workhorse of the Windows messaging API, and 
> it's how we all used to write Windows applications before those complete 
> frameworks came to be.  It's primitive.  It's simplistic.  It gets the 
> job done.
...
> Absence of structure was not a concern at all because the purpose 
> was clear and the method was simple to grasp and easy to follow AFA 
> implementation goes.  Besides, there were so many examples, and they all 
> looked very similar to what Charles Petzold put in his book^.

Fair enough. I didn't recognize this as a core Windows thing. The OP
didn't say, so I assumed it was forced upon him by some less
well-known API.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#11241

int xxx(...)
{
    ...

    switch (op)
    {
      case OP_A:
	...
	goto dontcallfunc;

      case OP_B:
	...
	goto docallfunc;

      case OP_C:
	...
	goto dontcallfunc;

      case OP_D:
	...
	goto docallfunc;

      default:
	...
	goto docallfunc;
    }

    abort();

  dontcallfunc:
    ret = ...;
    goto done;

  docallfunc:
    ret = func(...);
    goto done;

  done:
    ...
    return ret;
}

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web