C / C++ / MFC

29-Nov-05 5:11

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 Dead | X|

Any idea ?

C^hris L^osinger29-Nov-05 7:44

C^hris L^osinger

29-Nov-05 7:44

~~__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.

Cedric Moonen29-Nov-05 8:00

29-Nov-05 8:00

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).

C^hris L^osinger29-Nov-05 8:43

C^hris L^osinger

29-Nov-05 8:43

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

Cedric Moonen29-Nov-05 8:53

29-Nov-05 8:53

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 Sigh | :sigh:

. You will certainly understand that my head is buring now Poke tongue | ;-P

.

But nowaday, thanks for the help. I will sleep a night on it and tomorow, everything will be clear Big Grin | :-D

David Crow29-Nov-05 9:15

David Crow

29-Nov-05 9:15

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

changing default #defines in stdafx.h

PJ Arends29-Nov-05 9:32

PJ Arends

29-Nov-05 9:32

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!

BlackDice29-Nov-05 4:44

BlackDice

29-Nov-05 4:44

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

Re: changing default #defines in stdafx.h

Curtis Schlak.29-Nov-05 13:51

Curtis Schlak.

29-Nov-05 13:51

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

CDateTimeCtrl Questions

#realJSOP29-Nov-05 4:15

#realJSOP

29-Nov-05 4:15

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

Re: CDateTimeCtrl Questions

PJ Arends29-Nov-05 6:05

PJ Arends

29-Nov-05 6:05

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.

GDI+ cpu usage

Alberto_Canabal29-Nov-05 3:48

Alberto_Canabal

29-Nov-05 3:48

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?

I just want you to be happy;
That's my only little wish...

Shog⁹29-Nov-05 11:39

Shog⁹

29-Nov-05 11:39

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.

Alberto_Canabal1-Dec-05 1:01

Alberto_Canabal

1-Dec-05 1:01

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 />
  //Get the invalid rectangle...<br />
  CRect rect;<br />
  GetUpdateRect(&rect);<br />
<br />
  CPaintDC dc(this);<br />
  Graphics graphics(dc.m_hDC);<br />
<br />
  //Clear the background...<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 />
  //Paint the area with a grid...<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 />
  //Draw a static rectangle<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!

Shog⁹1-Dec-05 10:56

Shog⁹

1-Dec-05 10:56

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...

Alberto_Canabal2-Dec-05 7:29

Alberto_Canabal

2-Dec-05 7:29

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)

to send data from parent window to child window

Shog⁹2-Dec-05 7:51

Shog⁹

2-Dec-05 7:51

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):

// ... regular GDI calls
{
   using namespace Gdiplus;
   Graphics gfx(dc.m_hdc);
   gfx.Clear(Color::Black);
   // ...
}
// ... gfx goes out of scope, continue w/ regular GDI calls

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...

sheshidar29-Nov-05 3:28

sheshidar

29-Nov-05 3:28

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

Re: to send data from parent window to child window

Cedric Moonen29-Nov-05 3:47