Renaming can’t be done from source editor.

[wp]

@LV: I followed your steps exactly, some OS, same Laz/FPC version, same bitness. But in step 5 there is only Button1 in the lfm...

[Aruna]

@LV: I followed you steps exactly, some OS, same Laz/FPC version, same bitness. But in step 5 there is only Button1 in the lfm...

@wp I think @LV said (s)he added code in there:

Code: Pascal  [Select][+][-]

1.  object Button2: TButton
2.     Left = 104
3.     Height = 31
4.     Top = 62
5.     Width = 94
6.     Caption = 'Button2'
7.     TabOrder = 1
8.   end

@LV could you please confirm? Thank you.

[LV]

Sorry for the late reply. I usually go to bed early so I can get enough sleep before work week. Thanks for your attention and time with my "school" projects. @Aruna, yes, I confirm. @WP, I followed the steps exactly as described in reply #21 again. Everything works, I haven't tested it on Linux yet.

[wp]

@Aruna, yes, I confirm.

Then I misinterpreted your description as "this changes code unit1.lfm" (I should have read more carefully...).

But modifying the lfm file is the most dangerous way to to create a component. Only recently we had a post here where somebody destroyed a form by doing this. If you want to create a component by "text" rather than using the object inspector and form designer do it by code in the editor:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   Button2 := TButton.Create(self);
4.   Button2 := 104;
5.   Button2.Height := 31;
6.   Button2.Top := 62;
7.   Button2.Width := 94;
8.   Button2.Caption := 'Button2';
9.   Button2.TabOrder := 1 ;
10. end;

[MarkMLl]

But modifying the lfm file is the most dangerous way to to create a component.

I agree. The two times I've had to do it are (a) cleaning up after an inadvertent (or at least ill-asvised) edit of an instantiated frame and (b) walking the state of a form back after a more-recent version of the IDE has added a property to a component which didn't exist in an older version.

But directly editing the .lfm isn't what OP was talking about.

MarkMLl

[Thaddy]

Still, that needs to be done and if source and lfm are in sync it is not dangerous. It is only dangerous if the sync is not maintained.

[wp]

Why should a component declared in the published section of a form (the one immediately after "type...) be auto-created? Even Delphi doesn't do this.

[Aruna]

Sorry for the late reply. I usually go to bed early so I can get enough sleep before work week. Thanks for your attention and time with my "school" projects. @Aruna, yes, I confirm.

Thank you for confirming @LV. I am yet to test your code using the steps you posted. I will do so soon.

@WP, I followed the steps exactly as described in reply #21 again. Everything works, I haven't tested it on Linux yet.

I am using Linux Debian 12. I wonder if it is a linux related issue? 

[Aruna]

But modifying the lfm file is the most dangerous way to to create a component. Only recently we had a post here where somebody destroyed a form by doing this.

That somebody would be 'me' and the post is here I never destroyed the form, it decided to not appear anymore.

In my defence if I am very new and have very little knowledge with Objects and Free pascal and the documentation available though through does not have an answer to my problem what do you do? I learn by doing so I experiment and most times break things but I also figure out how to fix things in the end. Destroyed is a strong word, I prefer to think of it as I went and misplaced that form and I am unable to locate it to date :-)

[MarkMLl]

That somebody would be 'me' and the post is here I never destroyed the form, it decided to not appear anymore.

In other words something had happened to it which upset the IDE while it was parsing it for display/editing, but not when it was converting it into resources to be loaded at runtime.

Which I think makes the point adequately.

MarkMLl

[Joanna from IRC]

I think aruna was a bit confused earlier.
Adding a control at design time from component palette and then trying to rename it is not the same as typing a control into the form part of the source code. The latter will stay nil unto it’s created and should not appear in object inspector because it doesn’t exist.

I’ve had to resort to editing lfm files in the past because they were crashing because something in them didn’t match the source code anymore  and the messages were quite cryptic. I was making frames with inherited components which were no longer valid and stuff like that.

I’ve also caused myself problems using the rename feature in source editor and renamed things I didn’t intend to which also caused problems.

[WooBean]

I’ve also caused myself problems using the rename feature in source editor and renamed things I didn’t intend to which also caused problems.

I have played with renaming identifiers (as a part of supporting dotted identifiers) and found that it should be checked if a new name for renamed identifier is not a cause of conflicts like existing project or unit name, a Pascal keyword or an identifier already defined.

Experiments can be viewed at https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41002 but rather only for people a bit experienced with using git and a git command like "$ git apply ~/directory/patchname.patch". The real patch is really big and I try to keep them in sync with the trunk.

Anyway, a part of renaming an identifier which is used inside .lfm file and synchronizing them with GUI designer is not started yet.

[LV]

What I was talking about a few posts back was just a simple little "sandbox" game. It was working, but the "sand castle" was on the verge of collapsing.

But modifying the lfm file is the most dangerous way

I agree.

Of course, now such dangerous tricks should be avoided in projects. Or there must be a good reason to use them.

[Joanna from IRC]

I think that the lazarus ide should be made more robust so that disasters the require lfm files to be fixed.

I’ve had many misadventures in my experiments with nested frames. If I remember correctly I had frames that inherited other frames and I made changes to the ancestor frame but the no longer valid information was not updated the the descendant frames. 
Lazarus ide doesn’t know how to update inherited things when ancestor changes.

The best way to avoid trouble with ide not updating the gui is to create everything at runtime.

[MarkMLl]

I think that the lazarus ide should be made more robust so that disasters the require lfm files to be fixed.

In that case submit bug reports and patches. I'd suggest that a good start would be to work with Thaddy to identify the preexisting patches that he said would fix the problems.

MarkMLl