On 04/05/2020 11:05, Bo Berglund via lazarus wrote:
On Mon, 4 May 2020 10:25:42 +0100, Tony Whyman via lazarus
<lazarus@lists.lazarus-ide.org> wrote:
As to the filename issue: the xml file location is determined from the
Vendor Name and application name and relative to $HOME/.config - is that
really a problem?
First off:
I would NOT use the Registry ever for my new applications...
Instead I would use conf files in ini file format so I can read/write
them using the TIniFile or TMemIniFile classes.
If you are thinking of a new Linux app then I would agree. You only use
TRegistry if its cross-platform and you need to use the registry under
Windows.
But my task now is to port a Windows service program which is
controlling the scheduling of external equipment operations.
It is a Windows service and thus non-gui but it implements a socket
communications channel whereby existing Windows (Delphi) applications
can control it by writing config data and look for results etc.
We can no longer use the service application on Windows going forward
because of Microsoft changes to drivers we rely on etc.
So the idea is to convert the service application to FPC/Lazarus and
then port it over to Linux.
So, being a service the server uses the Registry for all of its config
and task data on Windows and it would be simpler to port if I can
continue using that part of the system.
At first look TRegistry seems to handle this.
But there is a problem:
On Windows HKLM is a *global* hive and by what I hear here the
TRegistry implementation for Linux uses xml files instead and that is
no problem, provided that there is one only such file in use.
But if they are application specific then it will not work.
We use different applications to manage the server via the Registry
and this would not work then.
The model is like Windows in that you have both system wide and per user
hives. If you want a group of applications under the same user to access
the same registry XML file then you need to make sure that they are
using the same AppConfigDir. You can ensure this by adding Vendor Name
and Application Name callbacks so that your applications all use the
same AppConfigDir.
The issue that you may find is when one process makes a change to the
XML file that needs to be picked up by the others. Then you may need
some IPC signalling to make that happen. There may even be a need for a
lockfile to avoid race conditions - but then you would have the same
problem with .conf files.
For example we have a local server configuration utility apart from
the TCP/IP socket connection and if I understand it right this
application would operate on a *different* xml file altogether so
whatever changes it makes to the "registry" will not be available to
the service application...
If this is so I need to reconsider the use of TRegistry and dig down
into changing to conf files (which can be global)...
Much more code to convert in that case.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
