|
|
i need to do this within the calling app, not from the shell.
|
|
|
|
|
Do you need this for trouble-shooting or all the time? ...because it sounded like you just needed for troubleshooting, in which case... why not use the shell options?
..but otherwise, you can always try reassigning the stream using freopen[^].
Here's an actual example...
http://support.microsoft.com/kb/58667[^]
|
|
|
|
|
Albert Holguin wrote: Do you need this for trouble-shooting or all the time
all the time.
|
|
|
|
|
Ok, try out the freopen option... hopefully that gets the job done.
|
|
|
|
|
|
Hey out there,
i'm heared that the use of timers in large projects is bad for performace.
So is this true?
I'm wondering, because i have done a new control using VC++/MFC and i use one timer in there.
The timer only is created and the first time it's called i terminate it.
Now someone said to me that i sould use ::GetTickCount() instead and save the first value and compare it again and again.
It look more performance hungry than my timer solution.
So what's your oppinion?
Please don't answer something like i should do a test, i haven't so much time to test such things.
And please answer only real facts and not only stuff like "i like timers more because i like it more" or "i like the TickCount solution more".
Hope for a good discussion 
|
|
|
|
|
I think it largely depends on specific circumstances... for example, I've used timers to update fields that change at extremely high-rates. Under those circumstances, timers were actually a HUGE improvement on an old system that updated UI fields as often as new data was available.
So my opinion is... use what works for you.
|
|
|
|
|
Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't.
Your question isn't so much about timers being bad in general, but about the proper use of one. The size of the application has nothing got to do with it at all.
As for our opinion: it's impossile to tell if you're not more specific. It's ironic how you're asking for specific answers, yet fail to offer the minimal information required to answer the question properly. There are plenty of timer interfaces that you might use, you didn't specify yours.
As for GetTickCount, that is a bad way to measure performance since it only checks the system time, not the time your application uses: if other applications are running at the same time and slowing the whole system down, you'll get much higher values! If your purpose is to measure program performance, a more suitable function to use would be clock()[^]
|
|
|
|
|
Stefan_Lang wrote: Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't.
I like that... 
|
|
|
|
|
I'd like too.
Using it correctly, the timer has a good performance.
Sometimes, GetTickCount is a good solution, but it wastes too many cpu time to do this.
On the other hand, Timer provide a good way to let you know when times out, and you can do anything in the period.
|
|
|
|
|
What are you talking about? Timers do not have bad performance! Timers don't waste CPU! All they do is read some hardware register. We're talking nanoseconds here!
Keep in mind that almost all timer functions can measure at a resolution of only about 20-50ms at best, even though the unit typically used for the result value is in ms. Calling them more often then 100 times a second is therefore utterly pointless and stupid. Calling them less often will not result in any performance loss that you are able to measure!
|
|
|
|
|
I am so sorry about you misunderstood my words, my English is very poor!
I agree with you about timers don't waste CPU, because it provides a way that can be waited, when times out, the callback functions is invoked.
About nanoseconds measure, clock() maybe right, but windows gives high-precision clock to us for API, it is QueryPerformanceFrequency().
But I think C3D1 just want to know which way is more performance in GetTickCount and Timer.
I think you are a good guys, Can I make friends with you ? 
|
|
|
|
|
I understand that english is not your first language - no need to apologize.
As for "waiting" or "callback", I don't see the OP asking about that at all. If his question were about waiting, he should use Sleep()[^] , not timer functions.
I understand the question as one about program performance, i. e. the CPU time it uses. Since the indicated functions don't measure CPU time, their properties are irrelevant. That is why I suggested clock()[^] .
You are correct that it it possible to use higher precision timers. However, most of the time the standard timers are sufficiently accurate for fixing performance issues. That said, the OP suggested comparing times "again and again", implying constant polling - and that doesn't make sense at all! Therefore I made my initial statement about 'inappropriate use' of timers.
There is one other possible scenario that the OP may be referring to: waiting for an operation to finish, but not for longer than a predetermined amount of time. If that is the case, I'd suggest using WaitForMultipleObjects()[^] .
|
|
|
|
|
Sorry, maybe i misunderstood the OP's question.
I understand the question as the OP want to delay executing.
You are right, if he want to waiting, he should use Sleep.
Through this, I think you are a good programmer who understand OS well, nice to meet you !
There is another question, sometimes you just want to delay executing, Sleep, Timers, or GetTickCount all is right.
Sleep don't waste any CPU time. GetTickCount does it. But sometimes, free loop just like GetTickCount is a performance way to wait a predetermined a mount of time, like SpinLock.
What do you think about it.
|
|
|
|
|
No! Don't use GetTickCount if all you want to do is wait. Ever.
What it amounts to is a busy loop that eats the entire CPU time as it is repeated hundreds of millions of times per second! You're slowing other programs by doing that, because one CPU core will be completely locked by your program! If your CPU only has one core, the Computer will freeze! If your program has any GUI parts that the user interacts with, these will freeze also. A user sitting in front of the computer may think the program is crashed, and restart it.
Not to mention that a modern OS has many tasks running in the background that you are preventing from working!
Do not needlessly eat CPU time!
|
|
|
|
|
Yeah, I can't agree with you any more !
Sometimes, i should delay a short time precisely, I think free loop is useful. just like wait some uart data in real OS.
May I get your email, i just want to contact with you frequently!
|
|
|
|
|
Hi,
I am writing a COM component using ATL. I am willing to add some dialog boxes and some functionality from MFC. How can I add MFC support?
|
|
|
|
|
|
there is not any link to do so .. plz guide to resolve the issue
|
|
|
|
|
john5632 wrote: there is not any link to do so plz guide to resolve the issue
To resolve what issue? All you have said is that you are interested in using MFC with COM. I provided a link to MSDN where the subject is covered. If that does not help then try searching for a more specific item, or asking a more specific question.
|
|
|
|
|
I followed the steps defined in THIS ARTICLEe. Now the problem is that I have commented dllmain function which is entry point of dll Now the overridden function Ininstance and ExitInstanced is not getting called.
|
|
|
|
|
I have no way of checking whether that article is correct or not, I suggest you try some feedback to Microsoft.
|
|
|
|
|
Dear all:
I use two global variables UINT g_PreUsedSize and g_CurUsedSize in WindowProc callback function.
When I touch on my device, I will get WM_INPUT message continuous in WindowProc callback function,
and get a result->active_touch_count, and set it to g_CurUsedSize.
When I did not touch on my device, I wanna set 0 to g_CurUsedSize.
LRESULT CALLBACK WindowProc (HWND window_handle, UINT message, WPARAM w_param, LPARAM l_param)
{
LRESULT result (0);
switch (message)
{
case WM_DESTROY:
PostQuitMessage (0);
break;
case WM_SIZE:
{
switch (w_param)
{
case SIZE_MAXIMIZED:
case SIZE_RESTORED:
{
window_width = (float)(LOWORD (l_param));
window_height = (float)(HIWORD (l_param));
}
break;
}
}
break;
case WM_INPUT:
{
UINT data_size (0);
GetRawInputData ((HRAWINPUT)l_param, RID_INPUT,NULL, &data_size, sizeof (RAWINPUTHEADER));
vector<BYTE> data;
data.resize (data_size);
if (GetRawInputData ((HRAWINPUT)l_param, RID_INPUT, &data [0], &data_size, sizeof(RAWINPUTHEADER)) != data_size)
{
OutputDebugString(TEXT("GetRawInputData does not return correct size !\n"));
break;
}
RAWINPUT* raw = (RAWINPUT*)(&data [0]);
if (raw->header.dwType == RIM_TYPEHID)
{
RID_DEVICE_INFO device_info;
UINT info_size = sizeof(RIDI_DEVICEINFO);
GetRawInputDeviceInfo ( raw->header.hDevice, RIDI_DEVICEINFO, (LPVOID)&device_info, &info_size);
if(device_info.hid.dwVendorId = 0x0457)
{
DigitizerData* result = (DigitizerData*)(raw->data.hid.bRawData);
g_CurUsedSize = result->active_touch_count;
BOOL bGot = FALSE;
if(g_CurUsedSize <= 5)
{
if(g_PreUsedSize < g_CurUsedSize)
{
PlaySound(TEXT("C:\\default.wav"),NULL, SND_FILENAME|SND_ASYNC );
}
}
bGot = TRUE;
}
}
if(bGot)
{
g_PreUsedSize = g_CurUsedSize;
}
}
}
result = DefWindowProc (window_handle, message, w_param, l_param);
}
break;
default:
result = DefWindowProc (window_handle, message, w_param, l_param);
break;
}
return result;
}
My question is:
1. How do I know my device send no data in WindowProc, if I did not touch?
Thank for your help, Victor
|
|
|
|
|
cedricvictor wrote: How do I know my device send no data in WindowProc, if I did not touch?
You cannot test for something not happening, only for things that do happen. You could use a flag in your WindowProc, which starts as false and gets set to true if you receive a touch input. At the end of the routine if the flag is still false then set your value to zero.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
