With all the talk of my project not opening properly elsewhere I thought I'd open my .lpi file in a text reader and see what I could see...

And was amazed to find the same unit listed about 20 times, several unit entries with no data at all (including unit name) and multiple units from other projects weeks ago that I had closed long before creating this latest project. It's like it did a mix-n-match of every unit I'd ever opened, regardless of if it was originally in a different project file. It even included some files I'd opened in the editor off of a CD but never added to any project.

I blew away the .lpi and figured out how to recreate it.

Leave it to me to find another bug and offer no solutions... LOL

-Tony

<<winmail.dat>>

Andrew Johnson wrote

And I have always tried to make sure of relative paths in Delphi because what happens if I move a project folder and try and reopen the Project? I have to remove and re-add all the files with non-relative paths.

This is a major bugbear for me in Delphi, I copy a project, open it up, start rebranding it (e.g. Times -> Sunday Times), run it, and hey presto, Original ver. runs. I then have to go round, making sure that the files are duplicated, and then work out which are added relative and need saving, and which are added non-relative to switch over.

I think that if possible, project files should be kept completely free of non-relative paths.

-
Martyn Ranyard
Free Software Advocate

jabber -
icq - 122500800
irc - Joran on oftc
msn -
e -

Yes. This is a very likely problem. Fact is, I think that lpi's should only contain Project file information, and Currently Open File information. Basically I think that Lazarus should have another xml file which stores info on all files ever opened in one central location. This would ensure smaller lpi, and if lpi's made sure to store relative location's of project files (../myfiles/myfile.pas, vs /somedir/someproj/myfiles/myfile.pas) and we had a "Publish Project" option which stripped any non-Project Info from the file(non-project open files), I think we would be much better off when it comes to sending projects to other people etc. Also we should have a command somewhere to clean out the lazarus xml of non-existing entries(if not file exists delete entries) to clean out the garbage. I was actually planning on asking Mattias about this later on, because while I hadn't considered the aspect of different systems different locations, why should we duplicate al these entries in multiple project files? I have several projects working, and at some point or another I have opened most of the same files in any one of them. And I have always tried to make sure of relative paths in Delphi because what happens if I move a project folder and try and reopen the Project? I have to remove and re-add all the files with non-relative paths.

Andrew

_________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

Andrew Johnson wrote

Yes. This is a very likely problem. Fact is, I think that lpi's should only contain Project file information, and Currently Open File information.

I agree 100% - besides, I don't want someone else knowing I'm working on a file in another project called "trojanpasswordcatcher.pas"... lol. (just kidding of course, but you get the picture).

I also figured out what happens when the project file "corrupts." The last few lines of the .lpi don't have carriage returns where they belong, in fact if I open it up in a text editor, the font color changes for those last few lines as if they include special control characters. I went in and entered CR using VI in the proper places and the file opened.

Is there a possible buffer overflow problem with the XML units from FPC similar to the form saving problem we saw?

-Tony

And was amazed to find the same unit listed about 20 times,

this was probably the jump-to section, which keeps track of where you well, jumped to within a file. AFAIK Multiple entries here is not an issue, and should be considered normal.

several unit entries with no data at all (including unit name)

well. This certainly sounds like a problem. Did you happen to keep the file? It would help for a reference to track this problem down.

hehe.. this is not a bug. this is a feature.. No, really. Every project file keeps track of every file you open while in it. I am sure your thinking - WHY?! Basically so that next time you open it lazarus can open up to them same spot in the file as when you last had it opened. I use this feature all the time in that I have a test project open in which I will edit Lazarus sources. Next time I open up they are remembered and open up right to the same line, so as I am working, testing, recompiling lazarus, reopening etc etc.. I am always in the same spot as I was last time. This not the problem either as Mattias was telling me that his project file has like a 1000 entries w/out any corruption in site(not that it couldn't be caused by something in this area though). Fact is you use this feature too even when you don't realize it. Actually, I thought this was the problem too till I started to dig through sources to try and fix it. Well. Now ya' know.

Andrew

_________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

Andrew Johnson wrote

hehe.. this is not a bug. this is a feature..

Hmmm. Interesting feature but can this cause problems in some cases. For example: Tony provided the source for the checkbook project. I opened the .lpi and notice, as he did, that it had listings for all sorts of files that had been opened and looked at. The problem is that I don't have those files at the same location (path) that he does. I think that was one problem I had when initially opening his project. He had left the project in a state where he had opened some FPC source files and left them opened in the editor. Those same files tried to open on my machine but they aren't in the same location. The project had a problem opening. (At least I think that is what was going on.)

So is this a possible problem or was something else going on?

hmmm. so that's one problem. I wonder if my corruption is when I am missing a CR in the middle of the units section.. Lazarus will die if I try and close a file sometimes, or if I saveall after closing it. This would certainly explain a lot.

Is there a possible buffer overflow problem with the XML units from FPC similar to the form saving problem we saw?

I asked Mattias about that when he first found out that problem, but he didn't think it likely(not that its imposible, just unlikely).

Andrew

_________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com

There is already an option for this:
Project -> Project Options -> Info -> Save editor info for closed files

The other option on the same page can be used for published projects. But I think this is not very comfortable for the purposes mentioned. I will add a 'publish project' menu item and add some global options to put information about closed files into a global file.

Basically I think that Lazarus should have another xml file which stores info on all files ever opened in one central location. This would ensure smaller lpi

It is planned that the closed files in the lpi files get 'usage stamps'. When a file is not used for a long period of time, the IDE will automatically remove them from the project.

and if lpi's made sure to store relative location's of project files (../myfiles/myfile.pas, vs /somedir/someproj/myfiles/myfile.pas)

Aehm, this is already the case. If not then you have spotted a bug. Can you describe me an example?

and we had a "Publish Project" option which stripped any non-Project Info from the file(non-project open files),

See above. The only missing thing is to set the default for all projects.

I think we would be much better off when it comes to sending projects to other people etc.

See above. I think there are two cases:
Projects that are always published (like the gtkglarea example in the laz sources) and projects that should be sent to other people on occasion. The former can be done with the two existing options and the latter with a 'publish project' function. What do you/the others think?

Also we should have a command somewhere to clean out the lazarus xml of non-existing entries(if not file exists delete entries) to clean out the garbage.

ok. This can easily be done when the auto deletion is implemented.

I was actually planning on asking Mattias about this later on, because while I hadn't considered the aspect of different systems different locations, why should we duplicate al these entries in multiple project files?

Think of the following scenario:
You have several lcl projects. In project A you are currently searching a bug, so you have opened a lot of lcl+gtk files showing related places in the sources. Then time runs out and you have to work on project B. So, you open this one and do some work. When you come back to poject A, you don't want to waste time to find all the places where you were. Because the complete session information is saved in the lpi file you can continue instantly. Another reason is the 'where did I stop last time' question. If I have not worked several days/weeks on a project, I always need some time to find out, what I was working at. But with the complete session of a project, seeing all the files at the last working position, I remember much faster.

And I have always tried to make sure of relative paths in Delphi because what happens if I move a project folder and try and reopen the Project? I have to remove and re-add all the files with non-relative paths.

If you have ideas how to turn more absolute paths to relative ones, plz tell me.

Mattias