Is there an easy way of clearing all stored state out of the .lps/lpi files, i.e. leaving no history of opened units/forms etc. except possibly a reference to the .lpr or the main-form unit?

I'm mindful of my current issue with files being referenced over different paths (when such a thing is possible, e.g. because of the presence of symlinks) but also it would seem like a good thing to do before publishing a project as source.

Mark Morgan Lloyd hat am 4. Februar 2013 um
12:08 geschrieben:

Is there an easy way of clearing all stored state out of the .lps/lpi files, i.e. leaving no history of opened units/forms etc. except possibly a reference to the .lpr or the main-form unit?

You can save session data separate in the lps file. Close project, delete lps, open project.

I'm mindful of my current issue with files being referenced over different paths (when such a thing is possible, e.g. because of the presence of symlinks) but also it would seem like a good thing to do before publishing a project as source.

Do you mean
Project / Publish Project
?

Mattias

Did that yesterday, but it still leaves at least one file in the .lpi (which was the one that we didn't want saved, under the circumstances).

I was thinking about the general case, including svn to a public repository such as Berlios.

Mark Morgan Lloyd hat am 4. Februar 2013 um
13:01 geschrieben:

What was left, what should not be there?

The lps is normally not stored in the svn repository.

Mattias

If I do a close-all, save-all, exit and then delete the .lps, when I bring up Lazarus it's displaying a tab DbConfigCode2 pointing at the "incorrect" /usr/local/src/inifiles/trunk/dbconfigcode2.pas.

The issue in this case appears to be that in the .lpi file there's

<Units Count="13">
..
<Unit12>
<Filename Value="..\..\inifiles\trunk\dbconfigcode2.pas"/> <IsPartOfProject Value="True"/>
<ComponentName Value="DbConfigFrame"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Frame"/>
<UnitName Value="DbConfigCode2"/>
</Unit12>
</Units>

which, if I understand things correctly, shouldn't be there since I've enables .lps support.

I know, but as I've said above there's a list of units stored in the .lpi as well. How does one clear this?

The above data are *not* session data. Session data is what file is open, cursor position, break points, jump history, .... The above lpi tells, that "..\..\inifiles\trunk\dbconfigcode2.pas" belongs to the project.
The Project Inspector will show the same.
You can remove this file from the project via the Project Inspector or Project / Remove from Project.

This list gives the IDE the clues what files are important and what not. So, you should not clear it, you should clean it up and add all missing project units. For example via the Project Inspector.

Mattias

I'm sorry, I took my eye off the ball since I was still looking at the stored paths.

One final question if I may: if the .lps has been deleted, what controls the IDE's choice of which unit to open when it starts? It looks as though it currently opens the most-recently-added unit, is it possible to change this to be the first-added unit on the basis that this is most likely to be in the project directory, or to open the .lpr as probably the safest choice?

Please test with 40191.

Mattias

Nice, and I think it fixes the naming issue from our earlier discussion (but testing continues).

FYI, looking at a freshly-created (after correcting the intentional error I'd left in one unit) .lps I notice

<Unit0>
<Filename Value="HeavyWethers.lpr"/>
<IsPartOfProject Value="True"/>
<UnitName Value="HeavyWethers"/>
<UsageCount Value="20"/>
</Unit0>
<Unit1>
<Filename Value="heavywetherscode.pas"/>
<IsPartOfProject Value="True"/>
<ComponentName Value="HeavyWethersForm"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Form"/>
<UnitName Value="HeavyWethersCode"/>
<EditorIndex Value="0"/>
<WindowIndex Value="0"/>
<TopLine Value="1"/>
<CursorPos X="1" Y="1"/>
<UsageCount Value="20"/>
<Loaded Value="True"/>
<LoadedDesigner Value="True"/>
</Unit1>
..
<Unit12>
<Filename Value="../../inifiles/trunk/dbconfigcode2.pas"/> <IsPartOfProject Value="True"/>
<ComponentName Value="DbConfigFrame"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Frame"/>
<UnitName Value="DbConfigCode2"/>
<UsageCount Value="20"/>
</Unit12>
<Unit13>
<Filename Value="../inifiles/trunk/dbconfigcode2.pas"/> <ComponentName Value="DbConfigFrame"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Frame"/>
<UnitName Value="DbConfigCode2"/>
<IsVisibleTab Value="True"/>
<EditorIndex Value="1"/>
<WindowIndex Value="0"/>
<TopLine Value="4"/>
<CursorPos X="4" Y="22"/>
<UsageCount Value="10"/>
<Loaded Value="True"/>
<LoadedDesigner Value="True"/>
</Unit13>

where if I (finally) understand things correctly Unit0...Unit12 are describing the files in the project and Unit13 is describing the file that is open on the screen. The only reason I mention this is that the two units that are open are HeavyWethersCode (one entry in the list above) and DbConfigCode2 (two entries in the list, with different paths)... please ignore me if this is intentional :-)

You understand it right.
A project can have multiple units with the same name. For example using one one Linux and the other on Windows. Switching is done via the unit path.
Of course opening both at the same time may confuse you.

Mattias

OK. The only thing I was noting was that in a case where the editor has two files open one of those has one entry (Unit1 above) while the other has two (Unit12, Unit13 above).

[...] OK. The only thing I was noting was that in a case where the editor has two files open one of those has one entry (Unit1 above) while the other has two (Unit12, Unit13 above).

No. Every unit in the lpi has a unique filename.

When you come from Linux (case sensitive) to Window (case insensitive) the IDE deletes one. But this is a rare case.

Mattias

Understood, but we're back at the situation where a name is distinguished only by whether a symlink's been followed.

<Unit12>
<Filename Value="../../inifiles/trunk/dbconfigcode2.pas"/> ..
<Unit13>
<Filename Value="../inifiles/trunk/dbconfigcode2.pas"/>

As previously discussed, that's with
/usr/local/src/heavywethers/inifiles -> /usr/local/src/inifiles

and with only a ../inifiles path in the project settings.

These are two different files for the IDE. Don't forget that this is about the meta data, not the content. The content is stored in the file itself.
One belongs to the project, one does not.

As previously discussed, that's with /usr/local/src/heavywethers/inifiles -> /usr/local/src/inifiles and with only a ../inifiles path in the project settings.

Mattias

OKaaay...so what you're saying is that when the compiler finds the syntax error in
/usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas and reports it to the IDE, the IDE is opening an editor on that file as though it's not in the project. [Checks] It also does exactly the same (i.e. the .lps has one entry for heavywetherscode.pas and two for dbconfigcode2.pas) if heavywetherscode.pas and dbconfigcode2.pas are both already open, but at least I don't get a duplicate tab/pane any more :-)

If the compiler gives an absolute filename the IDE opens just that. If the compiler gives a relative file, e.g. only 'dbconfigcode2.pas', then the IDE starts guessing and then it might use the information from the lpi and lps.

The filenames in the lpi are stored relative. When loading the lpi the IDE converts them to absolute filenames.

Mattias