Hi,

I started getting this message in my Lazarus applications since the last 2 weeks. It happens very seldom, but still strange. I don't use xml files at all in my application and don't have a reference to a "reg.xml" in any of my code. The applications are run from my HOME directory where I have full read/write access.

Anybody got some ideas?

I used FPC 2.1.1 (lastest SVN) and Lazarus (lastest SVN) under Linux. Lazarus is compiled against the GTK1 widget set. My applications also use the GTK1 widget set.

PS:
I did a quick search of the FPC src directory and found one reference to reg.xml in the /src/fcl/inc/xregreg.inc file.

TRegistry under Linux is simulated using XML file (this is afaik TXMLRegistry class inside)

FPC 2.1.1 is a proper version for registry under Linux.2.0.4 had bugs here.

Regards
Boguslaw

Bogusław Brandys wrote

TRegistry under Linux is simulated using XML file (this is afaik TXMLRegistry class inside) FPC 2.1.1 is a proper version for registry under Linux.2.0.4 had bugs here.

I'm using FPC 2.1.1! I found when the problem occurs. When a form is loaded or closed, it's state is saved. This is handled by the tiOPF framework. The tiOPF framework uses TRegINIFile for storing that State information. I thought it would use a .ini file as supplied by tiOPF, instead of a hard-coded reg.xml file as defined in FPC.

If I can't get this sorted in FPC, maybe I should change tiOPF to rather use the TINIFile class under Linux instead. At least that will mean anybody using tiOPF with FPC 2.0.4 will also be able to save their Forms State information, where currently they can't.

I fixed a bug in TInifile only yesterday. Maybe that is it. Loading form state should work, saving may still exhibit the problem.

I would recommend using TIniFile anyway, even on windows. Using the registry is Bad (tm). At my job we started with the registry, but in the end moved everything to Ini files. Much more practical, and portable to boot.

Michael.

Michael Van Canneyt wrote

I fixed a bug in TInifile only yesterday. Maybe that is it. Loading form state should work, saving may still exhibit the problem.

Thanks, I'll get another FPC update and retest. The problem occurred mostly at the save stage (closing a form).

I would recommend using TIniFile anyway, even on windows. Using the registry is Bad (tm). At my job we started with the registry, but in the end moved everything to Ini files. Much more practical, and portable to boot.

I fully agree! I hate the registry. I have actually just completed the change in tiOPF to rather use TIniFile under Linux, even if you call gINI or gReg singleton functions in the tiOPF framework. Unfortunately I can't change the gReg function under Windows as there are other users relying on the Registry for settings.

As for my own apps and any user settings, I call gINI which stores them in a .ini file on both Windows and Linux.

There is one dangerous caution against overzealous inifile use: with lessened privileges (a situation that is going to become more frequent under Vista, iow, user has no admin rights), apps can't write to "program files/" with the default permissions, and must use special directories for this.

Yes. A well known issue:

This is exactly why we moved away from the registry, because the HKEY_LOCAL_MACHINE (the key for installation-wide settings) is not writable by normal users since NT, and writing the same config to all HKEY_USER keys is not desirable or feasible (roaming profiles etc). A config directory can be made read/write for all users.

Michael.

Yes, and the hell they should, multi user OS's are out there for how long? Thirty years? Almost fourty?

So - writing application specific data to the same, single location for each and every user is inappropriate for most applications anyway. This leaves us with the "AppData" (or whatever it's called) directory in the user's home directory - or the local registry keys.

Without proper rights you can't write to the "global" registry keys either.

So I don't see the difference apart from the usual "Is it better to back up thousands of ini files in different locations, or a single blob aka. registry which is several megabytes of a mixture of important data and junk?" question.

Vinzent.

Michael Van Canneyt wrote

HKEY_USER keys is not desirable or feasible (roaming profiles etc). A config directory can be made read/write for all users.

A registry key can be made that, too.

Vinzent.

I know.
But the average IT admin of our clients doesn't know how to do that. He does know how to operate the windows explorer and click right, ask properties and set permissions (and even that is voodoo for many of them).

Anyone who is convinced that the registry is OK is welcome to sit for a day at the helpdesk here and give it a try. Switching to ini files was mainly done at the request of our helpdesk :-)

Michael.

No matter where the application is located, the .ini file is created in the users HOME directory, be that Windows or Linux. The .ini file only stores custom user settings, so the HOME directory is appropriate for that. You don't want to mix different users settings in a single .ini file!