Recent

Author Topic: Unexplained compiler error" pgPaintContextPopUp(TObject; TPoint; var Boolean)"  (Read 659 times)

tfurnivall

  • Jr. Member
  • **
  • Posts: 85
I have begun, relatively suddenly, to see this error message when compiling my project. It occurs with two pages of a TPage control (pgPaint and pgTools).

A few things are extremely confusing:

1) The error as reported gives no names for the types specified, while the lines where the error is deemed to have occurred do (in fact) have parameter names to match these type specifications.

2) There are (in fact) matching procedure declarations and stubs (begin end;) in the implementation of the unit I am trying to compile. They got there by the simple expedient of copying the interface declaration and adding a being-end pair.

Can it be that the location of a procedure within the implementation is following some unknown plan?

When checking the Forum for similar instances of the error, I discovered:
Quote
In my main program I had created a procedure, which works fine.
Now, I need to use that procedure from another unit, so I have to declare that procedure in the class portion of my main form.

Declaration: I added the following line and get the below error.
   Procedure ValidateRegKeyStr(Sender:TObject; RegKey:AnsiString; Out Valid:Boolean);     

In the body of my code, the procedure call looks like this:
Procedure ValidateRegKeyStr(Sender:TObject; RegKey : AnsiString; Out Valid:Boolean);     

I'm getting the following error, which points to the Declaration statement:
RIMMain.pas(166,15) Error: Forward declaration not solved "TfRIMMain.ValidateRegKeyStr(TObject,AnsiString,out Boolean);"

Without the above Declaration, the call to the procedure from the new unit gives the following error:
RegForm.pas(61,17) Error: identifier idents no member "ValidateRegKeyStr"


Any suggestions?
I've rebuild Lazarus-no improvements.

This is similar, but slightly different.
a) I have no (current) interest in handling a ContextPopUpRequest. Maybe in a gazillion years or so, but certainly Not Right Now.
b) I have 14 pages in this control, all of which have names that are meaningful to me, but none of which should be giving clues to the compiler. However, only two of the pages have the procedure declared. All of them have a placeholder in ProjectInspector, none of them have anything attached to the placeholder. Only these two (pgPaint and pgTools) have the declarations in the interface section of the form.

I have tried commenting out the lines in both sections. This produced a different message about dangling references, along with an offer to remove the dangling references. When I did this the compile worked.

It's a little bit like having an unhousetrained puppy wandering all over my project. Every once in a while there's a mess, which is a bother to clean up. But it seems to get cleaned up. With a puppy there is always hope in the future. But surely code is designed to be a little more stable than a puppy?

I can live with the result, but since the quoted issue was captioned "(yet another)Forward declaration not solved", and comes from 2011, I wonder if anyone can provide a simple explanation for what is happening?

Puppy Chow may be available to interesting responses!

Tony


cdbc

  • Hero Member
  • *****
  • Posts: 2475
    • http://www.cdbc.dk
Hi
Quote
They got there by the simple expedient of copying the interface declaration and adding a being-end pair.
This sounds very wrong in my ears!!!
Show us the code.
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE6 -> FPC 3.2.2 -> Lazarus 4.0 up until Jan 2025 from then on it's both above &: KDE6/QT6 -> FPC 3.3.1 -> Lazarus 4.99

tfurnivall

  • Jr. Member
  • **
  • Posts: 85
I seemed to pick up another instance this afternoon. It was for the Colors page (pgColors - see attached Project). I've left the stubs in - they don't seem to be doing anything! (I still have no idea why the earlier ones were creating problems for the compiler)

I'm not going to worry (excessively) about this any more, but if anyone happens on it and has some ideas, please let me know!

Tony

PS This project has been uploaded before, but this is a slightly later version...

cdbc

  • Hero Member
  • *****
  • Posts: 2475
    • http://www.cdbc.dk
Hi Tony
Your app works fine here with me =^
...and by the looks of it, your code seems fine too \o/
Happy coding mate  :)
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE6 -> FPC 3.2.2 -> Lazarus 4.0 up until Jan 2025 from then on it's both above &: KDE6/QT6 -> FPC 3.3.1 -> Lazarus 4.99

tfurnivall

  • Jr. Member
  • **
  • Posts: 85
Hi, Benny,

Yes, there was (almost) no problem with the functioning of the code. It was as I was trying to get rid of the unwanted handlers that compiler errors popped up. When I left the most recent one well alone, it was never called and seemed to have no effect on the rest of the code. Remaining questions:

1)  How on earth did the IDE decide to insert this particular handler
2) Why should ham-handed surgery on the code have such results.

I think this is a problem for Horatio!

Thanks for checking it out,

Tony

 

TinyPortal © 2005-2018