Duplicate identifier error

[smithcts]

Folks.  Noob here.  Decades ago I did a lot of hobby type work with Turbo Pascal.  Enjoyed it.  Was relaxing.  Discovered Lazarus/FreePascal a couple weeks ago and have written my first Pascal program in decades.  Saw that I could use the app development section in Lazarus to make a really nice looking interface and was attempting to write something I could port the Pascal program into.

Right off the bat I ran into this weird duplicate identifier issue; screenshot attached.  The compiler seems to be taking segments of variable identifiers and if those sections are the same, calling the entire variable name a duplicate.  I have to be making some fundamental error as it seems impossible to write even a small program if this is the case.

I cannot find this in a search of the forums.  Mods, if this is in the wrong place, please move it.  Best to ask those who actually know what they're doing.

Thanks folks.

[Bogen85]

The compiler seems to be taking segments of variable identifiers and if those sections are the same, calling the entire variable name a duplicate.  I have to be making some fundamental error as it seems impossible to write even a small program if this is the case.

Are you sure that is what is happening? (That the compiler is doing that and is thinking the partials are duplicates of the original PlaneOwn?)

Did you try correcting the first instance of a duplicate? (Where there are two complete PlaneOwn variables being declared).

The compiler would not be doing the visual highlight. That would be some mechanism in the IDE.

[Thaddy]

It is more silly than that. It is in plain sight. The compiler is correct.

[wp]

I don't fully understand. The highlighted line in the screenshot is a duplicate of the line a bit higher. The gray background in the other line is just a feauture of the editor to show you where the currently selected phrase occurs in this file again.

What did you do to duplicate the identifier? Normally it is quite difficult to achieve this...

Every identifier must be unique. Add a number, or a descriptive suffix/prefix to the base name. Enter the new name in the object inspector, row "Name".

Not sure, but once a duplicate component identifier is in the file the IDE may have huge difficulties to rename it. Close the IDE, make a backup copy of your project, open the pas file in an external editor, rename the identifiers so that they are different. Then open the lfm file (with the same base name) in the editor and find the two editors and rename them here again. Then load the project into Lazarus and try to compile it. When there are still references to the old names somewhere in your source code, it will tell you where they are; change the names accordingly.

[smithcts]

I agree.  It is in plain sight.  I got hung up on the highlighting of the similar strings.  This is something I noticed the FreePascal source editor did.  Candidly, it bugs me but I guess it's a useful feature when you're creating a real program.  Not the kind of stuff I do.  Kind of like the way it throws up hints as you enter a function call prompting you on how to properly format the command.  Always puts the hint in exactly the right spot where I can't see what I'm doing.

