Adam Messer wrote:

> Hello all,
>
> I am a fairly new Windows programmer. I am writing a program
> to remote control some A/V equipment. The way I decided to implement
> my interface is to use a BMP image of a universal remote control. I am
> using Visual Studio 6 with C++ and MFC in a dialog application.
>
> I have gone through the trouble to get the coordinates of
> every button on the remote control. By capturing the left button click
> message I am able to determine which button was under the mouse when
> it is clicked. I want visual feedback when a button is clicked, and
> here is what I am doing to get it.
>
> 1) I find all the 'fairly white' pixels within the button region and
> paint them a bright yellow to make it look like the button lights when
> clicked.
>
> 1a) Many of my buttons are not rectangular and there is black writing
> on each button. That is why I can't simply paint all pixels in my
> rectangles.
>
> 2) After about 1/2 second I change the color of the yellow pixels back
> to a 'standard white' color.
>
> 3) I am using the SetPixelV method to set the colors of the buttons.
>
>
> When I say 'fairly white', I mean all pixels who's RGB values fall
> into a range that look white. SInce I took a picture of my remote
> control instead of drawing it within my application, the colors vary a
> lot, so I can't simply do a flood fill. The color of the buttons and
> the surrounding areas are not consistent.
>
> This is obviously a very inefficient way to accomplish my task. There
> is one button called 'light' on my remote. When I click on it the
> whole keypad is supposed to light up for a few seconds. It takes so
> long to write all the pixels, one by one, that it looks like a yellow
> wave slowly washes across my remote control.
>
> The way I see it I have two choices. 1) I can go into some sort of
> graphics program (i.e. Photoshop) and 'fix up' the remote control
> image file. 2) I can set all 'fairly white' pixels to a consistent
> white when my application initializes. I can then use a flood fill
> when a button is clicked which should be much faster.
>
> Here is my problem. The method I am using to write directly into the
> device context doesn't work if my application gets re-painted. All the
> colors revert back to their defaults. If some kind sole out there
> could clue me in on a way to change the colors that would remain
> changed after a re-paint, I would be forever grateful!
>
> Please forgive me if my terminology isn't very good, but I am an OS
> programmer, not a UI or graphics programmer. These Win32 and MFC
> concepts and terms are fairly new to me.
>
> TIA,
> Adam Messer
> amesser39@hotmail.com
>

To solve the re-paint problem you have to separate the button click and
the painting into two steps. When the button is clicked just set some
variables to remember which button(s) are active and call Invalidate()
or InvalidateRect(). Don't paint in the click handler. Almost
immediately after that you will receive WM_PAINT. Paint in the WM_PAINT
handler. If your application needs repainting you will also receive
WM_PAINT, so you have to do all painting, from all causes, in WM_PAINT,
using variables to remember exactly what to paint.

To improve the efficiency of the flash effect you should have a second
bitmap or bitmaps, with the buttons illuminated. When you paint, first
blit the standard bitmap into the CDC, then blit illuminated buttons
onto that from the second bitmap, then blit the composite to the screen.
If you don't know how to do this look up examples that use
CreateCompatibleDC, which is an in-memory bitmap where you prepare the
composite. This will be enormously faster than SetPixel.

Similarly, when your timer says it is time to remove the flash, don't
paint, just change the variables and call Invalidate or InvalidateRect
to generate another WM_PAINT.

--
Scott McPhillips [VC++ MVP]

Scott,

Thank you for the advice. I will take a look an see if I can
do what you suggest.

Thanks again,
Adam

On Sat, 28 Feb 2004 09:12:59 -0500, "Scott McPhillips [MVP]"
wrote:

