C / C++ / MFC

28-Oct-05 23:39

I would like to know the simplest way to make a radio button with bitmap on it. Please help!

toxcct29-Oct-05 2:25

toxcct

29-Oct-05 2:25

if i well remember, you actually trying to put a bitmap on a push-like button (such as a radio or a check box).

you could have a look at my article[^] and look at the "Switch Answers Lists" button.

here is how to proceed. On the OnInitDialog() insert this code :

m_pbAnswersListState = (CButton*) GetDlgItem(IDC_ANSLISTSTATE_CHK);
 
//...
 
HICON hIcon;
hIcon = (HICON)LoadImage(AfxGetInstanceHandle(),
                         MAKEINTRESOURCE(IDI_SWITCH),
                         IMAGE_ICON,
                         0,
                         0,
                         LR_DEFAULTCOLOR);
if (hIcon) {
    m_pbAnswersListState->SendMessage(BM_SETIMAGE, IMAGE_ICON, (LPARAM)hIcon);
}

in my code, IDI_SWITCH is the ID of my icon, and IDC_ANSLISTSTATE_CHK is the ID of my checkbox (work the same with a radio)...

ok, i use an icon ; for a bitmap, just change the IMAGE_ICON parameter with IMAGE_BITMAP and the HICON with HBITMAP.

TOXCCT >>> GEII power
[toxcct][VisualCalc]

-- modified at 8:37 Saturday 29th October, 2005

LaHaHa29-Oct-05 12:17

29-Oct-05 12:17

I would like to know how it implement with button up image and button down image. Also it seems no change with the radio button.

m_logon.GetDlgItem(IDC_RADIO1);
//...
HBITMAP hIcon;
hIcon = (HBITMAP)LoadImage(AfxGetInstanceHandle(),
MAKEINTRESOURCE("TEST_U"),
IMAGE_BITMAP ,
0,
0,
LR_DEFAULTCOLOR);
if (hIcon)
{ m_logon.SendMessage(BM_SETIMAGE, IMAGE_BITMAP, (LPARAM)hIcon);}

Please help!

toxcct30-Oct-05 4:42

toxcct

30-Oct-05 4:42

looking here[^] will provide you several sources on the subject.

i especially appreciate this one[^]...

hope it helps

cheers,

TOXCCT >>> GEII power
[toxcct][VisualCalc]

LaHaHa30-Oct-05 11:17

30-Oct-05 11:17

Your method is OK!
I can place a bitmap on the radio button, but the problem is the shape of the button. I would like to place a round bitmap on it. Also the button up and down will have different bitmap. Please tell me how to do it with your method!
Thank you!

Ravi Bhavnani30-Oct-05 6:18

Ravi Bhavnani

30-Oct-05 6:18

See this[^] article.

/ravi

My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com

LaHaHa30-Oct-05 11:21

30-Oct-05 11:21

Thank you for your help!
Is there any simplest method without using other Class to do it as CBitmapbutton or as toxcct's method?
Please help!

Function parameters tip

Chintoo72328-Oct-05 23:14

Chintoo723

28-Oct-05 23:14

Visual Studio 6 gives the function prototype when you type left paranthesis '(' after the function name. This tip goes away if switch between windows momentorily. Is there any way to get this tip back when you are in the middle of the set of function parameters?

thanks in advance.

Ghasrfakhri28-Oct-05 23:58

Ghasrfakhri

28-Oct-05 23:58

Hi You can get that tip by press Ctrl+Shift+Space

Iman Ghasrfakhri

Chintoo72329-Oct-05 1:00

Chintoo723

29-Oct-05 1:00

Awesome. Thanks.

shivditya29-Oct-05 2:13

shivditya

29-Oct-05 2:13

your are too great how you know such minor details

|| ART OF LIVING ||

ThatsAlok30-Oct-05 19:25

ThatsAlok

30-Oct-05 19:25

shivditya wrote:
your are too great how you know such minor details

Practice Man Practice Smile | :)

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV

Odd BitBlt timings

RandomMonkey28-Oct-05 20:42

28-Oct-05 20:42

I am hoping somebody can explain why the following is happening, as it makes very little sense to me.

I have an application that is updating the screen between 10ms sleep states. Depending upon screen size, there are a different number of child windows. These child windows do not overlap each other.

