|
Yes very useful indeed. I did find the problem though, it had to do with the style parameters in the resource file, im not sure which one was messing it up, cause i just used copied the same param's from another dialog that was working.
"There are 10 types of people, those who understand binary, and those who don't."
- Somebody, not me.
|
|
|
|
|
Jader89 wrote: it had to do with the style parameters in the resource file
I am almost sure that your dialog's Border was not set to Dialog Frame in Properties Dialog.
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
I'm pretty sure it was the DS_MODALFRAME option... It looks like the same thing your talking about, without looking at what this option does.
"There are 10 types of people, those who understand binary, and those who don't."
- Somebody, not me.
|
|
|
|
|
Could some one help me with dynamically creating a combo box at a particular position. Currently I have a text Box, I need to replace this text box with a combo Box.
Any help will be greatly appreciated.
M
|
|
|
|
|
you could create both with the resource editor, and at initialization time of the program, hide on of the two using CWnd::ShowWindow(SW_HIDE).
d'you follow me ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
I have done this (drop-down list boxes) in C, SDK-level stuff. Is this any use, or are you looking for this new-fangled C++, MFC, etc code?
|
|
|
|
|
I was looking for C++ using MFC.
M
|
|
|
|
|
Hey,
I use a CRichEditCtrl to display RTF-text on screen and later to a printer. My code works pretty good for "printer - output" but on screen output my text is moved (ca. 2cm).
Can you help me solving this problem?
|
|
|
|
|
Hello !
I need to 'compute' a random __int64 value that must be included between two values (both are __int64 too).
Any idea how I can manage that ? I don't think it exists something else than rand_s() function that will 'return' a random unsigned int.
I'm trying to find how I can manage to do that by simply using this function several times but it's the end of the day and my brain is too slow yet 
Any idea ?
|
|
|
|
|
__int64 i64 = (__int64)rand() * (__int64)rand();
Cleek | Image Toolkits | Thumbnail maker
-- modified at 16:22 Tuesday 29th November, 2005, because that was stupid of me.
|
|
|
|
|
Hi !
Thanks for your response but unfortunately it doesn't help a lot: first, the range is not respected (the number must be between a min and a max value). And second, rand returns an unsigned value (from 0 to 32768).
|
|
|
|
|
Cedric Moonen wrote: the number must be between a min and a max value
randFoo = (randFoo % (max - min)) + min
Cedric Moonen wrote: rand returns an unsigned value (from 0 to 32768
i thought i knew that, but for some reason i assumed "int" means "32 bits worth of data", in the MSDN - like maybe MS had a better version of rand. oh well.
but, you can just call rand() multiple times and bit-shift the bits into a pair of 32-bit values, which you can then assign to your i64. there's nothing else in the standard C/C++ RTL to give you more than 16 bits of random data at a time.
this isn't cryptologically secure, of course. but if you need that, the obvious place to look is in a crypto library (crypto++, for example)
Cleek | Image Toolkits | Thumbnail maker
-- modified at 14:47 Tuesday 29th November, 2005
|
|
|
|
|
Chris Losinger wrote: like maybe MS had a better version of rand. oh well.
Yes, in VC 2005 you have rand_s which will compute a random unsigned value (from 0 to UINT_MAX).
Chris Losinger wrote: but, you can just call rand() multiple times and bit-shift the bits into a pair of 32-bit values, which you can then assign to your i64.
Yes, no problem for that I thought already about that but then I have the problem of the ranges  . You will certainly understand that my head is buring now  .
But nowaday, thanks for the help. I will sleep a night on it and tomorow, everything will be clear 
|
|
|
|
|
Cedric Moonen wrote: Any idea ?
See here. The period, M, can be changed to your liking. You might also have to change A to get full-period generator.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
http://www.codeproject.com/cpp/mersennetwisterclass.asp[^]
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
I often have to change my stdafx.h pch file for stuff like WINVER to have access to certain things in the win api. Of course I could just make a copy of this file and use that one as my starting point. But is there a way that I can change it so that when VS (.net 2003) creates it, it always has the #defines the way that I want them?
My articles
BlackDice
|
|
|
|
|
Go to the following directory:
<Visual Studio Install Path>\Vc7
Do a search for files named stdafx.h.
You can now see all the stdafx.h files and modify the one for the project that you use.
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
-- modified at 19:51 Tuesday 29th November, 2005
|
|
|
|
|
1) Is there a way to programatically check/uncheck the checbox in this control?
2) Is there a way to tell when the checkbox has been clicked on?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: 1) Is there a way to programatically check/uncheck the checbox in this control?
DTM_SETSYSTEMTIME. The WPARAM is used to set the checkbox state.
The return value from a DTM_GETSYSTEMTIME message is the checkbox state.
John Simmons / outlaw programmer wrote: 2) Is there a way to tell when the checkbox has been clicked on?
Handle the DTN_DATETIMECHANGE notification.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Hi all.
I wrote an app. that relies on GDI+ 1.0, and found that it uses a huge amount of CPU, comparing it with GDI. Is this right, or am i doing something wrong?
|
|
|
|
|
Alberto_Canabal wrote: am i doing something wrong?
Yes. 
Since i don't know what you're doing, i obviously can't say what. Here are some things to watch for:
- GDI+ is a good deal slower than old GDI calls for some operations. When faced with a serious performance problem, profile *everything* and look for the root cause.
- Some GDI+ features, such as antialiasing, gradiant fills, etc. are bound to make some operations slightly slower - so if your code requires a billion lines to be drawn every second, then the extra cost of making them look nice will really cost ya!
- Blitting between a memory DC and the screen in GDI+ can be considerably slower than doing so using GDI routines, especially if the two use different color depths.
|
|
|
|
|
To start monitoring things, i wrote a simple GDI+ app., which draws a static rectangle and marks a variable area with a grid. The app. doesn't use double buffering (for the sake of simplicity)...
Here is my whole OnPaint method:
<br />
CRect rect;<br />
GetUpdateRect(&rect);<br />
<br />
CPaintDC dc(this);<br />
Graphics graphics(dc.m_hDC);<br />
<br />
graphics.Clear(Color::Black);<br />
<br />
Color colorCross = Color::Red;<br />
HatchBrush oBrushCross(HatchStyleCross, colorCross, <br />
Color(0,0,0,0));<br />
<br />
Pen oPenCross(colorCross, 0.0);<br />
<br />
RectF oRect(<br />
rect.TopLeft().x + 50, <br />
rect.TopLeft().y + 50, <br />
rect.Width() - 50, <br />
rect.Height() - 50);<br />
<br />
graphics.FillRectangle(&oBrushCross, oRect);<br />
graphics.DrawRectangle(&oPenCross, oRect);<br />
<br />
Color color = Color::Yellow;<br />
HatchBrush oBrush(HatchStyleBackwardDiagonal, color, <br />
Color(0,0,0,0));<br />
Pen oPen(color, 0.0);<br />
<br />
RectF ooRect(100, 100, 200, 200);<br />
graphics.FillRectangle(&oBrush, ooRect);<br />
graphics.DrawRectangle(&oPen, ooRect);<br />
Results:
- CPU usage reaches nearly 70% (i'm working on a pretty good computer)
- Drawing is horrible...for example, when you hover another window over the dialog, it leaves "garbage", or doesn't repaint the variable area ok...
Any lights?????
Thanks!
|
|
|
|
|
Two suggestions:
1) You're drawing relative to the update rectangle. This is what's causing the "garbage" or unpainted areas on your window! For a stable drawing you want to always draw relative to the same area - in this case, the client area of the window. You can improve performance by clipping to the update area however.
2) If the window contents is stable, you'll get a *huge* improvement by double-buffering. Only redraw into the buffer when something changes, and only re-allocate the buffer when the window size changes. This can make the difference between 100% and 1-2% CPU usage while dragging a smaller window over the top of yours. Here also you can use the update rectangle to only blit the smallest possible amount of data from the back buffer to the screen.
Finally, hatch brushes are slow. The bulk of the time spent drawing in your test code is spent filling that big red hatched rectangle.
You must be careful in the forest
Broken glass and rusty nails
If you're to bring back something for us
I have bullets for sale...
|
|
|
|
|
I totally agree when you write about double buffering, but i've got an issue with that too (at this point i don't know what am i doing with GDI+)...my app needs zooming, so i'm using a CScrollView derived class (CZoomView, which i obtained here)...everithing's fine while i just drag windows (amazed how much fast is when using another brush)...but here's the but: it doesn't paint correctly when zooming...AAAAHHHHRG!
Some conclusions:
*Double buffering classes, or at least the ones i've tried, don't work OK with GDI+ unless you repaint ALL the client area, not only the clipbox (still haven't tried with CachedBitmap though)
*GDI, while not so good-looking and easy-to-use, is muuuch faster and reliable than it's + counterpart...i've even tried an MSDN sample, and it didn't repaint correctly (it was just a rectangle)...
Suggestions? (Harakiry or starting with bonsai are not acceptable ones)
|
|
|
|
|
Don't forget that you can mix GDI and GDI+ fairly easily. So if you have a GDI class that works for double-buffering, use it - switch to GDI+ only when you need it!
Example (dc is the MFC wrapper for the back buffer):
{
using namespace Gdiplus;
Graphics gfx(dc.m_hdc);
gfx.Clear(Color::Black);
}
You must be careful in the forest
Broken glass and rusty nails
If you're to bring back something for us
I have bullets for sale...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