>Adam Messer wrote:
>
>> Hello all,
>>
>> I am a fairly new Windows programmer. I am writing a program
>> to remote control some A/V equipment. The way I decided to implement
>> my interface is to use a BMP image of a universal remote control. I am
>> using Visual Studio 6 with C++ and MFC in a dialog application.
>>
>> I have gone through the trouble to get the coordinates of
>> every button on the remote control. By capturing the left button click
>> message I am able to determine which button was under the mouse when
>> it is clicked. I want visual feedback when a button is clicked, and
>> here is what I am doing to get it.
>>
>> 1) I find all the 'fairly white' pixels within the button region and
>> paint them a bright yellow to make it look like the button lights when
>> clicked.
>>
>> 1a) Many of my buttons are not rectangular and there is black writing
>> on each button. That is why I can't simply paint all pixels in my
>> rectangles.
>>
>> 2) After about 1/2 second I change the color of the yellow pixels back
>> to a 'standard white' color.
>>
>> 3) I am using the SetPixelV method to set the colors of the buttons.
>>
>>
>> When I say 'fairly white', I mean all pixels who's RGB values fall
>> into a range that look white. SInce I took a picture of my remote
>> control instead of drawing it within my application, the colors vary a
>> lot, so I can't simply do a flood fill. The color of the buttons and
>> the surrounding areas are not consistent.
>>
>> This is obviously a very inefficient way to accomplish my task. There
>> is one button called 'light' on my remote. When I click on it the
>> whole keypad is supposed to light up for a few seconds. It takes so
>> long to write all the pixels, one by one, that it looks like a yellow
>> wave slowly washes across my remote control.
>>
>> The way I see it I have two choices. 1) I can go into some sort of
>> graphics program (i.e. Photoshop) and 'fix up' the remote control
>> image file. 2) I can set all 'fairly white' pixels to a consistent
>> white when my application initializes. I can then use a flood fill
>> when a button is clicked which should be much faster.
>>
>> Here is my problem. The method I am using to write directly into the
>> device context doesn't work if my application gets re-painted. All the
>> colors revert back to their defaults. If some kind sole out there
>> could clue me in on a way to change the colors that would remain
>> changed after a re-paint, I would be forever grateful!
>>
>> Please forgive me if my terminology isn't very good, but I am an OS
>> programmer, not a UI or graphics programmer. These Win32 and MFC
>> concepts and terms are fairly new to me.
>>
>> TIA,
>> Adam Messer
>> amesser39@hotmail.com
>>
>
>To solve the re-paint problem you have to separate the button click and
>the painting into two steps. When the button is clicked just set some
>variables to remember which button(s) are active and call Invalidate()
>or InvalidateRect(). Don't paint in the click handler. Almost
>immediately after that you will receive WM_PAINT. Paint in the WM_PAINT
>handler. If your application needs repainting you will also receive
>WM_PAINT, so you have to do all painting, from all causes, in WM_PAINT,
>using variables to remember exactly what to paint.
>
>To improve the efficiency of the flash effect you should have a second
>bitmap or bitmaps, with the buttons illuminated. When you paint, first
>blit the standard bitmap into the CDC, then blit illuminated buttons
>onto that from the second bitmap, then blit the composite to the screen.
> If you don't know how to do this look up examples that use
>CreateCompatibleDC, which is an in-memory bitmap where you prepare the
>composite. This will be enormously faster than SetPixel.
>
>Similarly, when your timer says it is time to remove the flash, don't
>paint, just change the variables and call Invalidate or InvalidateRect
>to generate another WM_PAINT.

Scott,

I thought a little more about what you said, and I have two
things to say. First, I already separate the click from the drawing,
but not the way you mean. I know I should not do anything that blocks
in the message pump loop, so I have a thread that does the painting of
the buttons. The button response code simply tells the thread what
burton to draw. This is necessary because I want to draw a button one
color, then revert its color back in about 1/2 second. I know that you
mean for me to do my drawing when I get the pain message. The MSVC
application expert creates a paint method for dialogs, but does
nothing except invoke the super class's draw method. I have never put
code in the draw method and am not exactly sure how to determine what
I need to redraw. Even if I could it still presents a problem for me.i
would still have to have the code the repaints a pure white over all
my buttons get called every time I get the pain message. This in
addition to changing the color to yellow and back each time a button
is clicked. I don't know how much it would really buy me to do the
repaint when I get the message, eve though that is the right place to
do it. One thing I would really like to do is to be able to change the
button colors to a pure white color once at startup, and flood fill
the button that gets pressed. I will think about your suggestions more
though.

