View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003354JEDI VCL00 JVCL Componentspublic2005-12-11 03:552006-10-06 02:49
ReporterujrAssigned Toobones 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.00 
Target VersionFixed in Version3.30 
Summary0003354: TJvScheduledEvents runtime creation
DescriptionThis is in principal the same as issue 0002623: "TJvSchedulerdEvents blocks in run time component creation", which is not really fixed in version 3.00. Besides I cannot find the announced version 1.28 in CVS - there is only 1.13 (http://cvs.sourceforge.net/viewcvs.py/jcl).

The actual problem is, as far as I examined it, that there is no scheduler thread running at all as long as the component is created dynamically during runtime. Hence, this thread cannot be finished during the finalization.
It seems to be fixed when the thread creation, that is carried out during procedure Loaded will also executed in the TJvSchedulerEvents.Create.
TagsNo tags attached.

Activities

ujr

2005-12-11 06:51

reporter   ~0008204

Well, just found the current source code - version 1.29 of JvScheduledEvents.pas.
I used the wrong address and path (correct is cvs.sourceforge.net/viewcvs.py/jvcl with path below "dev").
Nevertheless the bug still persists.

ujr

2005-12-13 03:15

reporter   ~0008213

Well - I wonder why the event collection is attached during procedure Loaded, not immediately after it has been created. Is there any particular reason?
On the other hand the event collection is removed from the threads watch list just before destroying the events...
Thanks!

obones

2006-04-04 05:59

administrator   ~0008880

Can you test with the latest version, and if the problem is still there, please provide the zipped sources of an application showing the bug.

2006-04-04 07:32

 

SchedBug.zip (4,289 bytes)

ujr

2006-04-04 07:47

reporter   ~0008904

Okay - I attached a small sample application that sets a schedule at 10s after the program has been started. Although the application does not hang on exit, the schedule will not be fired unless I change

---
constructor TJvCustomScheduledEvents.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FEvents := TJvEventCollection.Create(Self);
end;
---

to

---
constructor TJvCustomScheduledEvents.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FEvents := TJvEventCollection.Create(Self);
  { patch begins }
  if not (csDesigning in ComponentState) then
  begin
    {$IFDEF VCL}
    FWnd := AllocateHWndEx(WndProc);
    {$ENDIF VCL}
    {$IFDEF VisualCLX}
    FWnd := QWidgetH(AllocateMessageObject(Self));
    {$ENDIF VisualCLX}
    if AutoSave then
      LoadEventStates;
    InitEvents;
    ScheduleThread.AddEventComponent(Self);
  end;
  { patch ends }
end;
---

which basically copies everything that is done during TJvCustomScheduledEvents.Loaded to the constructor: It initializes events and activates the thread. This is very much related to my note 0008213.

HTH

obones

2006-06-08 08:13

administrator   ~0009495

Why simply not move

ScheduleThread.AddEventComponent(Self);

to the constructor?
To me that is all that is needed. If not then I'll have to look deeper, but I could not have a look at your example today as it is written in C++, either you redo it in Delphi or you wait until I can do it.
In all cases, if the change mentionned above is enough, please let us know.

obones

2006-06-30 06:56

administrator   ~0009735

Any news on my proposed change?

marcelb

2006-07-04 10:35

manager   ~0009767

Hmm, wasn't there some weird issue with the proposed change? Or, rephrasing that, does the damn thing still work if you use the component at design-time? If so, I think the change should be made.

However, I suspect trouble in paradise when Loaded tries to do the exact same thing, and it needs to do that (at least the LoadEventStates) in the Loaded only. So maybe, most of the code in Loaded should be moved to the constructor, with only 'if AutoSave then LoadEventStates;' inside a 'if not (csDesigning in...)':

---
constructor TJvCustomScheduledEvents.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FEvents := TJvEventCollection.Create(Self);
  { patch begins }
  {$IFDEF VCL}
  FWnd := AllocateHWndEx(WndProc);
  {$ENDIF VCL}
  {$IFDEF VisualCLX}
  FWnd := QWidgetH(AllocateMessageObject(Self));
  {$ENDIF VisualCLX}
  if not (csDesigning in ComponentState) then
  begin
    if AutoSave then
      LoadEventStates;
    InitEvents;
  end;
  ScheduleThread.AddEventComponent(Self);
  { patch ends }
end;

procedure TJvCustomScheduledEvents.Loaded;
begin
  inherited Loaded;
  { patch begins }
  if AutoSave then
    LoadEventStates;
  InitEvents;
  { patch ends }
end;
---

ujr

2006-07-10 16:10

reporter   ~0009782

Sorry for taking so long - I was very busy lately.

I'm not experienced in component programming, so I cannot tell if there is anything bad with doing things in Loaded or in the constructor - neither in general nor in this special case.
From my point of view it is not sufficient to add or move
ScheduleThread.AddEventComponent(Self);
to the constructor since it omits the creation of the window (AllocateHwnd) which is used in a PostMessage call from TScheduleThread.Execute and as a detector for WM_TIMECHANGE in another patch of mine (issue 0003355)
For me it looks like the proposal by marcelb should work, but I wasn't able to test it yet.

obones

2006-09-29 07:38

administrator   ~0010249

ujr, have you been able to test the fix from marcelb?

obones

2006-10-06 02:49

administrator   ~0010301

The fix is now in SVN

Issue History

Date Modified Username Field Change
2005-12-11 03:55 ujr New Issue
2005-12-11 06:51 ujr Note Added: 0008204
2005-12-13 03:15 ujr Note Added: 0008213
2006-04-04 05:59 obones Note Added: 0008880
2006-04-04 05:59 obones Status new => feedback
2006-04-04 07:32 ujr File Added: SchedBug.zip
2006-04-04 07:47 ujr Note Added: 0008904
2006-04-14 07:57 obones Status feedback => assigned
2006-04-14 07:57 obones Assigned To => obones
2006-06-08 08:13 obones Note Added: 0009495
2006-06-30 06:56 obones Note Added: 0009735
2006-06-30 06:56 obones Status assigned => feedback
2006-07-04 10:35 marcelb Note Added: 0009767
2006-07-10 16:10 ujr Note Added: 0009782
2006-09-29 07:38 obones Note Added: 0010249
2006-10-06 02:49 obones Status feedback => resolved
2006-10-06 02:49 obones Fixed in Version => Daily / SVN
2006-10-06 02:49 obones Resolution open => fixed
2006-10-06 02:49 obones Note Added: 0010301