The problem is that when the application is relatively small, the processor is kicking over at about 6%. When the application is maximized, the processor is also kicking over at about 6%. (It seems closer to 4%, though.) Now the kicker - when it is stretched fairly big on the screen, it starts to chew up the processor - up to 20-35%.

When I first started this, the times for the maximized and small windows were about the same - 5~10% processor hit. But the non-maximized, large window time was terrible - 65%. I created a permenant memory DC, and brought the time down to ~35%. Then I changed the class style to include 'CS_OWNDC', and created a permenant 'compatible' DC, and this brought the non-maximized, large window size to about the 20% processor hit.

It makes no sense to me why the maximized application window state would chew up less processor time to draw than the large, non-maximized application window, unless Windows allocates things differently if a window is maximized, because it figures the maximized window 'hides' everything behind it?

I am running Win2000 on a AMD 2100 machine, with a relatively old 16Meg Radeon 7000 graphics card.

The code looks like the following. Each window uses exactly the same code. (I have simplified it a bit, but the pertinant part is shown.)

void GenView::paintWindow() {
   HDC dc = GetDC(thisWindowsHwnd);
   //Simply blit the bitmap onto the memory dc
   HBITMAP oldBmp = (HBITMAP) SelectObject(memoryDC, memoryBitmap);
   BitBlt(dc, 0, 0, width, height, memoryDC, 0, 0, SRCCOPY);
   SelectObject(memoryDC, oldBmp);
   ...
   }

When the window is maximized, it is performing this 8 times each 10ms pass, as there are 8 windows visible. This becomes 7 times for the problem window size, and 4 times for the minimum window size.

Any ideas on how to bring that 20% proc usage down to the 4% mark, or am I going to be stuck with that?

Thanks,
David

The following is a table overview, for reference:

State:                   Child Window Sizes:     # Windows:     Proc time:
Maximized                799(wide)x100(high)     8              4%

Large, non-maximized     608x100                 7              20%

Small                    347x100                 4              6%

Debugging - The high art and magic of cussing errors into 'features'

Mircea Puiu28-Oct-05 21:19

Mircea Puiu

28-Oct-05 21:19

DDB related activities do consume time resources, especially when you are blitting large areas.
You can get a great improvement by using DIBs. StretchDIBBits is significantly faster.

SkyWalker

RandomMonkey29-Oct-05 4:24

29-Oct-05 4:24

Can you explain why it takes LESS time to draw more? All things are equal except that the app is maximized. When the app is maximized, it draws quickly. When it is large, but not maximized, it is significantly slower.

Of course, now that I have turned the computer off and on, I no longer see that effect (yet), so this is triply befudling. Weird.

David

Debugging - The high art and magic of cussing errors into 'features'

Mircea Puiu29-Oct-05 7:32

Mircea Puiu

29-Oct-05 7:32

Do experience any memory leaks?

SkyWalker

RandomMonkey29-Oct-05 9:06

29-Oct-05 9:06

No, not according to MemProof 9.48. It does tell me thousands of times that I am attempting to free an unexisting resource. I have found that most of those come from deep within the RougueWave STL that shipped with my ancient compiler, and there is nothing I can do about them. But the same blitting proc hit occurs when I compile the app with Code::Blocks and VS2003 Toolkit, so it can't be the old compiler's fault in this case.

The more I play with it, the more I am totally perplexed. As I said, it worked as I thought it should when I rebooted this morning. About ten times later (just hitting 'Play' in the app some of those times, shutting the app down and restarting it other times), after I had been on the Internet, and had several other programs running, the proc time again jumped to the unacceptable levels for a commercial app of its nature. So I logged off and logged back on, without rebooting, and the behavior was fixed. Tried re-running the applications that I had ran before, and re-running the app. I could not get the behavior to come back! Arrrgggghhhhh!

I think I'm suffering from the 'Ghost in the Machine'! I guess I'll just have to depend upon everyone having a 1.2GHz proc to run my program, so they can keep the Ghost happy. (I'm kidding - I really want to figure this out before shipping.)

David

Debugging - The high art and magic of cussing errors into 'features'

Mircea Puiu29-Oct-05 9:11

Mircea Puiu

29-Oct-05 9:11

Hard to say.
By the way, did you try to use DIBs? Just give it a try!

SkyWalker

RandomMonkey29-Oct-05 9:14