Writing to projects.ini and other settings files

[pmk65]

I working on a new plugin
This time I want to extend the Project handling. I am able to read the "projects.ini" file and also write to it.
But as WeBuilder stores the content internally (registry?), my changes are not detected by WeBuilder.

Would it be possible to add some kind of method to trigger reloading of the file into memory?
Or a way to duplicate the code written in .ini file, into memory?

[Aivars]

Not really, but the correct way to be to go through API anyways. What exactly are you trying to change for the projects?

[pmk65]

Not really, but the correct way to be to go through API anyways. What exactly are you trying to change for the projects?

Since i can't add anything to the existing "Project" GUI, I basically want to clone as much of the existing Project functionality into a new plugin.
Then I can add my enhancements, and use the plugin as a replacement/addition to the "Project" menu.

I also tried setting properties of Script.ProjectSettings, but that result in a crash/error, so Im assuming they are read-only?

Code: Select all

    Script.ProjectSettings.SelectedProjectName = "testproject";

Result:
Plugin "Extended Projects handling.": Line 338:5: Access violation at address 00000000 in module 'webuild.exe'. Execution of address 00000000

[Aivars]

I'll check but I think that they are read-only.

One way to work around all this would be to have your special "Edit Project" dialog, where the general project info (name, path) is read-only with Edit button, that simply calls "Edit Current Project" action. That way you can focus on the extra stuff and not worry about standard project properties, even between major versions.

[pmk65]

One way to work around all this would be to have your special "Edit Project" dialog, where the general project info (name, path) is read-only with Edit button, that simply calls "Edit Current Project" action.

I thought of that too, but it kind of defeat the purpose of having a docking panel. (Forgot to say it was a docking panel plugin )

[Aivars]

Maybe it doesn't have to be. I don't know what you're making, maybe docking panel makes sense for this plugin, but generally you would need it only for stuff that you want to be visible and quickly accessible at all times.

[Will Fastie]

I know what Peter is doing so let me ask a more general question.

Where can a plugin read and write persistent data? For example, can a plugin read/write the Windows registry?

I can see both points of view here. Because Peter's plugin relates to project management, the logical place to persist his data is in projects.ini. I agree with him that it makes sense.

On the other hand, I would worry that persisting data there runs the risk of conflicting with a future Blumentals change.

Personally, I like the idea of the Registry.

[Aivars]

Plugins can read/write persistent data in multiple ways and Peter has done it before. I'm sure he already has ideas how to go about it this time.

[Will Fastie]

I'd like to know how it is done. The online documentation for plugins is very thin.

[Aivars]

1. Using properties.ini (I'm using parts of Peter's script for this example). The advantage of this method is that these values can be customized by anyone via Plugin Manager.

Create properties.ini:

Code: Select all

[Properties]
Trigger sequence=string
Trigger on keywords only=check

[Values]
Trigger sequence=/**
Trigger on keywords only=0

[Hints]
Trigger sequence=Keyboard sequence to trigger plugin
Trigger on keywords only=If checked, DocBlock Comment will only be inserted if next line contains a matching keyword.

Reading the setting:

Code: Select all

var triggerCombo		= Script.ReadSetting("Trigger sequence", "/**"),
triggerKeywordsOnly	= Script.ReadSetting("Trigger on keywords only", "1");

Writing the setting:

Code: Select all

Script.WriteSetting("Trigger sequence", triggerCombo);
Script.WriteSetting("Trigger on keywords only", triggerKeywordsOnly);

2. Using custom ini file:

Code: Select all

function WriteIni(Sender) {
  var lastFileName = Document.FileName;
  var ini = new TIniFile(Script.Path + "test.ini");
  ini.WriteString("My Settings", "Last File", lastFileName);
  delete ini;
}

function ReadIni(Sender) {
  var ini = new TIniFile(Script.Path + "test.ini");
  var fileName = ini.ReadString("My Settings", "Last File", "file not found");
  delete ini;
  Script.Message(fileName);
}

Script.RegisterAction("", "Test INI Read", "", &ReadIni);
Script.RegisterAction("", "Test INI Write", "", &WriteIni);

You can use this plugin as reference as to what other methods TIniFile combined with its parent TCustomIniFile supports: http://forums.blumentals.net/viewtopic.php?f=33&t=7407. In most cases Read/WriteString, Read/WriteInteger, Read/WriteBool is enough.

[Will Fastie]

Thank you.

While I appreciate the time you took to add these notes, I hope they can be added to the standard documentation set so they are readily available from help.