I've just spotted this in my code:

procedure FormCloseQuery(Sender: TObject; CanClose: boolean);
..
procedure TListForm.FormCloseQuery(Sender: TObject; CanClose: Boolean);

Those were inserted by some old version of the IDE, presumably the current version inserts the missing var.

Shouldn't either the IDE or the runtimes pick up this error?

I don't remember such a bug, but I'm not sure. Maybe it was there for a very short time and you were just unlucky.

Shouldn't either the IDE or the runtimes pick up this error?

It's valid code. What do you expect?

Mattias

Only thing there is that I roughed that program out a long time before I was getting Lazarus from svn, so it might in fact be in one or more releases. Appears to be , so it's fairly unlikely that anybody's still using an affected copy.

> Shouldn't either the IDE or the runtimes pick up this error? It's valid code. What do you expect?

I'd expect the trunk IDE or runtimes to realise that the second parameter isn't compatible with the current definitions.

Huh? And what will happen if this handler gets assigned to OnCloseQuery through the LFM?

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120223/9b287c6b/attachment-0001.html>

The TReader can not find "procedure FormCloseQuery". It can only find methods in TListForm.

Mattias

Ah, now I see what you mean:

TCloseQueryEvent = procedure(Sender : TObject; var CanClose : boolean) of object;

And you have

procedure TListForm.FormCloseQuery(Sender: TObject; CanClose: Boolean);

Yes, the IDE adds the var when the event is created. I don't know when this was implemented - a long time ago.
There is currently no tool to fix the signatures.
The LFM / TReader does not check either.

You can create feature requests if you like.

Mattias

I might be missing something to my discredit, but this *is* in the TListForm:

type
   { TListForm }
   TListForm = class(TForm)
     Bevel1: TBevel;
     DialogFind: TFindDialog;
     DialogFont: TFontDialog;
     MenuItem1: TMenuItem;
..
     procedure FormCloseQuery(Sender: TObject; CanClose: boolean);
..
   public
     { public declarations }
     GlobalState: TGlobalState;
   end;
var
   ListForm: TListForm;

Comments in the code suggest that I was using whatever version was current in around '06 or possibly a bit older.

I suspect this code was originally roughed out in the middle of '06, I can see comments in there from August of that year.

There is currently no tool to fix the signatures. The LFM / TReader does not check either. You can create feature requests if you like.

I'll double-check the situation later with trunk and a trivial example and will file a report to get it into the record.

Mattias Gaertner wrote: [...] I might be missing something to my discredit, but this *is* in the TListForm:

Is this in the Lazarus sources?

Mattias

No, my own code but generated by the Lazarus IDE (circa 2006) and apparently still getting past current checks.

Mark Morgan Lloyd wrote

I've just spotted this in my code:

(...)

I can't see any way to justify this not being catch by the compiler as an _error_. We should report it in the fpc-devel ML or in mantis.

Best regards,
Fl?vio

Op 24 februari 2012 13:13 heeft Fl?vio Etrusco
het volgende geschreven:

I can't see any way to justify this not being catch by the compiler as an _error_. We should report it in the fpc-devel ML or in mantis.

A compiler doesn't read the lfm file.

Vincent.

Oops, I thought I tested it with code, not the designer (and now I see that test would've been meaningless anyway). I stand corrected. The current RTTI doesn't provide that much detail yet, then only the IDE can make that check, right?

-Fl?vio

Correct.

And AFAIK the object inspector already does not provide methods with incompatible declarations (though I don't know whether "var", "const" and "constref" are considered different). So in a current Lazarus you might not be able to achieve a situation like this, but it will not warn/fail if an older form contains such an event handler.

(My assumption is not completely verified, so handle wit care)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120224/7981cfea/attachment.html>

In general: yes.
It depends on the calling convention if you notice it.

A check project/package dialog is needed to do various checks, including lfm files. But this has low priority to me.

Mattias