Forum > Designer
How to propagate changes in a frame .lfm to the TFrame referencing it?
MarkMLl:
--- Quote from: Cascade on November 12, 2024, 11:08:13 pm ---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.
--- End quote ---
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. >:D
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:
--- Quote from: Thaddy on November 13, 2024, 09:40:47 am ---If you touch lfm or dfm files you are an idiot that needs to be banned from programming. >:D
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)
--- End quote ---
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:
--- Quote ---with one exception: if files become corrupted in a way other than editting an lfm/dfm
--- End quote ---
--- Quote ---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.
--- End quote ---
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.
--- Quote ---Make sure that the main form is not open in the designer/IDE before making changes to the frame.
--- End quote ---
Thank you - that is worth bearing in mind.
--- Quote ---Arguably, the IDE should treat an instantiated frame as read-only.
--- End quote ---
Oh absolutely, by default. Then it could be a simple reference, like an include, without any inherited entries to deal with, so more robust.
Navigation
[0] Message Index
[#] Next page
[*] Previous page