Thanks again,
Adam

On Sat, 28 Feb 2004 09:12:59 -0500, "Scott McPhillips [MVP]"
wrote:

>Adam Messer wrote:
>
>> Hello all,
>>
>> I am a fairly new Windows programmer. I am writing a program
>> to remote control some A/V equipment. The way I decided to implement
>> my interface is to use a BMP image of a universal remote control. I am
>> using Visual Studio 6 with C++ and MFC in a dialog application.
>>
>> I have gone through the trouble to get the coordinates of
>> every button on the remote control. By capturing the left button click
>> message I am able to determine which button was under the mouse when
>> it is clicked. I want visual feedback when a button is clicked, and
>> here is what I am doing to get it.
>>
>> 1) I find all the 'fairly white' pixels within the button region and
>> paint them a bright yellow to make it look like the button lights when
>> clicked.
>>
>> 1a) Many of my buttons are not rectangular and there is black writing
>> on each button. That is why I can't simply paint all pixels in my
>> rectangles.
>>
>> 2) After about 1/2 second I change the color of the yellow pixels back
>> to a 'standard white' color.
>>
>> 3) I am using the SetPixelV method to set the colors of the buttons.
>>
>>
>> When I say 'fairly white', I mean all pixels who's RGB values fall
>> into a range that look white. SInce I took a picture of my remote
>> control instead of drawing it within my application, the colors vary a
>> lot, so I can't simply do a flood fill. The color of the buttons and
>> the surrounding areas are not consistent.
>>
>> This is obviously a very inefficient way to accomplish my task. There
>> is one button called 'light' on my remote. When I click on it the
>> whole keypad is supposed to light up for a few seconds. It takes so
>> long to write all the pixels, one by one, that it looks like a yellow
>> wave slowly washes across my remote control.
>>
>> The way I see it I have two choices. 1) I can go into some sort of
>> graphics program (i.e. Photoshop) and 'fix up' the remote control
>> image file. 2) I can set all 'fairly white' pixels to a consistent
>> white when my application initializes. I can then use a flood fill
>> when a button is clicked which should be much faster.
>>
>> Here is my problem. The method I am using to write directly into the
>> device context doesn't work if my application gets re-painted. All the
>> colors revert back to their defaults. If some kind sole out there
>> could clue me in on a way to change the colors that would remain
>> changed after a re-paint, I would be forever grateful!
>>
>> Please forgive me if my terminology isn't very good, but I am an OS
>> programmer, not a UI or graphics programmer. These Win32 and MFC
>> concepts and terms are fairly new to me.
>>
>> TIA,
>> Adam Messer
>> amesser39@hotmail.com
>>
>
>To solve the re-paint problem you have to separate the button click and
>the painting into two steps. When the button is clicked just set some
>variables to remember which button(s) are active and call Invalidate()
>or InvalidateRect(). Don't paint in the click handler. Almost
>immediately after that you will receive WM_PAINT. Paint in the WM_PAINT
>handler. If your application needs repainting you will also receive
>WM_PAINT, so you have to do all painting, from all causes, in WM_PAINT,
>using variables to remember exactly what to paint.
>
>To improve the efficiency of the flash effect you should have a second
>bitmap or bitmaps, with the buttons illuminated. When you paint, first
>blit the standard bitmap into the CDC, then blit illuminated buttons
>onto that from the second bitmap, then blit the composite to the screen.
> If you don't know how to do this look up examples that use
>CreateCompatibleDC, which is an in-memory bitmap where you prepare the
>composite. This will be enormously faster than SetPixel.
>
>Similarly, when your timer says it is time to remove the flash, don't
>paint, just change the variables and call Invalidate or InvalidateRect
>to generate another WM_PAINT.

