|
did you take a piece of your time to search the site ?
see this[^]...
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
|
Plz can someone help me? Is it possible to show text in a RichEditCtrl in zoomfactor while editing? (real zoom, not changing fontsize etc)
thx
|
|
|
|
|
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'
|
|
|
|
|