programming style for windows apps

[Todd Smith]

I'm wondering if anyone knows where I can learn a good programming
method for creating windows apps. I'm just starting to learn windows
programming with MSVC++ 6.0. I want to learn low level windows
programming in C first. I don't want to learn any bad habits by
hacking away at code until I get something to work.

Specifically, I'd like to learn how to set up and plan out a C windows
project and break it down into pieces of code that will be efficient
and in good style. A recomendation for website or book that teaches C
windows methodolgy would be good.

I hope the question was clear.

-thanks
-todd

[Mark A. Odell]

sm*****@auburn. edu (Todd Smith) wrote in
news:ed******** *************** ***@posting.goo gle.com:

I'm wondering if anyone knows where I can learn a good programming
method for creating windows apps. I'm just starting to learn windows
programming with MSVC++ 6.0. I want to learn low level windows
programming in C first. I don't want to learn any bad habits by
hacking away at code until I get something to work.

Specifically, I'd like to learn how to set up and plan out a C windows
project and break it down into pieces of code that will be efficient
and in good style. A recomendation for website or book that teaches C
windows methodolgy would be good.

I hope the question was clear.

Very. And very off-topic here. You seek a software engineering newsgroup
and one of the microsoft.* newsgroups. Please read the C-FAQ.

--
- Mark ->
--

[Malcolm]

"Todd Smith" <sm*****@auburn .edu> wrote in message

I'm wondering if anyone knows where I can learn a good programming
method for creating windows apps.

Windows programming isn't topical here but good style is.
For any program, you want to break the source down into logical units. For a
Windows program, an obvious unit is the Window.
Windows allows you to hang a pointer containing arbitrary data off each
window. Use this as something technically called an "object".

Eg, say you have a window which goes darker as you left click it, and
lighter as you right click it. It might be a control for ambient light level
in a game, for example.

You would define a structure

typedef struct
{
unsigned char level; /* light level 0-255 */
unsigned char prev; /* previous level (to implement a cancel) */
/* maybe more members here */
}LIGHTLEVEL;

Then in your windows procedure, the very first line retrieves this structure
from the window.

You then have a series of sub-functions to respond to messages. A "draw"
message would floodfill the window with grey of the appropriate colour.
Left-clicks and right clicks would cause the level to change and send a
redraw message. You might also want to respond to resize messages.

[Richard Heathfield]

Malcolm wrote:

"Todd Smith" <sm*****@auburn .edu> wrote in message

I'm wondering if anyone knows where I can learn a good programming
method for creating windows apps.
Windows programming isn't topical here but good style is.

Let's rephrase the question:

"I have a C function which accepts four parameters. It's a key routine, a
gateway into the whole program. The parameters convey information about an
incoming message, and I have tons of different messages to process. How can
I invoke the right bits of my program without making a complete pig's
breakfast of the program structure?"

I think that, put this way, it is very close to becoming a C question. YMMV.

For any program, you want to break the source down into logical units. For
a Windows program, an obvious unit is the Window.
Windows allows you to hang a pointer containing arbitrary data off each
window. Use this as something technically called an "object".
Well, I call it a pointer to struct, but yeah, this is good advice.
Eg, say you have a window which goes darker as you left click it, and
lighter as you right click it. It might be a control for ambient light
level in a game, for example.

You would define a structure

typedef struct
{
unsigned char level; /* light level 0-255 */
unsigned char prev; /* previous level (to implement a cancel) */
/* maybe more members here */
}LIGHTLEVEL;

Then in your windows procedure, the very first line retrieves this
structure from the window.

You then have a series of sub-functions to respond to messages. A "draw"
message would floodfill the window with grey of the appropriate colour.
Left-clicks and right clicks would cause the level to change and send a
redraw message. You might also want to respond to resize messages.

This is just about a perfect description of how I write Windows programs. I
would just add that I handle each message via a function with the same
prototype as the "standard" window procedure. This makes "message cracking"
very easy indeed. In fact, I use a macro to associate messages with
functions. My window procedures contain one physical line per message, plus
about half a dozen lines of overhead.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[pete]

Richard Heathfield wrote:

I would just add that I handle each message via a function
with the same prototype as the "standard" window procedure.
This makes "message cracking" very easy indeed.
In fact, I use a macro to associate messages with functions.
My window procedures contain one physical line per message,
plus about half a dozen lines of overhead.

I like an array of function pointers
for handling numbered messages.

--
pete

[Richard Heathfield]

pete wrote:

Richard Heathfield wrote:

I would just add that I handle each message via a function
with the same prototype as the "standard" window procedure.
This makes "message cracking" very easy indeed.
In fact, I use a macro to associate messages with functions.
My window procedures contain one physical line per message,
plus about half a dozen lines of overhead.

I like an array of function pointers
for handling numbered messages.

Now there's an idea. :-)

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Mike Wahler]

Richard Heathfield <in*****@addres s.co.uk.invalid > wrote in message
news:3f******@n ews2.power.net. uk...

pete wrote:

Richard Heathfield wrote:

I would just add that I handle each message via a function
with the same prototype as the "standard" window procedure.
This makes "message cracking" very easy indeed.
In fact, I use a macro to associate messages with functions.
My window procedures contain one physical line per message,
plus about half a dozen lines of overhead.

I like an array of function pointers
for handling numbered messages.

Now there's an idea. :-)

Until you actually look at the numerical values
of the e.g. MS Windows messages. The array would
be *very* large. :-)

-Mike

[Morris Dovey]

Mike Wahler wrote:

Richard Heathfield <in*****@addres s.co.uk.invalid > wrote in
message news:3f******@n ews2.power.net. uk...

pete wrote:

Richard Heathfield wrote:

I would just add that I handle each message via a
function with the same prototype as the "standard"
window procedure. This makes "message cracking" very
easy indeed. In fact, I use a macro to associate
messages with functions. My window procedures contain
one physical line per message, plus about half a dozen
lines of overhead.

I like an array of function pointers for handling numbered
messages.

Now there's an idea. :-)

Until you actually look at the numerical values of the e.g. MS
Windows messages. The array would be *very* large. :-)

But surely /never/ larger than 640K...
;-|

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Richard Heathfield]

Mike Wahler wrote:

Richard Heathfield <in*****@addres s.co.uk.invalid > wrote in message
news:3f******@n ews2.power.net. uk...

pete wrote:

> Richard Heathfield wrote:
>
>> I would just add that I handle each message via a function
>> with the same prototype as the "standard" window procedure.
>> This makes "message cracking" very easy indeed.
>> In fact, I use a macro to associate messages with functions.
>> My window procedures contain one physical line per message,
>> plus about half a dozen lines of overhead.
>
> I like an array of function pointers
> for handling numbered messages.

Now there's an idea. :-)

Until you actually look at the numerical values
of the e.g. MS Windows messages. The array would
be *very* large. :-)

Well, not necessarily. You could easily map them: unsigned int
MapMessageToFun ction(MESSAGE m); Having said that, it does become less
tempting if you have to do that, since that's basically what the switch
does anyway.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton