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
0003354 [JEDI VCL] 00 JVCL Components major always 2005-12-11 03:55 2006-10-06 02:49
Reporter ujr View Status public  
Assigned To obones
Priority normal Resolution fixed  
Status resolved   Product Version 3.00
Summary 0003354: TJvScheduledEvents runtime creation
Description This 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.
Additional Information
Tags No tags attached.
Attached Files zip file icon SchedBug.zip [^] (4,289 bytes) 2006-04-04 07:32

- Relationships

-  Notes
(0008204)
ujr (reporter)
2005-12-11 06:51

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.
(0008213)
ujr (reporter)
2005-12-13 03:15

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!
(0008880)
obones (administrator)
2006-04-04 05:59

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.
(0008904)
ujr (reporter)
2006-04-04 07:47

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
(0009495)
obones (administrator)
2006-06-08 08:13

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.
(0009735)
obones (administrator)
2006-06-30 06:56

Any news on my proposed change?
(0009767)
marcelb (manager)
2006-07-04 10:35

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;
---
(0009782)
ujr (reporter)
2006-07-10 16:10

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.
(0010249)
obones (administrator)
2006-09-29 07:38

ujr, have you been able to test the fix from marcelb?
(0010301)
obones (administrator)
2006-10-06 02:49

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


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