|
I would like to know the simplest way to make a radio button with bitmap on it. Please help!
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
looking here[^] will provide you several sources on the subject.
i especially appreciate this one[^]...
hope it helps
cheers,
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
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!
|
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
Hi
You can get that tip by press Ctrl+Shift+Space
Iman Ghasrfakhri
|
|
|
|
|
|
your are too great how you know such minor details
|| ART OF LIVING ||
|
|
|
|
|
shivditya wrote: your are too great how you know such minor details
Practice Man Practice 
"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
|
|
|
|
|
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);
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'
|
|
|
|
|
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
|
|
|
|
|
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'
|
|
|
|
|
Do experience any memory leaks?
SkyWalker
|
|
|
|
|
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'
|
|
|
|
|
Hard to say.
By the way, did you try to use DIBs? Just give it a try!
SkyWalker
|
|
|
|
|
I have never played with them, as they intimidated me. I'll start the Google machine, and undertake another learning experience. Can't see why that would cure the problem, but, as you say, you never know.
Thanks,
David
Debugging - The high art and magic of cussing errors into 'features'
|
|
|
|
|
Take the DDB2DIB() from this article:http://www.codeproject.com/opengl/anyTex.asp[^]
...and belive me.. I developed a control for panning / zooming maps and it works really fast (almost independent on if the application is maximized or not).
Yours
SkyWalker
-- modified at 15:22 Saturday 29th October, 2005
|
|
|
|
|
Thank you. I am looking into it.
Debugging - The high art and magic of cussing errors into 'features'
|
|
|
|
|
Not quite plug-n-dib, as I am using neither OpenGL, nor MFC, but I'll figure it out...
Debugging - The high art and magic of cussing errors into 'features'
|
|
|
|
|
Ok - question time. My application is a MIDI software sequencer, and the windows can be piano views, event views, or other views. I chose to create these views on the fly, as the user can make the 'bars' take more or less space, and each view will be changed. These views can be quite long. A quick calculation shows that a six minute performance can have up to 135,000 pixels in width, and these views can be up to 1000 (or more) pixels in height. In addition, there are an unknown number of windows, as the user can have as many tracks in the performance as they desire (until their computer craps out, of course).
From that, you can see why I chose to create these views on the fly, and only create what needs to be blitted. It would just be too slow if I didn't, and it would take WAY too much memory.
So my question is what would a DIB buy me in this scenario? I am creating the scene using the device that it will be blitted to, so it doesn't make sense to me to put a DIB intermediary in there. That would just make Windows perform many more operations behind the scene, in order to blit what I am blitting. It would take the DDB for the device, convert it to DIB, and then blit it to the DDB stage again, for the exact same device that was used to originally create it. Every scrollbar change and every window resize would result in a huge increase in processor usage to do this background processing. Just reblitting the screen would be slowed down as well, as the WM_PAINT handler would have to go through the entire process.
Please don't take this as me not liking what you have done, or your advice. I am simply trying to get my thoughts down in a cohesive manner, in order to learn more efficiently.
Thank you,
David
Debugging - The high art and magic of cussing errors into 'features'
|
|
|
|
|
I would say the problem is how much Windows must clip the screen output. When the window is maximized the only surface that needs to be drawn is your window, but when you are not maxed, Windows must draw the windows under yours and then clip out your Windows client area from them.
|
|
|
|
|
I think this is part of the problem at times, except that it doesn't explain why the proc is at 7%, and then at other times the proc is at 55%, doing the exact same things. Another program leaking resources? My program leaking resources? What is it, exactly, that causes the proc usage to suddenly jump, when restored to the same window size as before? I have tried running a large number of apps while running my app, and I did not trigger the problem. I'll keep trying to find the trigger.
Thanks for the input.
David
Debugging - The high art and magic of cussing errors into 'features'
-- modified at 21:02 Saturday 29th October, 2005
ps - when the problem occurs, closing all other windows does not fix it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
