|
You are correct when you say that your proc wont be called every 1 mSec, far from it in fact. So, there are two ways of looking at this:
1) Finding out what the timing actually is. This can easily be done with the excellent CPerfTimer class by Dean Wyant dwyant@mindspring.com. I think it is available on codeproject.com.
2) Improve the timer resolution and accuracy. This can be done quite simply using multimedia timers. You should be able to get a lot better accuracy than you get with a standard windows timer but you might not get the 1mSec timing that you require. I have some info/code frags on using multimedia timers if you like.
Hope this helps.
Tony
|
|
|
|
|
Thanks for the pointer. I reimplemented the timer using a multimedia timer (using an example I found on the web). It seems vastly better than what I had before.
But...my question still remains.
Does anyone know how to use the Visual Studio Profiler?
|
|
|
|
|
wings2 wrote: From what I understand, this timer should trigger every 1 ms.
No way Windows can deliver that frequency. SetTimer works reasonably well for ranges over half a second, not milliseconds.
Anyway, if you are looking for a profiler, I suggest GlowCode[^] - has a free trial period. Not sure if it works with VC6, though.
|
|
|
|
|
wings2 wrote: I created a timer that looks like:
m_UpdateTimer = SetTimer (1, 1, NULL);
From what I understand, this timer should trigger every 1 ms.
Wishful thinking, but since Windows is not a RTOS, it's just not possible. The best you could hope for is about 15ms.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I'll save you some trouble...
There's almost no chance whatsoever that your routing is getting reliably called every millisecond. Like WM_PAINT, WM_TIMER is only generated if the message queue is quiet.
If you just want it "as often as I can, and at most 1000 times a second", then you might be lucky.
Otherwise, you're going to have to use a separate thread, and some mechanism like waitable timers. If you are *REALLY* insistent on the interval, then windows is not going to be real time enough for deterministic real time behaviour...
Hopefully this gives you some parallel thoughts, even if it went nowhere near answering your question,
Iain.
|
|
|
|
|
Nemanja Trifunovic wrote: No way Windows can deliver that frequency. SetTimer works reasonably well for ranges over half a second, not milliseconds.
Well, not exactly.
I just tested SetTimer, and the minimum increment it works with is 1/100 of a second (not 1/1000). But with increments in multiples of 1/100 of a second it is extremely accurate. Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
An interval less than 10 milliseconds is treated as 10. An interval that is not a multiple of 10 is bumped up to the next multiple of 10.
The docs on SetTimer mention a USER_TIME_MINUMUM but #defining this to 1 didn't seem to matter. The minimum increment was still ten milliseconds. (OS - Win 2000).
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
Come to think of it, being off by an average of 1/50000 of a second could be attributed to the overhead of OutputDebugString(GetCurrentTime()).
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
ummm - are they using the same clock?  I think you'd need to compare the values against a
real-time clock.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Force Code wrote: Try it out for yourself. Set an interval of 10 (milliseconds) and every WM_TIMER msg, OutputDebugString(GetCurrentTime()). The millisecond output will increment by 10 for at least fifty iterations before being off by one.
Mark Salsbery wrote:
ummm - are they using the same clock? I think you'd need to compare the values against a real-time clock.
I just tried it with QueryPerformanceCounter. It showed the WM_TIMER msgs were only off by an average of .0032%.
According to the SDK docs, QueryPerformanceCounter returns TRUE "if the installed hardware supports a high-resolution performance counter" (which it did in my case).
-- modified at 16:52 Tuesday 19th June, 2007
|
|
|
|
|
Well that's good news.
The most troubles I've ever had programming (and I'm still dealing with it now) is trying to
get any kind of close-to-real-time timing on a PC.
On my dual Xeon XP development machine, I get very precise timing. On another P4 Windows 2000
box I have, the timing is horrible. How much is OS, how much is hardware, I still have no idea.
I do know I have to synchronize certain timings between them (and more importantly, between
customer machines)) in real-time and it's a nightmare
Some possibly interesting articles...
Time is the Simplest thing...[^]
Precision is not the same as accuracy[^]
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark Salsbery wrote: Some possibly interesting articles...
Time is the Simplest thing...[^]
Precision is not the same as accuracy[^]
From Precision is not the same as accuracy[^]: "If you're looking for high accuracy, then you'd be better off playing around with the QueryPerformanceCounter function."
|
|
|
|
|
Right I'm dealing with varying 3rd party hardware clocks. 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Force Code wrote: I just tried it with QueryPerformanceCounter. It showed the WM_TIMER msgs were only off by an average of .0032%.
Correction: It was actually .0032, or .32%.
|
|
|
|
|
Hi,
We have an install batch file which needs to run at administrator level on all machines on our network. Is there a way to temporarily switch to administrator level programmatically?
Cheers,
Tony
|
|
|
|
|
You want to challenge windows security !
|| ART OF LIVING ||
|
|
|
|
|
Check out LogonUser(), ImpersonateLoggedOnUser(), and CreateProcessAsUser().
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
First off, I'm running Visual C++ 6.0. I've got a DLL project that runs a batch file that uses the Message Compiler to create the .rc and .h file from a .mc file, then uses the Resource Compiler to create the .res file, and finally uses the linker to create the DLL from the .res file. What I'd like to do is to get the VERSIONINFO information into the .res or .rc file so that we can see this version information in the DLL when the user right clicks on the DLL in Explorer and selects Properties. Does anyone know a way to do this?
|
|
|
|
|
I don't know of a prepackaged way, but you should do it with a bit of programming.
1/ Make a resource only dll, and create the VERSIONINFO in it the way you'd like.
2/ Make a small program to merge the version resource into the MC created one - Have a look at BeginUpdateResource, UpdateResource, EndUpdateResource for the MC one, and FindResource et al for the versioninfo one.
3/ Add the mergeres.exe program to your custom build steps.
I didn't say it would be eeeeasy....
Iain.
|
|
|
|
|
What and where is mergeres.exe?
|
|
|
|
|
It's the program you write for yourself in step 2...
Iain.
|
|
|
|
|
Hi
In one of my application crashes sometime.
I used _CRTDBG_MAP_ALLOC and _CrtMemState() to set set points in various location of application and compared to find the leak. Sometime it alerts for memory leaks and sometimes not.
Could any way to locate the exact file/line which creates the problem?
Also I like to know can I use the _CRTDBG_MAP_ALLOC in AIX platform, or any equivalent?
Thanks
Krishnakumar
|
|
|
|
|
Do you want to find why your app crashes or find memory leaks?
Mamory leaks don't necessarily cause crashes...
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I want to find why my applicaiton is failing. But my primary investigation there some code which are free() memory which are not properly allocated. I used Visual studio 6.0 debugger to do so.
So anything which helps to point out from which location/line/file the problem occurs will be helpful.
thanks
Krishnakumar
|
|
|
|
|
|
krishnakumar75 wrote: I used _CRTDBG_MAP_ALLOC and _CrtMemState() to set set points in various location of application and compared to find the leak. Sometime it alerts for memory leaks and sometimes not.
Where you do checkpoints can effect the results. You need to make sure no allocations that
aren't freed are made between checkpoints.
I prefer to use a static class object so I can catch all leaks (except possibly any in other
static objects) that occur over the lifetime of the app.
I use this in one (usually the main) source module:
#ifdef _DEBUG
class _MemStateCheck
{
public:
CMemoryState oldMemState, newMemState, diffMemState;
_MemStateCheck();
~_MemStateCheck();
};
_MemStateCheck::_MemStateCheck()
{
oldMemState.Checkpoint();
}
_MemStateCheck::~_MemStateCheck()
{
newMemState.Checkpoint();
if( diffMemState.Difference( oldMemState, newMemState ) )
{
TRACE( "************************\n" );
TRACE( "Memory leaks Detected\n" );
TRACE( "************************\n" );
diffMemState.DumpStatistics();
diffMemState.DumpAllObjectsSince();
}
else
{
TRACE( "************************\n" );
TRACE( "No memory leaks Detected\n" );
TRACE( "************************\n" );
}
}
_MemStateCheck MemCheckObj;
#endif //#ifdef _DEBUG
For MFC apps, I include this at the top of every source (cpp) file (under any #include lines):
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
To get file/line numbers for malloc, you should use _malloc_dbg instead of malloc (it will use the regular malloc in non-debug builds):
void *p = _malloc_dbg(128, _NORMAL_BLOCK, __FILE__, __LINE__ );
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
