How to propagate changes in a frame .lfm to the TFrame referencing it?

[Cascade]

When I make a change to a frame .lfm in the IDE form editor, for example renaming a control, any form that is using the frame (via a TFrame object) will no longer open.

I see error messages such as general read error and missing ancestor when trying to open the form in the IDE.  Not sure I'm explaining clearly:

So, MyFrame.lfm contains a ListView control, and I rename that control from the default name ListView1 to MyListView.  MyForm.lfm will no longer open - it contains a Frame object referencing MyFrame.lfm, but it doesn't seem to know the ancestor name of a control has changed, and is still trying to find an ancestor named ListView1 (?)

How can I get my form to update with the latest changes from the frame .lfm ?

[wp]

When I make a change to a frame .lfm in the IDE form editor, for example renaming a control, any form that is using the frame (via a TFrame object) will no longer open.

You are directly editing the lfm file? You should not do this, it is too easy that fatal error slip in this way. When you rename a control in the lfm, for example, you must also rename the form variable in the associated unit.

The correct way is to open the frame's unit in the IDE and do the changes there. Note that when other frames descending from that particular frame are open as well they will not be updated automatically (not 100% sure, though), and you will have to close and reopen these units for this to happen.

[cdbc]

Hi
Have a look at this thread post.
...I wish people would /search/ our forum more... 
Regards benny

eta: see reply #4 in that thread...

[Cascade]

You are directly editing the lfm file? ... The correct way is to open the frame's unit in the IDE and do the changes there.

Thanks, I'm not directly editing the Frame .lfm file, no.  I open the frame's unit in the IDE form designer and make the changes visually using the Property Inspector.  Sounds like I've got this bit right.

However I am then manually editing the main Form's .lfm file as a last resort, as I can no longer get the IDE to open it after making changes to the frame .lfm that it references.

Thanks for the link to that thread Benny - I will have a good read.

[Cascade]

Think I've got it - so I design my frames visually as normal, but assemble them onto the main form only at runtime (basically avoid using the TFrame object in the visual designer, and instantiate TFrames in my code instead).  I reckon I can live with that for the time being - will give it a try.  Thank you.

[MarkMLl]

Think I've got it - so I design my frames visually as normal, but assemble them onto the main form only at runtime (basically avoid using the TFrame object in the visual designer, and instantiate TFrames in my code instead).  I reckon I can live with that for the time being - will give it a try.  Thank you.

That's the safest thing. There's nothing stopping you instantiating at design time and by and large changes to the frame will "trickle through" to the form on which it's been placed, but the real risk is that if you incautiously edit the instantiated frame your changes aren't fed back to the design-time frame, and can be difficult to get rid of.

Arguably, the IDE should treat an instantiated frame as read-only.

MarkMLl

[Thaddy]

Never touch lfm files, consider them read-only. There is a case to be made to obfuscate them to such an extend that this recurring question will never be asked again.(actually, the early Delphi's had obfuscation on purpose, by design, until some bloke was fired/hired somewhere else in the Valley and all kind of wrong decisions were made.(that was not Anders...)
If you touch lfm or dfm files you are an idiot that needs to be banned from programming.
To put it stronger: everybody knows I am an idiot, (previously also savant) but you just squared that behavior.

(with one exception: if files become corrupted in a way other than editting an lfm/dfm)

[MarkMLl]

If you touch lfm or dfm files you are an idiot that needs to be banned from programming.
To put it stronger: everybody knows I am an idiot, (previously also savant) but you just squared that behavior.

(with one exception: if files become corrupted in a way other than editting an lfm/dfm)

I am /so/ glad that you put in that final line.

OK, let's try this as being somewhat less incendiary.

1) Anybody who routinely uses a text editor to change content in an intermediate file is extremely ill-advised. At the very least he ought to be investigating what the deficiencies are in standard tools that force him to augment them, and if necessary he should be writing a tool to automate his changes so that it can be incorporated into the workflow.

2) Anybody who edits a machine-generated file which has a header advising him not to is unsupportable, *but* there should be an explicit warning header: simply saying "we didn't expect anybody to edit an XML file" isn't good enough. I've just added MD5 hashes to some files one of my tools generates for just this reason, after somebody expressed a preference to edit them to suit his own programming style.

The .lfm files are intermediates between the GUI-oriented form designer and the compilation utilities. They should not be edited manually, but (2) implies that they should have a warning header. However it would be better if there could be some consensus that the IDE shouldn't get them into a state where they- on rare occasions- /had/ to be edited manually.

MarkMLl

[marcov]

Make sure that the main form is not open in the designer/IDE before making changes to the frame.

[Cascade]

with one exception: if files become corrupted in a way other than editting an lfm/dfm

However it would be better if there could be some consensus that the IDE shouldn't get them into a state where they- on rare occasions- /had/ to be edited manually.

This, this - so much this.  I only manually edit a .lfm when the IDE can no longer open it.  I consider it a last resort, but it's happened twice to me in the last couple of weeks for different reasons.  However I do understand an IDE may have bugs or flaws - there is complexity.  It would be nice if IDE handling of .lfm files were improved for fault tolerance.

Hmm...  I think I may have struck a nerve.

I wonder whether it could (almost) always be designed to present the option: "There's a problem with this .lfm - would you like to auto-fix it and open anyway (this might remove the offending component and/or properties) ?  Or cancel."  An error like "Can't find an ancestor class, so I refuse to open it" feels unhelpful.  Please don't take this the wrong way!

A neat approach might be: on opening .lfm file, if a class (or ancestor class) is missing, swap the offending control to a TPanel, but keep any left, top, width, height and alignment properties, so that the overall layout of the form is not compromised.

I did have a look through the Lazarus lfm file opening code with a view to perhaps making some tweaks - but it does look quite scary in there.

Make sure that the main form is not open in the designer/IDE before making changes to the frame.

Thank you - that is worth bearing in mind.

Arguably, the IDE should treat an instantiated frame as read-only.

Oh absolutely, by default.  Then it could be a simple reference, like an include, without any inherited entries to deal with, so more robust.

[LV]

What OP described is easy to reproduce.
Let's create a simple project with Form1 and Frame1.
Rename ListView1 to MyListView in Frame1.
See screenshots of Form1 and Frame1.
Run the application. Everything works fine.
Open unit1.lfm in the source code editor (without changing this file!!!).
See screenshot unit1lfm.png.
Run the application. Everything works fine.
Close Lazarus. Open project1.lpi.

Oops...
See screenshot OpenProject1.png.

Is this a bug?

[Thaddy]

NEVER touch a lfm file! I explained that already. NEVER.

[MarkMLl]

NEVER touch a lfm file! I explained that already. NEVER.

(with one exception: if files become corrupted in a way other than editting an lfm/dfm)

MarkMLl