|
David,
First of all thx for your kind response.
But, I think you have read the code a bit wrong way withing the limit of my knowledge.
Randor wrote: Your due time is set to the minimum 0xA value (one NT quantum).
This is wrong because I set the initial due time and period as follows at line 15-16
#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 1)
#define WAITABLETIMER_DUETIME_INITIALLY (0)
It is the period that set to 0xA, not the initial due time.
The initial due time and period is intentionally set to 0 and 0xA to fire the timer 'immediately first time and ,after then, in the period of every 0xA milliseconds'.
Because of 'immediate due time', the timer gets signaled 'immediately' literally, and therefore 'case WAIT_OBJECT_0 + 1:' statement is the first statement executed without any delay.
Then socket Connect fails with WSAEWOULDBLOCK error and finally CWT call returns TRUE in sequence.
So, the overall code flow is like this:
pWTDlg->m_hTimerRC = CreateWaitableTimer(NULL, FALSE, NULL);
bRet = SetWaitableTimer(pWTDlg->m_hTimerRC, 0, 0xA, NULL, NULL, NULL);
pWTDlg->m_bCreated = sock.Create();
pWTDlg->m_bConnected = sock.Connect(...);
bRet = CancelWaitableTimer(pWTDlg->m_hTimerRC);
Since the last CancelWaitableTimer returns TRUE, it should stop the timer right away, but the timer gets signaled just one more time. That's the issue!
Questions here are
- Why is the timer not stopped even after CWT returns TRUE?
- Why is the timer always signaled just one more time, not two or three and so on even if I admit the timer can be signaled more times after CWT returns TRUE(of course, I don't admit this, but just for the discussion of this issue, though)?
- What's the use of CWT if it is not guaranteed to stop the timer immediately? I'd rather set INFINITE due time and/or INFINITE period for SWT instead of using CWT.
I hope I miss something but unfortunately I don't know what are they.
Please be very specific and detail explaining what's going on about this issue.
regards
|
|
|
|
|
Hi,
Yes, by setting the initial due time to zero the waitable timer becomes immediately signaled. When the timer becomes signaled an APC is queued on your thread. When an APC is queued on your thread the kernel object representing the timer object has its reference count incremented. When you call CancelWaitableTimer if an APC is queued on your thread... a single APC is dequeued and the reference count is decremented by one and the timer is NOT cancelled.
Follow the instructions in my previous post to cancel your waitable timer.
Other thoughts... You can achieve the one-time timer fire by simply setting the
_In_ LONG lPeriod, argument to zero.
Best Wishes,
-David Delaune (MSFT)
|
|
|
|
|
Can you clearly explain why the code below triggers the timer twice from time to time, say once in 5-10 executions?
MSDN does not explain this weird phenomenon at all.
#if !defined(BTF)
#define BTF(b) (b ? _T('T') : _T('F'))
#endif
#if !defined(ERR)
#define ERR(b, d) (b ? 0 : d)
#endif
BOOL CWTApp::InitInstance()
{
CWinApp::InitInstance();
HANDLE hTimer = CreateWaitableTimer( NULL, FALSE, NULL );
BOOL bRet;
DWORD dwErr;
#define WAITABLETIMER_DUETIME_INITIALLY (0)
#define WAITABLETIMER_PERIOD (USER_TIMER_MINIMUM * 200)
#define SLEEP_BEFORE_CWT Sleep(50)
LARGE_INTEGER DueTime;
DueTime.QuadPart = WAITABLETIMER_DUETIME_INITIALLY;
bRet = SetWaitableTimer(hTimer, &DueTime, WAITABLETIMER_PERIOD, NULL, NULL, FALSE);
ATLTRACE(_T("SetWaitableTimer_1(hTimer)=%c/%d\n"), BTF(bRet), ERR(bRet, GetLastError()));
dwErr = WaitForSingleObject(hTimer, INFINITE);
ATLTRACE(_T("Timer(1) was signaled. dwErr=%d\n"), dwErr);
SLEEP_BEFORE_CWT;
bRet = CancelWaitableTimer(hTimer);
ATLTRACE(_T("CancelWaitableTimer(hTimer)=%c\n"), BTF(bRet), ERR(bRet, GetLastError()));
dwErr = WaitForSingleObject(hTimer, INFINITE);
ATLTRACE(_T("Timer(2) was signaled. dwErr=%d\n"), dwErr);
bRet = CloseHandle(hTimer);
return FALSE;
}
modified 23-Nov-13 14:27pm.
|
|
|
|
|
I am trying to extract the functions in a module by using the DBGHELP.LIB functions and loading only the PDB.
I can't seem to get SymEnumSymbols to invoke the callback at all. The SymEnumSymbols function returns 'success' as if it had done something. Trying various combinations of 'options' using SymSetOptions has not yielded results either. When I search The Internet almost always the result/examples seem to come back with examples where the EXE is loaded and running and has been attached to or at very least the process handle has been obtained.
Is having the process handle of the running EXE a requirement Microsoft has completely forgotten to state while using this 'Debug' library?
Thanks.
I need a 32 bit unsigned value just to hold the number of coding WTF I see in a day …
|
|
|
|
|
|
I had few CBitmapButton(s) on a CDIalogBar, but I had noticed that they are not react on Enter key, only on mouse click ? How can I workaround in order to react on enter key ? Thank you.
|
|
|
|
|
Where is the focus when you press the enter key?
Veni, vidi, abiit domum
|
|
|
|
|
On the CBitmapButton, of course 
|
|
|
|
|
I know what you are trying to say, that the focus is stealing by CMainFrame, but I must say that CBitmapButton react on "SPACE" key, so that is the prove that the button had th focus ...
|
|
|
|
|
Flaviu2 wrote: I know what you are trying to say
Actually, I was not trying to say anything, merely asking the obvious question. I had a good root through the documentation for this control and cannot find anything in MSDN that explains what is supposed to happen. I know that in a normal dialog it will work this way, but I don't have MFC so cannot make a sample to test what you are trying to do.
Veni, vidi, abiit domum
|
|
|
|
|
Ok, I understand. Thank you for your concern.
|
|
|
|
|
hi all,
I am get window text like this in my function it works fine for multibyte data but fails in case of Unicode data.
HWND hWnd;
char string [256]={_T('\0')};
::SendMessage(hWnd, WM_GETTEXT, 255, (LPARAM)string);
and
TCHAR szBuffer[MAX_PATH] = {_T('\0')};
SendMessage(hWnd, WM_GETTEXT, sizeof(szBuffer) / sizeof(TCHAR), (LPARAM)szBuffer);
please help me to get the Unicode data.
thank in advance.
|
|
|
|
|
I have used the same code as you have above to receive the Unicode text from a window. Are you sure you set the project options to select a UNICODE build?
Veni, vidi, abiit domum
modified 15-Nov-13 9:02am.
|
|
|
|
|
|
Hi all,
I am getting a weird stack overflow after calling the MFC function SetLocalTime. There is no code to step into and no call stack. I am using Visual Studio 2008 on Windows CE.
Here is my code:
void OnBnClickedButtonSet()
{
SYSTEMTIME time, new_time;
GetLocalTime(&time);
//get the date info
time.wYear = static_cast<WORD>(i_year);
time.wMonth = static_cast<WORD>(i_month);
time.wDay = static_cast<WORD>(i_day);
//get the time info
DWORD ret = m_Time.GetTime(&new_time);
if (ret == GDT_VALID)
{
time.wHour = new_time.wHour;
time.wMinute = new_time.wMinute;
time.wSecond = new_time.wSecond;
time.wMilliseconds = 0;
}
else
{
TRACE(_T("not a time format\n"));
return;
}
CString str(_T(""));
//set the date and time
if (!SetLocalTime(&time))
{
str.Format(_T("system time error = %d. \n"), GetLastError());
TRACE(str);
return;
}//here the stack overflow message shows up; it only happens the first time i turn the unit on and if the user chooses new values only for the date (no stack overflow when setting the time).
}
SetLocalTime doesn't return an error and sets the chosen values for date/time, even if WindowsCE crashes and it needs restarting. After restarting, the date and time can be set again without any problems...
The Disassembly Window points here: "40060198 stmdb sp!, {r0, r4, r5, lr}". I don't know if this is helpful or not...
I tried SecureZeroMemory(&time, sizeof(time)) before GetLocalTime(&time) but no change.
Thanks in advance for your help.
CB
modified 14-Nov-13 10:34am.
|
|
|
|
|
Sounds like a possible recursion issue. What happens if you comment out the call to SetLocalTime()?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 14-Nov-13 15:17pm.
|
|
|
|
|
The stack overflow message doesn't appear but the new date doesn't get set.
CB
|
|
|
|
|
After SetLocalTime() is called, how many times does OnBnClickedButtonSet() get called?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Only one time..The user inputs the day, month and year and/or time and then presses on Set button which calls SetLocalTime().
|
|
|
|
|
Yes,I know... I was thinking that maybe SetLocalTime() calles a hidden WM_something that gives the recursion issue? Do you know if this could be the case? I couldn't find anything by searching on google or reading the function description on microsoft help page...
|
|
|
|
|
corina.beer wrote: Do you know if this could be the case?
Set a breakpoint and find out.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
The problem was calling a delete function on a timer in my base class... I have removed that function and Set button works all the time. If I put the function back on timer, the stack overflow message shows up again.
Thanks everyone for your suggestions.
CB
|
|
|
|
|
This just about points to passing bad data to SetLocalTime(), any way you can check it prior to sending it to SetLocalTime()?
Are you sure m_Time.GetTime(&new_time) is returning a valid time every time (keep in mind the debugger will initialize uninitialized data but this won't be the case in the release version)?
|
|
|
|
|
Thanks.
Stack overflow happens in release mode as well.
Yes, I was thinking of that too. I checked with a breakpoint and all the values for time were all right - no weird looking data...I will run in in Debug and put a TRACE with all the time values to make sure. Also maybe calling UpdateData before SetLocalTime might help? ...I will try that too.
|
|
|
|
|
corina.beer wrote: I checked with a breakpoint and all the values for time were all right - no weird looking data...I will run in in Debug and put a TRACE
 You can't break and look at values on a release version (data will be bogus).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
