|
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...
|
|
|
|
|
Hi,
in my work i have to select data from combobox in parent window and send it it to editbox in child window,
i written code in parent window button control like as fallowing..
CTransmit_ModeDlg Dlg; // assigning object for child window
Dlg.DoModal();
CString RecAddr;
GetDlgItemText(IDC_Addr_Channel1, RecAddr);// selecting data from combobox
Dlg.m_strRec_Addr=RecAddr; // assigning it to edit box in child window and m_strRec_Addr is member variable of editbox in child window.
thanking you
sheshidar patnam
|
|
|
|
|
This would never work because DoModal will 'block' until the dialog box is closed.
A better way to 'send' data from your parent dialog to your child dialog is to add method in your child dialog that will 'store' the data. You call these function before calling DoModal and in OnInitDialog of your child dialog, you just have to use this data.
Example:
class CChildDlg : public CDialog<br />
{<br />
public:<br />
void SetData(int Value) { m_Value = Value; }<br />
<br />
private:<br />
int m_Value;<br />
}
voidCChildDlg::OnInitDialog()<br />
{<br />
....<br />
}
|
|
|
|
|
THx Moonen,
i solved my problem but not exactly how u explained, i got an idea on "DoModal will 'block' until the dialog box is closed", i wrote the same code before domodal();
and it worked.
Thx again.
|
|
|
|
|
Hi,
is it possible to change the Threadname of a Thread that was created with "AfxBeginThread()"?
In C# it is quite easy, but i couldn't find out a method for C++/MFC. It would be nice to read the correct threadname in the debuggerwindow. Right now it always tells me: "The Thread 'Win32 Thread' finished with code 0 (0x0).".
Thanks,
Snow
|
|
|
|
|
<br />
<br />
<br />
#pragma once<br />
<br />
extern "C"<br />
void WINAPI SetCurrentThreadName(<br />
LPCTSTR szThreadName<br />
);<br />
<br />
extern "C"<br />
void WINAPI SetThreadName(<br />
DWORD dwThreadID, <br />
LPCTSTR szThreadName<br />
);<br />
<br />
<br />
<br />
#include "stdafx.h"<br />
#include "SetThreadName.H"<br />
<br />
#define MS_VC_STN_EXCEPTION 0x406d1388<br />
<br />
#pragma pack( push, PPSetThreadName)<br />
#pragma pack( 4 )<br />
<br />
typedef struct _SETTHREADNAMEINFO<br />
{<br />
DWORD dwType;
LPCSTR szName;
DWORD dwThreadId;
DWORD dwFlags;
<br />
} SETTHREADNAMEINFO;<br />
<br />
#pragma pack( pop, PPSetThreadName )<br />
<br />
extern "C"<br />
void WINAPI SetCurrentThreadName(<br />
LPCTSTR szThreadName<br />
){<br />
DWORD dwThreadId = GetCurrentThreadId();<br />
SetThreadName(dwThreadId, szThreadName);<br />
}<br />
<br />
extern "C"<br />
void WINAPI SetThreadName(<br />
DWORD dwThreadId, <br />
LPCTSTR szThreadName<br />
){<br />
if( IsDebuggerPresent() ){<br />
<br />
SETTHREADNAMEINFO STNInfo;<br />
TCHAR szTempName[10];<br />
<br />
ZeroMemory(&STNInfo, sizeof(SETTHREADNAMEINFO));<br />
<br />
ZeroMemory(szTempName, sizeof(szTempName));<br />
lstrcpyn(szTempName, szThreadName, 9);<br />
<br />
STNInfo.dwType = 0x1000;<br />
STNInfo.szName = szTempName;<br />
STNInfo.dwThreadId = dwThreadId;<br />
STNInfo.dwFlags = 0;<br />
<br />
TCHAR szMessage[512];<br />
wsprintf(szMessage, "Setting thread 0x%08lx name to '%s'", dwThreadId, szTempName);<br />
OutputDebugString(szMessage);<br />
<br />
__try<br />
{<br />
RaiseException( MS_VC_STN_EXCEPTION, <br />
0, <br />
sizeof(STNInfo) / sizeof(DWORD),<br />
(DWORD *)&STNInfo);<br />
}<br />
__except (EXCEPTION_CONTINUE_EXECUTION)<br />
{<br />
}<br />
<br />
}<br />
}<br />
<br />
<br />
|
|
|
|
|
|
Thanks thats what i wanted 
|
|
|
|
|
every time Button1 is click, the value of CPU's program counter is read and displayed on edit box1.
Then Button2 is click, the value of CPU's program counter is read and displayed on edit box2.
My purpose is to measure how long the device reponds to computer's command.
Cheers.
MilkyWay
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