To answer the question, why is it there; I have no idea.  This gets generated behind the scenes as I'm dropping the fields into the form generator.  Probably something I messed up.  Just not used to not having this stuff created unless I type it myself.  Another thing to get used to.  I'll delete one of them (don't know right now which if any of them I need) and see what happens.  If I kill the wrong one, I'll find out pretty fast.

Thanks folks.  Lesson learned.  Now on to the next one.

Charlie

[Bogen85]

It is more silly than that. It is in plain sight. The compiler is correct.

Of course. I was just trying to point things out in a way the OP would come to that conclusion.

[Bogen85]

I agree.  It is in plain sight.  I got hung up on the highlighting of the similar strings.  This is something I noticed the FreePascal source editor did. 

In general I've found it best it always correct first occurrence of some problem a development tool points out to me. Quite often subsequent indicators (until the first problem is corrected) are just noise...

[VisualLab]

In my opinion, it looks like a manual modification in the content of the form files: PAS and LFM. However, if I'm wrong and the IDE allowed it, it would be good to know how it happened (details). This could speed up the removal of a potential error in the editor (if indeed it was).

[smithcts]

I didn't have a lot done so just trashed the entire thing and started over.  I probably put in an entry for the field name and intended it to be in caption.

Started another one.  Happened again.  This time I have no idea where it finds the duplicate.  I sure don't see one.  Was pretty careful this time not to conflate name and caption.

I think I'll just stick with standard Pascal.  This looks way nicer but isn't all that friendly.  I can't progress much past just adding six data fields.  I will need to add a bunch more.  And integrating the old Pascal code will be a lot more challenging.  The old one works.  It just looks like it's from thirty years ago.  But so am I; figuratively speaking.

Thanks for your comments folks.  I think I'll just stick with the classic version.  This seems a bridge too far.

[Bogen85]

I cannot find this in a search of the forums.  Mods, if this is in the wrong place, please move it.  Best to ask those who actually know what they're doing.

You definitely picked the correct location in this forum in my opinion....

I use free pascal, but I rarely use the Lazarus IDE. It seems obvious this is not the compiler messing up, and is something the IDE is doing (based on how you are using it) for the code it is putting into the source file.

I tend to avoid code generators that are not based on meta programming that I control, but I'm not going to rush to blame the IDE and form designer here.

I have little experience with the form designer in Lazarus (used Delphi and Borland C++ builder extensively 20+ years ago) but I've not heard of this happening to others who use the form designer I can't really fathom this is something normal with the form designer.

[AFFRIZA 亜風実]

I didn't have a lot done so just trashed the entire thing and started over.  I probably put in an entry for the field name and intended it to be in caption.

Started another one.  Happened again.  This time I have no idea where it finds the duplicate.  I sure don't see one.  Was pretty careful this time not to conflate name and caption.

I think I'll just stick with standard Pascal.  This looks way nicer but isn't all that friendly.  I can't progress much past just adding six data fields.  I will need to add a bunch more.  And integrating the old Pascal code will be a lot more challenging.  The old one works.  It just looks like it's from thirty years ago.  But so am I; figuratively speaking.

Thanks for your comments folks.  I think I'll just stick with the classic version.  This seems a bridge too far.

Well, that's really friendly to me. Just read the hint, go to  unit Classes and you found the parent of that form class already have "Owner" field. It's so clear, just need a bit reading comprehension. 

Same here, I'm also a noob, the worse thing is I don't really speak English but that IDE hint is so clear to me. Not even fully read the message, just look at the unit name and which line and I can really realized that I am using the same field name as the parent class. Hell I even have no idea WTH and how OOP works in Object Pascal.

[KodeZwerg]

@smithcts: Since you start learning, best practice: Always give your field names an leading "F", like "FOwer", so such error can not happen, when you later are more common into OOP feel free to do as however you like (but I guess you stay at leading "F")

[wp]

I still wonder how it was possible to give two different components the same name in the first post. Did you write these line by yourself? Everything between the classname and its inheritance (Form1 = class(TForm)) is "published" and administrated by the IDE - do not change this part of the unit yourself. If you want to make additions do this in the lower sections preceeded by "private", "protected" and "public".

Maybe you should look at an introductory video first, such as https://www.youtube.com/watch?v=3APFv8Rj2iU.

[VisualLab]

I still wonder how it was possible to give two different components the same name in the first post. Did you write these line by yourself? Everything between the classname and its inheritance (Form1 = class(TForm)) is "published" and administrated by the IDE - do not change this part of the unit yourself. If you want to make additions do this in the lower sections preceeded by "private", "protected" and "public".

Maybe you should look at an introductory video first, such as https://www.youtube.com/watch?v=3APFv8Rj2iU.

I took a better look at the last screenshot, from answer #8. It only now dawned on me that the OP is not using a form designer. He creates a brand new class based on TForm. This is code from the source code editor only. When the OP tries to compile the project, the completely correct messages rightly appear. The IDE did nothing wrong. However, since the OP doesn't say what he did, it doesn't make it any easier to find the cause of his problems. It would suffice for him to briefly and concisely describe what he was doing in turn.

[af0815]

In the pic of post #8 it is clear to see, the OP have re-used a existing name. The compiler says, it was defined in Classes, Classes.inc in Line 1988. This is, because "Owner" is a often used declaration in the LCL and/or FCL. This is the result of OOP, and normal.

This is a normal learning curve, you should accept this and use such common names not.   


Edit: The first issue i have sometimes see by me. You can produce this with search and replace or with a renaming (F2) in an other unit andaccidently using the same name. It is not a great problem, because i can ask GIT-diff for the differences and correct this. But this can definitly happen.