Adam Messer wrote:
> Scott,
>
> I thought a little more about what you said, and I have two
> things to say. First, I already separate the click from the drawing,
> but not the way you mean. I know I should not do anything that blocks
> in the message pump loop, so I have a thread that does the painting of
> the buttons. The button response code simply tells the thread what
> burton to draw. This is necessary because I want to draw a button one
> color, then revert its color back in about 1/2 second. I know that you
> mean for me to do my drawing when I get the pain message. The MSVC
> application expert creates a paint method for dialogs, but does
> nothing except invoke the super class's draw method. I have never put
> code in the draw method and am not exactly sure how to determine what
> I need to redraw. Even if I could it still presents a problem for me.i
> would still have to have the code the repaints a pure white over all
> my buttons get called every time I get the pain message. This in
> addition to changing the color to yellow and back each time a button
> is clicked. I don't know how much it would really buy me to do the
> repaint when I get the message, eve though that is the right place to
> do it. One thing I would really like to do is to be able to change the
> button colors to a pure white color once at startup, and flood fill
> the button that gets pressed. I will think about your suggestions more
> though.
>
> Thanks again,
> Adam

If my suggestions seem strange, it is because in Windows you can blit a
bitmap hundreds or thousands of times faster then you can flood fill
with SetPixel. SetPixel is so slow that you were forced to introduce a
thread. The thread would be unnecessary if you had highlighted bitmaps
of the buttons available and blit one of them to change a button's
appearance. Avoid SetPixel, except perhaps during one-time
initialization if you prefer to prepare the bitmaps in memory instead of
by adding a bitmap resource.

And putting all the drawing code in WM_PAINT is fundamental to any
well-behaved Windows GUI. It makes minimize/restore possible and it
supports the illusion that one window can "uncover" another.

--
Scott McPhillips [VC++ MVP]

Scott,

I really do understand what you are saying. Anytime you can
make one (or a few) calls and get the drive to do all the work within
the system, you are way, way better off. The reason I have a separate
thread is not because of the time of setting a color, its the fact
that I want to have the new color stay for about 1/2 second, then get
reset.

The flood-fill operation is a driver call. I don't mean to
insinuate that I can flood fill with writing pixels. I can't use flood
fill though, unless I have a solid color or border, which I have
neither. If I want to bit blit, I think I will need a separate bit
image for each button. I am trying to avoid that.

In any case, I think I have a good solution. I remember seeing
some decent bitmap editing classes on codeproject.com. I think I will
write a one time program to modify the color of the buttons in my bmp
file then save it back. This way, I will be able to use the Win32
flood fill call, or maybe even a bit blit. I have looked at those
calls too.

Your suggestions don't sound strange to me at all by the way.
I understand what you are saying. Its just that doing a bit blit in
the pain message handler isn't ideal for me. However, that may work
out better than any other alternative. I really do appreciate the
help. It is obvious that you know way more than I about this stuff!

Thanks,
Adam

On Sun, 29 Feb 2004 09:21:32 -0500, "Scott McPhillips [MVP]"
wrote:

