Home Dashboard Directory Help
Search

WPF InputEventArgs.Timestamp should encapsulate the DateTime conversion by Moby Disk


Status: 

Active


5
0
Sign in
to vote
Type: Suggestion
ID: 520472
Opened: 12/15/2009 8:36:41 AM
Access Restriction: Public
0
Workaround(s)
view

Description

The WPF InputEventArgs class provides a public Timestamp value that is an int. There is no documentation on what that int means. It turns out that the value is a pass-through from the Windows API time stamp as described by the Win32 GetMessageTime() function. Timestamp should be deprecated, and a new property should be added that encapsulates the conversion.

The code should look something like this:

/// <summary>
/// Time when this event occurred.
/// </summary>
public DateTime ActualTimestamp
{
    get
    {
        DateTime dt = DateTime.Now;
        dt.AddMilliseconds(Environment.TickCount - Timestamp);
        return dt;
    }
}

MSDN documentation on InputEventArgs.Timestamp:
http://msdn.microsoft.com/en-us/library/system.windows.input.inputeventargs.timestamp%28VS.100%29.aspx

Actual meaning of the value:
http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/acccf7f5-92e0-4927-8528-5ae34025ae8c

GetMessageTime() function:
http://msdn.microsoft.com/en-us/library/ms644939%28VS.85%29.aspx
Details
Sign in to post a comment.
Posted by Alexander Hoisl on 12/5/2013 at 3:26 AM
Thank you very much for that code, it really helped me out!
However, I guess there is a bug in the code, the line updating the "dt" variable should be the following (AddMilliseconds does not change the instance):

dt = dt.AddMilliseconds(Timestamp - Environment.TickCount);
Posted by Microsoft on 7/30/2012 at 10:20 PM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.
Posted by fastcat on 6/16/2010 at 5:30 PM
A note for those finding this page via google: the math in the example above (and the forums thread) is wrong, it needs to be Timestamp - Environment.TickCount, otherwise it will be reporting times in the future, not the past.
Posted by Microsoft on 12/16/2009 at 12:50 AM
Thank you for your feedback, we are currently reviewing the feedback you have submitted.
Sign in to post a workaround.