MFC CPicture, CBitmap and CDC programming question - Programmer

This is a discussion on MFC CPicture, CBitmap and CDC programming question - Programmer ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: MFC CPicture, CBitmap and CDC programming question

  1. MFC CPicture, CBitmap and CDC programming question

    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


  2. Re: MFC CPicture, CBitmap and CDC programming question

    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]


  3. Re: MFC CPicture, CBitmap and CDC programming question

    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.



  4. Re: MFC CPicture, CBitmap and CDC programming question

    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.



  5. Re: MFC CPicture, CBitmap and CDC programming question

    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]


  6. Re: MFC CPicture, CBitmap and CDC programming question

    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.



  7. Re: MFC CPicture, CBitmap and CDC programming question

    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.

  8. Re: MFC CPicture, CBitmap and CDC programming question

    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
    >




  9. Re: MFC CPicture, CBitmap and CDC programming question

    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.



+ Reply to Thread