>Adam Messer wrote:
>> Scott,
>>
>> I thought a little more about what you said, and I have two
>> things to say. First, I already separate the click from the drawing,
>> but not the way you mean. I know I should not do anything that blocks
>> in the message pump loop, so I have a thread that does the painting of
>> the buttons. The button response code simply tells the thread what
>> burton to draw. This is necessary because I want to draw a button one
>> color, then revert its color back in about 1/2 second. I know that you
>> mean for me to do my drawing when I get the pain message. The MSVC
>> application expert creates a paint method for dialogs, but does
>> nothing except invoke the super class's draw method. I have never put
>> code in the draw method and am not exactly sure how to determine what
>> I need to redraw. Even if I could it still presents a problem for me.i
>> would still have to have the code the repaints a pure white over all
>> my buttons get called every time I get the pain message. This in
>> addition to changing the color to yellow and back each time a button
>> is clicked. I don't know how much it would really buy me to do the
>> repaint when I get the message, eve though that is the right place to
>> do it. One thing I would really like to do is to be able to change the
>> button colors to a pure white color once at startup, and flood fill
>> the button that gets pressed. I will think about your suggestions more
>> though.
>>
>> Thanks again,
>> Adam
>
>If my suggestions seem strange, it is because in Windows you can blit a
>bitmap hundreds or thousands of times faster then you can flood fill
>with SetPixel. SetPixel is so slow that you were forced to introduce a
>thread. The thread would be unnecessary if you had highlighted bitmaps
>of the buttons available and blit one of them to change a button's
>appearance. Avoid SetPixel, except perhaps during one-time
>initialization if you prefer to prepare the bitmaps in memory instead of
>by adding a bitmap resource.
>
>And putting all the drawing code in WM_PAINT is fundamental to any
>well-behaved Windows GUI. It makes minimize/restore possible and it
>supports the illusion that one window can "uncover" another.

I've actually written the very application that the original poster is
describing: a window with the image of a physical remote control, where
the user can poke non-rectangular buttons, and the buttons can be either
up or down or, independently lit or unlit.

I used as resources 5 images:

an image of the remote control all lit, all buttons down.
an image of the remote control all lit, all buttons up.
an image of the remote control unlit, all buttons down.
an image of the remote control unlit, all buttons up.
an 8-bit deep, indexed color image where each button was a different
color. This image was used to create blitmasks, and for hit
testing.

The user clicks, I use the mouse coordiantes to get an appropriate pixel
from my mask image, and depending on the pixel color index, I know which
button was hit. I set the button state appropriately and generate a
paint event of the bounding rect of that button.

For the light, I set a timer for a 1/2 sec. When it fires, it resets the
state and generates a paint event.

In my paint event handler:

On an offscreen bitmap, I first blit the background, then using the
mask, the one button that is different. Then blit the result to the
window. No flicker. Smooth animation.

explore DIBSections ...
they are an easy an practical way to dirrectly manipulate and then draw
images
....
load the source image into a dib section (CreateDIBSection) in a memory dc
(created with CreateCompatibleDC), then directly manipulate the pixels using
the pointer returned by CreateDIBSection, then BitBlt it during a wm_paint
to the screen

--
Louis Solomon
www.steelbytes.com


