View Issue Details

IDProjectCategoryView StatusLast Update
0002688JEDI VCL00 JVCL Componentspublic2005-03-01 09:09
ReporterwdonkerAssigned Touser72 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.00 BETA 2 
Target VersionFixed in Version3.00 
Summary0002688: TJvChangeNotify generates change events even when not Active
DescriptionSetting property Active to false does NOT stop JvChangeNotify from generating change events.
I looked at the coding of procedure JvChangeNotify.Active. It seems to me that setting Active makes the component start generating events, but resetting to Inactive does noet stop it. Don't know how to fix yet but a workaround is to test for Active in the handler of the change event.
Additional InformationThis bug was not present in JVCL 2.00.
TagsNo tags attached.

Activities

user72

2005-02-26 02:43

  ~0006593

I can't reproduce this. Drop a JvChangeNotify and a button on a form. Set up one change notification folder (like "C:\"). Set all Actions to true. Write the following code:

procedure TForm1.Button1Click(Sender: TObject);
begin
  JvChangeNotify1.Active := not JvChangeNotify1.Active;
end;

procedure TForm1.JvChangeNotify1ChangeNotify(Sender: TObject; Dir: String;
  Actions: TJvChangeActions);
begin
  Caption := Format('Change detected: %s',[DateTimeToStr(Now)]);
end;

Make changes to the files in the checked folder (rename, change attributes, copy etc). Does the date/time in the caption change even when Active is set to false?

Note that it could be a few moments before the thread is terminated after Active is set to false (depends on the number of notify objects you have defined).

wdonker

2005-02-26 03:42

reporter   ~0006594

>> Note that it could be a few moments before the thread is terminated after >> Active is set to false

This might be the reason cause my coding looks something like:

    ChangeNotify1.Active := false;
    { Look for first selected item in the filelistview }
    Item := FileListView.Selected;
    while Item <> nil do
      begin
        RenameFile.....
        { Look for next item starting at last index found }
        Item := FileListView.GetNextItem(Item, sdAll, [isSelected]);
      end;
    ChangeNotify1.Active := true;

Renaming the file triggers a ChangeNotify event which in turn causes a rebuild of the listview (disturbing the loop). Maybe a longer pause between inactivating the ChangeNotify and renaming the first file would avoid this problem.

Still, the problem has only occurred since I migrated the program to JVCL 3.00.

user72

2005-02-26 04:53

  ~0006595

> Still, the problem has only occurred since I
> migrated the program to JVCL 3.00.
In version 2, it didn't use an internal thread, so that is probably the reason it works differently. Try unhooking the event that rebuilds the listview before changing Active, i.e:

// unhook event handler
JvChangeNotify1.OnChangeNotify := nil;
try
  JvChangeNotify1.Active := false
  // do processing here
finally
  // rehook handler and activate
  JvChangeNotify1.OnChangeNotify := YourNotifyHandler;
  JvChangeNotify1.Active := true
end;

wdonker

2005-02-26 07:32

reporter   ~0006596

Well I guess that works ok but I prefer a simpler workaround by changing the event handler to

if ChangeNotify1.Active then
   begin
     do some processing
   end;

With either your workaround or mine, there doesn't seem to be any 'added value' in the Active property anymore.

user72

2005-02-27 03:12

  ~0006600

Last edited: 2005-02-27 03:13

> With either your workaround or mine,
> there doesn't seem to be any 'added value'
> in the Active property anymore.
The problem is that since the notification check is running in it's own thread, you will have to give it time to terminate.

However, if you set FreeOnTerminate to false, the call to Active shouldn't return until the thread has terminated (it issues a WaitFor before freeing the thread in that case), but then you can't change the state of the Active property in the OnChangeNotify event.

wdonker

2005-02-27 04:00

reporter   ~0006601

Setting FreeOnTerminate to false works OK for me.
Thanks for the help; I think we can mark this issue resolved.

user72

2005-03-01 09:09

  ~0006621

Thanks for the update. Will add a note to the on-line help about the differences in Active behavior when FreeOnTerminate is true or false

Issue History

Date Modified Username Field Change
2005-02-26 00:25 wdonker New Issue
2005-02-26 02:43 user72 Note Added: 0006593
2005-02-26 02:43 user72 Status new => feedback
2005-02-26 03:42 wdonker Note Added: 0006594
2005-02-26 04:53 user72 Note Added: 0006595
2005-02-26 07:32 wdonker Note Added: 0006596
2005-02-27 03:12 user72 Note Added: 0006600
2005-02-27 03:13 user72 Note Edited: 0006600
2005-02-27 04:00 wdonker Note Added: 0006601
2005-03-01 09:09 user72 Status feedback => resolved
2005-03-01 09:09 user72 Resolution open => fixed
2005-03-01 09:09 user72 Assigned To => user72
2005-03-01 09:09 user72 Note Added: 0006621