Do all your configuration of the content of a frame when the frame is being edited by the IDE. Instantiating a frame onto a form and then editing some of its properties is a recipe for disaster, to the extent that you might need to fix it by editing the form's .lfm as a text file.
Please take that as a statement of fact: I'm not attempting to defend the situation, or attempting to defend the fact that an instantiated frame is not read-only (at least by default).
MarkMLl
as a TFrame, you can customize it's code and add your own "reset" or return to default function. since a TFrame can be made up of different components, which ones are you trying to return to "default"?
Hi
1) create you frame and design it visually, DO NOT PUT IT ON THE FORM!
2) when satisfied with your frame, create it in code on form startup,
ONLY IN CODE I.E.: DYNAMICALLY!
3) It's ok to design and redesign your frame(only) in oi but don't instantiate it
on the form.
This is a proven way to handle your predicament.
Regards Benny
Hi
1) create you frame and design it visually, DO NOT PUT IT ON THE FORM!
2) when satisfied with your frame, create it in code on form startup,
ONLY IN CODE I.E.: DYNAMICALLY!
3) It's ok to design and redesign your frame(only) in oi but don't instantiate it
on the form.
This is a proven way to handle your predicament.
Regards Benny
For now the best I am aware of, is a workaround.
Let's say you have you TFrameFoo on your TFormBar. And then you Edit TFrameFoo...
Now it may actually depend what you edited....
But what I usually do is:
- Make a backup
- Open TFormBar (and any form that has the frame)
- From the designer context menu "View source (lfm)"
- find the frame- within the frame remove all entries, except those that I have intentionally set, to modify the frame
A lot of it will just be Top,Left,Height,Width. And nested objects, with only those fields.
- Save the lfm, close the editor holding the lfm, open the form with F12 again
All should be updated.
I can not find it now but there was a post or wiki page on how to refresh a TFrame at design time. The 1st option was to close the IDE and reopen it but there were other better options offered. I think one was to save everything and then just reopen the project without closing the IDE. in my memory, there was even a simpler [F5] like fix with IDE 3.4 or abouts but I may be wrong.
I tend to use cdbc's approach in my work since mine then to be reused in my code and need to be created at run time so each can be customized at run time (wording and coded options).
I'm not sure if you're answering to my original post, or to the later "The LFM file contains invalid properties" error. If it's the latter, Lazarus managed to fix it itself by deleting the properties.
If it's the former, I'm afraid your solution is actually more work, or at least an equivalent amount of work to just deleting the instance and re-inserting it from scratch. Unless you mean that the frame instance will update itself automatically in perpetuity, if the process you describe is performed once?
So when I have any such issue, I usually open the lfm, and remove any component within the frame, unless I have reason to keep it. This is usually one or two blocks of lfm code to delete.
Then reopening the form and the frame will have its correct new state. And it will still be correctly place in form1 and have its events. (events on the frame, if there were events on components inside the frame, then those components had to be kept in the "delete" step, and maybe only had it's left/top removed).
Martin, can you remember why the consensus was that a frame shouldn't default to R/O after being instantiated to a form? Was it the "Delphi compatibility" bogeyman?
So the question is why not "why was it decided otherwise", but it is "why wasn't it decided to be different" => well because nobody ever thought of it.
I have just recently worked with frames, and (after fixing the streaming issues) I was able to just edit a frame (ok, I only do certain edits) and I don't even need to touch the forms (or frames that nest the edited frame), and yet the compiled exe has all the changes.
So there are large parts that (nearly) work. I would not want to make them less reachable by hiding them behind some RO that then needs to be turned off to get the full experience.
I have just recently worked with frames, and (after fixing the streaming issues) I was able to just edit a frame (ok, I only do certain edits) and I don't even need to touch the forms (or frames that nest the edited frame), and yet the compiled exe has all the changes.
So there are large parts that (nearly) work. I would not want to make them less reachable by hiding them behind some RO that then needs to be turned off to get the full experience.
That sounds great, and probably fixes most of the problems that people have had in the past :-)
It was meant a reply to you first post.
Though it depends on what you meant by "refresh"
I assume that you changed the frame, but those changes aren't visible in the form on which the frame has already been added.
Then it depends what changes you made to the frame.
- Added a new component (and saved the frame)
=> just close and re-open the form
- Removed a component from the frame
=> This may work by reopening the form. BUt it may give an error then you need to remove the "inherited" entry for the deleted component from the forms lfm (which contains the frame lfm too)
=> Moved a component / change some other property (color, caption, ...)
Movement may not follow, because the frame saved the old coordinates to the frame lfm, and sticks to them. So you need to edit away the old coordinates.
Other properties may or may not need editing.
By Editing, you can however keep other changes. Such as caption for frame elements, that you intentionally modified in the form. And you keep settings of the frame itself, eg how it is anchored inside the form.
So when I have any such issue, I usually open the lfm, and remove any component within the frame, unless I have reason to keep it. This is usually one or two blocks of lfm code to delete.
Then reopening the form and the frame will have its correct new state. And it will still be correctly place in form1 and have its events. (events on the frame, if there were events on components inside the frame, then those components had to be kept in the "delete" step, and maybe only had it's left/top removed).