"Adam Messer" wrote in message
news:8pe040lebddtgo4n8v57tcbh22efvj61ds@4ax.com...
> Hello all,
>
> I am a fairly new Windows programmer. I am writing a program
> to remote control some A/V equipment. The way I decided to implement
> my interface is to use a BMP image of a universal remote control. I am
> using Visual Studio 6 with C++ and MFC in a dialog application.
>
> I have gone through the trouble to get the coordinates of
> every button on the remote control. By capturing the left button click
> message I am able to determine which button was under the mouse when
> it is clicked. I want visual feedback when a button is clicked, and
> here is what I am doing to get it.
>
> 1) I find all the 'fairly white' pixels within the button region and
> paint them a bright yellow to make it look like the button lights when
> clicked.
>
> 1a) Many of my buttons are not rectangular and there is black writing
> on each button. That is why I can't simply paint all pixels in my
> rectangles.
>
> 2) After about 1/2 second I change the color of the yellow pixels back
> to a 'standard white' color.
>
> 3) I am using the SetPixelV method to set the colors of the buttons.
>
>
> When I say 'fairly white', I mean all pixels who's RGB values fall
> into a range that look white. SInce I took a picture of my remote
> control instead of drawing it within my application, the colors vary a
> lot, so I can't simply do a flood fill. The color of the buttons and
> the surrounding areas are not consistent.
>
> This is obviously a very inefficient way to accomplish my task. There
> is one button called 'light' on my remote. When I click on it the
> whole keypad is supposed to light up for a few seconds. It takes so
> long to write all the pixels, one by one, that it looks like a yellow
> wave slowly washes across my remote control.
>
> The way I see it I have two choices. 1) I can go into some sort of
> graphics program (i.e. Photoshop) and 'fix up' the remote control
> image file. 2) I can set all 'fairly white' pixels to a consistent
> white when my application initializes. I can then use a flood fill
> when a button is clicked which should be much faster.
>
> Here is my problem. The method I am using to write directly into the
> device context doesn't work if my application gets re-painted. All the
> colors revert back to their defaults. If some kind sole out there
> could clue me in on a way to change the colors that would remain
> changed after a re-paint, I would be forever grateful!
>
> Please forgive me if my terminology isn't very good, but I am an OS
> programmer, not a UI or graphics programmer. These Win32 and MFC
> concepts and terms are fairly new to me.
>
> TIA,
> Adam Messer
> amesser39@hotmail.com
>

David and all who helped,

First of all, thanks for the help. Sorry I did not say that
until now. stopped reading News for a while. I finally did realize
that I did need more than one bitmap, although I did not go as far as
you did. I do have one image with the buttons all up, and one with the
buttons all down. I did not do the one with all the buttons all
different colors. I understand what you are saying though. What I did
was more painful and less flexible. I wrote a special version of the
program, for development purposes only, that has a listbox which sets
up the upper left coordinate when I left click and the lower right
when I right click. I also added an edit box in which I can enter the
button name. When I clicked the 'done' button my program wrote out
three files. One has CRects with each button, another has an array of
all the CRects from the first step, and the last has defines for all
the CRects. This gives me what I want, but if I ever change the
position of the BMP I am in trouble.

I still use a thread so I don't need a timer and I don't block
the message pump. When I click a burton, I blit the appropriate area
of the down button, and 1/2 second later I blit the up button. It
works pretty well. My remote also has a 'light' button which lights up
the who;e key pad. I didn't really need the functionality on the
computer program, but I did it anyway. I have one huge CRect which
covers all my buttons. When I click the 'light' button I blit that
whole area. It works pretty well. On my old version, in which I was
setting every pixel, the 'light' function looked like a wave running
up and down my key pad. That's how slow it was, even on a 1.8 GHz
machine.

Thanks again for all the help. I am seriously thinking about
adapting your method for the future as it would make my life easier.

Thanks,
Adam

On Sun, 29 Feb 2004 21:19:31 GMT, David Phillip Oster
wrote:

>I've actually written the very application that the original poster is
>describing: a window with the image of a physical remote control, where
>the user can poke non-rectangular buttons, and the buttons can be either
>up or down or, independently lit or unlit.
>
>I used as resources 5 images:
>
>an image of the remote control all lit, all buttons down.
>an image of the remote control all lit, all buttons up.
>an image of the remote control unlit, all buttons down.
>an image of the remote control unlit, all buttons up.
>an 8-bit deep, indexed color image where each button was a different
> color. This image was used to create blitmasks, and for hit
> testing.
>
>The user clicks, I use the mouse coordiantes to get an appropriate pixel
>from my mask image, and depending on the pixel color index, I know which
>button was hit. I set the button state appropriately and generate a
>paint event of the bounding rect of that button.
>
>For the light, I set a timer for a 1/2 sec. When it fires, it resets the
>state and generates a paint event.
>
>In my paint event handler:
>
>On an offscreen bitmap, I first blit the background, then using the
>mask, the one button that is different. Then blit the result to the
>window. No flicker. Smooth animation.