View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003355JEDI VCL00 JVCL Componentspublic2005-12-11 03:562006-09-29 07:52
ReporterujrAssigned Toobones 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.00 
Target VersionFixed in Version3.30 
Summary0003355: TJvScheduledEvents - use WM_TIMECHANGE
DescriptionAs the component already allocates its own window for processing schedules it might as well recompute all schedules if the system time changed by using WM_TIMECHANGE.

Thanks!
TagsNo tags attached.

Activities

obones

2006-04-04 05:56

administrator   ~0008878

I don't see the point of reacting to that event, the local time is tested everytime the thread is running through its main loop.
Hence I don't understand your need here. Could you provide more details?

ujr

2006-04-04 06:45

reporter   ~0008887

It is a matter of actually *recomputing* schedules, aka timestamps.
Let's suppose I have a schedule which should fire every day at 15:00. At some time after 15:00 the clock is changed for whatever reason to a time before 15:00. I would expect that the schedule fires another time at 15:00 according to the current time. However, since schedules/timestamps are computed at start that supposed schedule would fire not until the next day.

In my (C++) program I act on WM_TIMECHANGE by
  if (JvScheduledEvents) {
    JvScheduledEvents->StopAll();
    JvScheduledEvents->StartAll();
  }

I should have elaborated more on that "recompute" in my initial report - sorry.

obones

2006-04-14 08:55

administrator   ~0009119

This is now fixed in CVS, use version 1.31 of JvScheduledEvents.pas

ujr

2006-04-25 11:18

reporter   ~0009183

Version 1.31 is not available yet - please check in.

I'm very much interested in how you solved it. In another project of mine I had to realize that it is not always feasible to restart (*all*) schedules. Actually only those running should be restarted.
Have you considered that?

Thanks!

obones

2006-04-26 00:48

administrator   ~0009185

Yes it is available. However, there are two things:

1. The anonymous server is behing: See http://sourceforge.net/docs/A04/ for details.
2. We migrated to SVN. So the revision in SVN you want is revision 10498.

As to your question, no I did not take that into account, but it should not matter. If there is a problem and you manage to create a small sample application, please create a NEW issue with this.

ujr

2006-07-10 16:20

reporter   ~0009783

Sorry for not opening a new issue - I strongly believe it should be handled here. Besides I still miss a new version :-(

The point of my last post is actually pretty simple. If I have a couple of schedules that are running, a WM_TIMECHANGE restarts all schedules - the are recomputed and will fire as they are due. Fine. But what if the logic of my program deactivates (stops) all schedules (which are responsible for a show control and shall not fire during pause or stop of show)? A WM_TIMECHANGE, caused by whatever source, would restart the stopped schedules! This is probably worse than ignoring WM_TIMECHANGE at all, isn't it?

As an example - the WndProc as I use it currently is:
{$IFDEF VCL}
procedure TJvCustomScheduledEvents.WndProc(var Msg: TMessage);
var
  b: Boolean;
begin
  with Msg do begin
    { WM_TIMECHANGE patch starts }
    if Msg = WM_TIMECHANGE then begin
      { all schedules are treated equally }
      if (FEvents.Count > 0) then begin
        b := FEvents[0].State <> sesNotInitialized;
        StopAll;
        if b then
          StartAll;
      end
    end else
    { WM_TIMECHANGE patch ends }
    if Msg = CM_EXECEVENT then
      Dispatch(Msg)
    else
      Result := DefWindowProc(Handle, Msg, WParam, LParam);
  end;
end;
{$ENDIF VCL}

which is still not the perfect thing, because all schedules are treated equally.
That suits the needs of my application, but to do it correctly, one should only restart those schedules that are running.
And it probably should be protected in the general case by a critical section to prevent race conditions, ...

obones

2006-09-29 07:52

administrator   ~0010250

A better solution is now in SVN.

Issue History

Date Modified Username Field Change
2005-12-11 03:56 ujr New Issue
2006-04-04 05:56 obones Note Added: 0008878
2006-04-04 05:56 obones Status new => feedback
2006-04-04 06:45 ujr Note Added: 0008887
2006-04-14 08:55 obones Status feedback => resolved
2006-04-14 08:55 obones Resolution open => fixed
2006-04-14 08:55 obones Assigned To => obones
2006-04-14 08:55 obones Note Added: 0009119
2006-04-25 11:18 ujr Status resolved => feedback
2006-04-25 11:18 ujr Resolution fixed => reopened
2006-04-25 11:18 ujr Note Added: 0009183
2006-04-26 00:48 obones Status feedback => resolved
2006-04-26 00:48 obones Resolution reopened => fixed
2006-04-26 00:48 obones Note Added: 0009185
2006-07-10 16:20 ujr Status resolved => feedback
2006-07-10 16:20 ujr Resolution fixed => reopened
2006-07-10 16:20 ujr Note Added: 0009783
2006-09-29 07:52 obones Status feedback => resolved
2006-09-29 07:52 obones Fixed in Version => Daily / SVN
2006-09-29 07:52 obones Resolution reopened => fixed
2006-09-29 07:52 obones Note Added: 0010250