|
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.
|
|
|
|
|
Hrm, intresting..
Out of curosity, in TaskManager Process tab, go View/ Select Columns.. and Check GDI Objects, see how much work you are really putting on the GDI system.
|
|
|
|
|
It only shows 50 when opened with nothing running, ~92 GDI objects when running the performance I was playing with. This is well under some of the other procs running (Firefox: 131). My application uses about 15.5K memory when running that proc, as well.
Now, that major clue. There are two of them, actually.
1) Out of curiousity, I ran Jooleem while my application was running. All of a sudden Task Manager showed my proc usage creeping up to about 10%, from 0%. Shut Jooleem down and restarted my program and played it. Proc usage was at 45%.
Rebooted. Ran my program five times. Each time Task Manager showed it about 0~2% proc usage. During sixth time, ran Jooleem again. My proc usage immediately went up to 10% again. Shut Jooleem off. Without shutting my program down, I restarted the task it was performing. TM showed my app to be using 45% of the proc time. Shut my program down and restarted it. It was still at 45%.
So finally a breakthrough.
2'nd clue) It definately seems to have something to do with the graphics. If my application is being shown on the screen, and then I cover it up with Firefox or another program, the proc usage goes to 0%. Bring my program to the front, and proc usage spikes to 45% again.
I am not using anything other than plain GDI for my graphics. No DirectX, no OpenGL, no nothing. My app is using DirectMusic, but I don't see how that could be tying into the graphics. I'm not saying that it is impossible, I'm just saying that I don't know how it could be. I don't link to anything other than dxguid.lib.
I guess a third clue is that the problem is somehow able to transmit itself to my relaunched application, no matter how many times I shut it down and restart it. It takes a shutdown or a log-off and log-on to make the problem go away.
Even with these clues, I don't know what to do next. Leave it? Say it is some other program's problem? I would still like to know what is really going on, but I don't want to delve into the guts of Jooleem just to find out, and I am scared that is the only thing that would eventually unearth the problem. Maybe someone else has a better idea?
David
Debugging - The high art and magic of cussing errors into 'features'
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
