I notice that recent versions of the IDE add LCLVersion to a .lfm as soon as the corresponding .pas is saved. Can this be inhibited (or, better, can a form be locked at the project level), since it messes up backwards compatibility?

I notice that recent versions of the IDE add LCLVersion to a .lfm as soon as the corresponding .pas is saved. Can this be inhibited (or, better, can a form be locked at the project level), since it messes up backwards compatibility?

LCLVersion was added 27 Feb 2008.
It exists to solve problems with backwards compatibility.

If you do not want to store a property you have to change the source code.

Mattias

Yes.

It exists to solve problems with backwards compatibility.

Or more to the point it solves /forward/ compatibility: later versions of the IDE can massage properties as the form is being read, but older versions clearly can't know how to handle changes that postdate them.

If you do not want to store a property you have to change the source code.

I'm OK with the idea of the .lfm being updated if I do something to the form. But the current situation- and I think this is comparatively recent- is that the .lfm is updated even if it's not explicitly open.

[...] I'm OK with the idea of the .lfm being updated if I do something to the form. But the current situation- and I think this is comparatively recent- is that the .lfm is updated even if it's not explicitly open.

To update a .lfm the IDE must have an open form, because that's what TWriter requires.
Maybe you mean an open form was saved, even though you have not modified it?

BTW, you can mark a unit read-only.

Mattias

Got that, checking carefully using Lazarus 1.0. What's happening is that if multiple copies or representations of a file are open, the r/o state doesn't necessarily propagate. As a particular example, if you clone a r/o file to a new window that doesn't inherit the r/o state (at least until the IDE is restarted).

So if you tell the IDE to open a form as text (.lfm) and mark that r/o, close the graphical representation and update the .pas then the .lfm doesn't get LCLVersion stuffed into it. But if you close the IDE and then restart it, you've got the form both as a text and a graphic representation: under this condition if you update the .pas the .lfm is also updated, even though in its text representation it's still marked r/o.

Explicitly, when the IDE finds an open .pas at startup it opens the corresponding form as a graphic even if it wasn't open when the IDE was last shut down, and even if the text representation of the .lfm is open. I think this is the root of my original complaint, plus there's no r/o property on the graphical representation of a form, and it doesn't inherit r/o from a text representation.

Mark Morgan Lloyd hat am 27. Dezember 2012 um
13:12 geschrieben:

Disable Tools / Form Editor / Open designer on open unit

and even if the text representation of the .lfm is open. I think this is the root of my original complaint, plus there's no r/o property on the graphical representation of a form, and it doesn't inherit r/o from a text representation.

Lazarus defines the 'form' concept as the combination of unit sources plus lfm. While the form is open the lfm is ignored (except for changes on disk messages). You can open the lfm in the source editor, but form changes will automatically overwrite the lfm. So in a way, the lfm is readonly while the form is open. The readonly flag of the unit is used, not the readonly of the lfm source editor.

Maybe the source editor of the lfm should be made readonly while the form is open, although I found the current state useful a few times and no one has complained yet.

A form can not really be made readonly because some things are not controlled by the IDE. For example the window manager and theme changes. And some things have cross-form side effects. For example editing the ancestor of a form. Maybe a form can be marked as 'ask before saving changes'. But I wonder if this setting should really be per-form or if it would be better defined in categories, like all forms in a directory, or forms not belonging to the project.

Mattias

Thanks, noted :-)

But the r/o flag comes off "File settings", rather than from a per-unit setting in e.g. Project Inspector. Presumably these issues also apply to e.g. line termination.

Maybe the source editor of the lfm should be made readonly while the form is open, although I found the current state useful a few times and no one has complained yet.

Maybe. I think some way of locking the form down would be useful, as supported by (at least some versions of) Delphi. I'm not so much complaining now that I've a better understanding of why I was seeing problems... except that I think setting one representation of a unit or form r/o and still being able to change it via other representations or windows is undesirable.

But while things like size changes apply to the content of a form, theme changes wouldn't- only to its presentation during design.

I accept that I'm very much in a minority here. I wouldn't really have noticed anything if I didn't have a very small number of programs that I'm trying to keep working from everything like GTK1 and NT4 onwards: in general experience suggests that that sort of effort is more hassle than it's worth.

Mark Morgan Lloyd hat am 27. Dezember 2012 um
14:46 geschrieben:

I just pointed out, that the r/o file setting of the lfm source editor is somewhat difficult.
Most people hardly open/edit the lfm directly. They expect the r/o flag of the unit to apply to the form.
Applying both r/o flags (unit and lfm) will cause confusion.

Well, yes, not everyone likes micro management at every place. One solution would be to ask when setting r/o to change it for the lfm/unit too. Another would be some way to mark whole categories/directories r/o.

Themes define sizes too.

Mattias

Mattias Gaertner wrote: > Mark Morgan Lloyd hat am 27.

+1

My recent (bad) experience from working with D5 is, that the form layout should be protected better against inadvertent changes, at least in Lazarus. When my VM window was shrunk recently, all open forms were resized, even if only the .pas file was open, and this change made them unusable at runtime :-(

I'd really like an *option* (project setting!) to open a project with all forms locked. Then it would be possible to e.g. fix bugs in a project without risking changes to the DFM/LFM files. In a long-term (commercial...) project *no* single developer, and *no* IDE, should be allowed to change the *appearance* of the program accidentally.

In the best case it should be possible to preserve all control and form *sizes and positions*, while changes to control properties (list styles, handlers...), using OI and property editors, should be allowed. Eventually a project (or form) layout file can be used, or another set of form and control bounds, allowing to restore the actual bounds to exactly these values. Something like "Save/Restore Layout" (or Appearance) menu items. In a business project the forms' layout should be password protected, so that only selected developers can change the appearance of a released program *willingly*; in fact every make/build should use the acknowledged project size/position values, regardless of eventual changes to individual forms.

But while things like size changes apply to the content of a form, theme changes wouldn't- only to its presentation during design.

+1

I accept that I'm very much in a minority here.

I'm not so sure. I don't think that the silent majority would have objections against better protection of a project's appearance, against inadvertent or automatic changes.

There exist many more scenarios, where changes to the layout of a program GUI are undesireable, e.g. when a developer is hired to work on an existing business program. I consider to implement a tool for beforementioned save/restore functionality, usable with Delphi projects. I really don't want to be guilty when a customer cannot use a program any more, because some non-resizeable forms have been resized by some accident on my machine :-(

DoDi

Defending the orthodox position as expounded by Mattias, his suggestion of unchecking "Open designer on open unit" works all the way back to 0.9.24 (possibly beyond, but I can't realistically see anybody wanting to go older). Adding an in-form property to lock its content would have limited benefit in mixed-version work, since unless it was something that irreparably broke the designer (but still left the form compilable) it would either be ignored/discarded or would break the project.

I started using svn locally a year ago and am glad of it: now that I know about the problem, I can simply look for and revert changed forms... provided obviously that there hasn't been a bona-fide change in the .pas which has affected the appearance.

Using filesystem properties as the starting state for a form or unit being locked down would obviously be a possibility, but I don't know how tolerant the IDE is of that. Another way would be to lock files based on some property of a VCS repository (svn, git or whatever), but again there's a risk that the IDE would accept changes and then bomb on any attempt to save them, leaving a project inconsistent.

Elsewhere, I've been advocating some system of giving developers privilege tokens so that- e.g.- the office junior doesn't mess directly with pointers and assembler. I think you've reached much the same conclusion.