views:

284

answers:

1

I'm using a usoft date time picker control in a dialog box. I started by setting the format to "HH':'mm' 'ddddMMMdd','yyyy" and the current local date & time using DTM-SETSYSTEMTIME. If the user changes any field in the control, the program can not reset the date and time in the control using DTM-SETSYSTEMTIME although SendMessage returns a 1. As far as I can tell, the dialog box returns false (zero) to any notifications it receives concerning the control.

The problem as described above is how I first became aware of it but it's actually much simpler. I did two DTM-SETSYSTEMTIME calls in a row and only the first one took affect. The second in the following example does not get put into effect even though the status is returned is 1.

  hwnd = GetDlgItem (hDlg, IDC_SUN_STAT_DATE_TIME);
  Status = SendMessage (hwnd, DTM_SETFORMAT,0,(LPARAM)"HH':'mm' 'ddddMMMdd','yyyy");
  Status = SendMessage (hwnd, DTM_SETSYSTEMTIME,GDT_VALID, (LPARAM)&systimeTime);
  systimeTime.wHour += 2;
  Status = SendMessage (hwnd, DTM_SETSYSTEMTIME,GDT_VALID, (LPARAM)&systimeTime);

It appears that only the first DTM-SETSYSTEMTIME is put into effect, following ones are ignored.

What do I have to do to change/reset the date/time in the control? Or (more likely) what am I doing wrong?

A: 

I have cut and pasted your code into my own program in Visual C++ 6.0, and it works perfectly for me. If I comment out the second DTM_SETSYSTEMTIME, I get a time that is two hours earlier. There is something in the code you're not showing us.

Edit: Since you've selected this answer, I might as well make it accurate. I've verified your comments with my own program.

You're having a problem with the interactions of unexpected behaviors of the date/time picker:

  1. The SYSTEMTIME structure requires a full 4-digit year.
  2. The date/time picker does not indicate an error if you use DTM_SETSYSTEMTIME with an invalid SYSTEMTIME.
  3. Once you've set an invalid SYSTEMTIME, the date/time picker stops responding to further DTM_SETSYSTEMTIME messages. Furthermore it still returns as if it had processed the message properly.
Mark Ransom
Thanks! Knowing that it works for you in the same environment allowed me to figure out what I did wrong. The problem turned out to be an illegal year in my SYSTEMTIME which I had constructed from a tm time (I neglected to take the 1900 offset into account). Evidently DTM-SETSYSTEMTIME accepts an illegal year (and substitutes the current year) if it has no date/time BUT ignores subsequent calls with illegal years. If DTM-SETSYSTEMTIME has given me an error or failed entirely, I would have figured this out long ago. Happy holidays!
Mike D
Well, to be complete DTM_SETSYSTEMTIME accepts the first illegal SYSTEMTIME and ignores subsequent illegal ones BUT will later respond to proper SYSTEMTIMEs.
Mike D