Leaderboard

Whilst there are many Delphi components for detecting changes to file system folders they suffer from serious limitations: typically they only allow you to monitor a single folder they do not support the monitoring of specific files they rely on the FindFirstChangeNotification API which gives no information about what has changed, requiring an inefficient search. I have created a new file system monitoring library that addresses the above limitations. Features: Easy to use, but also suitable for heavy duty monitoring Single unit with no external dependencies Allows monitoring folders and/or specific files Uses the ReadDirectoryChangesW API which provides information about what exactly was changed A single instance of the component can handle the monitoring of many folders and/or files Uses an I/O completion port for efficient handling of large numbers of requests A single thread handles all requests A different notification handler can be specified for each request You can have multiple handlers for each folder or file When you monitor folders you can specify whether you want to also monitor subfolders Installation: You do not need to install the library. Just download or clone the repo and add the source subdirectory to the Library path. Usage: procedure TForm1.FormCreate(Sender: TObject); begin // Create the IFileSystemMonitor interface FFileSystemMonitor := CreateFileSystemMonitor; // Monitor a directory FFileSystemMonitor.AddDirectory(TPath.GetTempPath, False, HandleChange); // Also monitor a specific file FFileSystemMonitor.AddFile('pathtoyourfile', HandleChange); end; procedure TForm1.HandleChange(Sender: TObject; const Path: string; ChangeType: TFileChangeType); begin with lvEventList.Items.Add do begin Caption := GetEnumName(TypeInfo(TFileChangeType), Integer(ChangeType)); SubItems.Add(Path); end; end; To stop monitoring a specific file or folder you use the following methods: function RemoveDirectory(const Directory: string; OnChange: TMonitorChangeHandler): Boolean; function RemoveFile(const FilePath: string; OnChange: TMonitorChangeHandler): Boolean;

For the benefit of anyone reading this thread, the most powerful way to allow your python script to create instances of a Delphi class (e.g. TEntry) is to create a wrapper: type TEntryClassWrapper = class(TPyClassWrapper<TEntry>) constructor CreateWith(APythonType: TPythonType; args, kwds: PPyObject); overload; override; end; { TEntryClassWrapper } constructor TEntryClassWrapper.CreateWith(APythonType: TPythonType; args, kwds: PPyObject); var _obj : PPyObject; begin if GetPythonEngine.PyArg_ParseTuple( args, 'O:CreteWith',@_obj ) <> 0 then begin Create(APythonType); DelphiObject := TEntry.Create(GetPythonEngine.PyObjectAsString(_obj)); end; end; You need to register and initialize the wrapper in your Form.Create: procedure TForm1.FormCreate(Sender: TObject); begin PyDelphiWrapper1.RegisterDelphiWrapper(TEntryClassWrapper).Initialize; end; and then in python: from spam import * entry = Entry('Test') print(entry.Name()) entry = None The Delphi TEntry class is exposed as the python type Entry in your python code.

TEntry = class(TObject) strict private FstrName: string; FclsStringList: TStringList; public constructor Create(strName: string); destructor Destory; function Name: string; end; Destroy misspelled and not declared with override. If you fix this TEntry gets destroyed. But the better way is: function TManager.GetNewEntry: TEntry; begin Result := TEntry.Create('Test'); end; and in python from spam import * entry = manager.GetNewEntry() print(entry.Name()) entry.__owned__ = True entry = None Explanation: When P4D wraps the result of GetNewEntry it does not know who owns the return value. The default is that Delphi does. But the ownership can be changed in python using the __owned__ property.

Not without carefully checking what might breakdown before and why exactly you wanna do this. The way back is made a bit hard, by Apple, better be shure if you upgrade. Avoid also the Beta-Versions, which can cause much trouble too.

Hello Angus, I might have finally found what the issue is. I have tried to reinstall the ICS suite, except that instead of taking the ICS-V9.4 download, I took the ICS-V9 Snapshot one. And after the installation, when trying to compile my project, I had an error that I never add before : [bcc32c Error] OverbyteIcsTypes.hpp(398): expected unqualified-id [bcc32c Error] OverbyteIcsTypes.hpp(399): expected unqualified-id [bcc32c Error] OverbyteIcsTypes.hpp(400): expected unqualified-id relative to this part of the OverbyteIcsTypes.hpp file And apparently, it is due to CF_ACCEPT, CF_REJECT and CF_DEFER being already defined in <winsock2.h> for the WSAAccept function : https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsaaccept I have then added a check to undefine these variables before they are defined in the cpp like this : It now compiles and when I connect a client I finally have the information of the client displayed on my server side. However, while working, I am not sure yet if my solution can cause other issues down the line. Is it on purpose that these variables where named similarly to the windows defined ones ?

BTW for anyone else doing ThreadExecMode := emNewInterpreterOwnGIL; and using a module, do make sure in your module you set this property: MultInterpretersSupport := mmiPerInterpreterGIL; That cause me a bit of head scratching for a while!