Alternative for TIMERs in MFC??
-
I am having a dialog box application (main dialog box in which many other child dialog boxes are created) in which I am having a closed loop function which does a series of other functions(doing some computations and updating some dialog boxes) continuously untill the user stops. For this we are using TIMERs, but using TIMERs I see there is atleast 10ms delay between the end of first TIMER to the start of next TIMER. We are trying to improve our closed loop frequency and I am not able to reduce this delay?? Is there any other better way rather than using TIMERs, like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started). thanks in advance.
PKNT
-
I am having a dialog box application (main dialog box in which many other child dialog boxes are created) in which I am having a closed loop function which does a series of other functions(doing some computations and updating some dialog boxes) continuously untill the user stops. For this we are using TIMERs, but using TIMERs I see there is atleast 10ms delay between the end of first TIMER to the start of next TIMER. We are trying to improve our closed loop frequency and I am not able to reduce this delay?? Is there any other better way rather than using TIMERs, like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started). thanks in advance.
PKNT
Kiran Satish wrote:
like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started)
That means you need to properly using threads. How are you using timers? How did you use threads?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
I am having a dialog box application (main dialog box in which many other child dialog boxes are created) in which I am having a closed loop function which does a series of other functions(doing some computations and updating some dialog boxes) continuously untill the user stops. For this we are using TIMERs, but using TIMERs I see there is atleast 10ms delay between the end of first TIMER to the start of next TIMER. We are trying to improve our closed loop frequency and I am not able to reduce this delay?? Is there any other better way rather than using TIMERs, like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started). thanks in advance.
PKNT
this is NOT because of the MFC's Timer (which is in fact a wrapper to Win32), but because Windows is NOT a Real Time OS... so you cannot expect much efficiency from there.
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
Kiran Satish wrote:
like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started)
That means you need to properly using threads. How are you using timers? How did you use threads?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain ClarkeYes... I know I haven't used threads in proper way in this particular application ;P . Well I used them in more sumple way, once the user clicks on 'Close Loop' button on one of the dialog boxes, I start a thread that does all the necessary work, but I remember it giving errors when I send/post messages to dialog boxes (but I am not sure) and the interface doesnt respnd anymore to user inputs. Coming to TIMERs, here is how we are using currently-
//This is the code for the close loop user interface button void CAnalysisDlg::OnCloseloop() { CButton *ClButton; HICON icn; ClButton = (CButton *)GetDlgItem(IDB_CLOSELOOP); icn = ClButton->GetIcon(); if(icn == AfxGetApp()->LoadIcon(IDI_CLOSELOOP)) { ClButton->SendMessage(BM_SETIMAGE,IMAGE_ICON,(LPARAM)AfxGetApp()->LoadIcon(IDI_LOOPCLOSED)); if(parent->closeLoop() == FALSE) { ClButton->SendMessage(BM_SETIMAGE,IMAGE_ICON,(LPARAM)AfxGetApp()->LoadIcon(IDI_CLOSELOOP)); } } else { KillTimer(1); parent->Uncheck_Closeloop(); } } //This code goes into parent(main) dialog box BOOL CMainDlg::closeLoop() { //do some intializations and calculations here if(OnAutoMeasure()==FALSE) return FALSE; } BOOL CMainDlg::OnAutoMeasure() { //calculate the frequency of closed loop //do closed loop functions and update other dialog boxes as necessary //if there is nay error it returns false SetTimer(1,1,NULL); return TRUE; } void CMainDlg::OnTimer(UINT nIDEvent) { CButton *ClButton; HICON icn; KillTimer(1); ClButton = (CButton *)tbdisp->GetDlgItem(IDB_CLOSELOOP); icn = ClButton->GetIcon(); if(icn == AfxGetApp()->LoadIcon(IDI_LOOPCLOSED)) { if(closeloopsafety <= NUM_FALSE_RETURN_AUTOMEASURE) { if(OnAutoMeasure()==FALSE) Uncheck_Closeloop(); } else Uncheck_Closeloop(); } CDialog::OnTimer(nIDEvent); }I hope the code wont be too much of confusion :). But that how its basically works now.PKNT
-
this is NOT because of the MFC's Timer (which is in fact a wrapper to Win32), but because Windows is NOT a Real Time OS... so you cannot expect much efficiency from there.
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
Yes.. its true. But I never had much of problems using threads in MFC, they used to work better. But well you can't compare it with other real-time OSes like Linux and other packages that you can get that makes Windows as real-time OS though :) .
PKNT
-
Yes.. its true. But I never had much of problems using threads in MFC, they used to work better. But well you can't compare it with other real-time OSes like Linux and other packages that you can get that makes Windows as real-time OS though :) .
PKNT
but maybe your processor is overloaded in kernel mode...
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
but maybe your processor is overloaded in kernel mode...
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
Good point, but I have 8 cores and I barely use one core at full clock (while running all our applications at the same time) and to say windows is not bad in scheduling processes on multi core systems and distributes evenly if not overloading :omg: .
PKNT
-
I am having a dialog box application (main dialog box in which many other child dialog boxes are created) in which I am having a closed loop function which does a series of other functions(doing some computations and updating some dialog boxes) continuously untill the user stops. For this we are using TIMERs, but using TIMERs I see there is atleast 10ms delay between the end of first TIMER to the start of next TIMER. We are trying to improve our closed loop frequency and I am not able to reduce this delay?? Is there any other better way rather than using TIMERs, like using threads (but the problem is when I tried using threads before, the interface doesnt respond anymore once the thread has started). thanks in advance.
PKNT
from MSDN article: How To Use QueryPerformanceCounter to Time Code Function Units Resolution --------------------------------------------------------------------------- Now, Time, Timer seconds 1 second GetTickCount milliseconds approx. 10 ms TimeGetTime milliseconds approx. 10 ms QueryPerformanceCounter QueryPerformanceFrequency same not so much in MFC but Win32 perhaps? your best resolution is probably 10ms NB multicore breaks simple RDTSC approaches you may read about my old article on timing: http://www.codeproject.com/KB/cpp/precision_timer.aspx[^]
-
Yes.. its true. But I never had much of problems using threads in MFC, they used to work better. But well you can't compare it with other real-time OSes like Linux and other packages that you can get that makes Windows as real-time OS though :) .
PKNT
-
Yes... I agree, but I am not saying about those commercial Linux Distros (like Fedora, Mandrake etc), there are many RTOSes based on Linux, I meant it in the same way I said about Windows RTOS version packages.
PKNT