Project JEDI - Issue Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003355 [JEDI VCL] 00 JVCL Components feature always 2005-12-11 03:56 2006-09-29 07:52
Reporter ujr View Status public  
Assigned To obones
Priority normal Resolution fixed  
Status resolved   Product Version 3.00
Summary 0003355: TJvScheduledEvents - use WM_TIMECHANGE
Description As 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!
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0008878)
obones (administrator)
2006-04-04 05:56

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?
(0008887)
ujr (reporter)
2006-04-04 06:45

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.
(0009119)
obones (administrator)
2006-04-14 08:55

This is now fixed in CVS, use version 1.31 of JvScheduledEvents.pas
(0009183)
ujr (reporter)
2006-04-25 11:18

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!
(0009185)
obones (administrator)
2006-04-26 00:48

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.
(0009783)
ujr (reporter)
2006-07-10 16:20

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, ...
(0010250)
obones (administrator)
2006-09-29 07:52

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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker