Can't cast Tpanel to TwinControl

[Remy Lebeau]

Sender @$00007F97ED561210 = TLabel( FALIGNMENT: TALEFTJUSTIFY;  FFOCUSCONTROL: nil;  FOPTIMALFILL: False;

Your event handler is being triggered by a TLabel, which is derived from TGraphicControl not TWinControl, that is why you are getting an invalid typecast error at runtime.

it does not change the facts that the compiler in their case must be inserting a Type check when clearly the coder didn't specify that

Yes, it can, and this is undocumented behavior. See:

https://forum.lazarus.freepascal.org/index.php?topic=58944.msg486254
https://forum.lazarus.freepascal.org/index.php/topic,64034.0.html
https://gitlab.com/freepascal.org/fpc/source/-/issues/39644

So, the expression TwinControl(sender).tag silently becomes (sender as TwinControl).tag if the -CR option is enabled, which fails if the Sender is not a TWinControl descendant, such as TLabel.

You can use the {$OBJECTCHECKS OFF} directive to disable this behavior, if needed, eg:

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

1. {$PUSH}{$OBJECTCHECKS OFF}
2. i:=TwinControl(sender).tag;
3. {$POP}
4.  

[Thaddy]

Note that {$objectchecks on/off} is a local define and can be used with {$push}/{$pop} to just turn it off or on for particular pieces of code. The default is still... OFF.

[Bart]

Yes, it can, and this is undocumented behavior. This is what I documented in Indy's source code when I learned of the issue:

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

1. // In FreePascal, if the -CR compiler option (Verify object method call validity) is enabled,
2. // the compiler emits code to make class methods raise an error if their Self pointer is nil
3. // (this is documented behavior), BUT the compiler will ALSO silently change object hard-casts
4. // into the 'as' operator (this is undocumented behavior!).  This change breaks any place that
5. // Indy uses Accessor Classes to reach protected class members across unit boundaries.
6. ...
7.  

You can use class helpers to overcome this, see my recent changes to win32 widgetset code.

Bart

[Remy Lebeau]

You can use class helpers to overcome this, see my recent changes to win32 widgetset code.

Do you have a link to that change? Or at least an example you can post here so I/people don't have to hunt for it?

In any case, Indy still supports older compilers that don't have class helpers, so this is not really an option for me.  But maybe it can help someone else.

[Bart]

This is the simples commit in that range:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/769b7fdc4f4838e178f91178ce3c7cb482306b85

You can check some others by filering commits by me:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/main?author=Bart

Bart

[Remy Lebeau]

Oh ok, thanks. I'll consider it for a future release of Indy. Right now, there are only a handful of access types being used, so the {$PUSH}{$OBJECTCHECKS OFF}...{$POP} workaround is sufficient for now.

[Bart]

Note that, with higher levels of optimization, the compiler may decide to re-order the fields of a class, in which case the access hack may stop working.

Bart

[Thaddy]

@Bart
@Remy Lebeau

And that can be mitigated with {$optimization orderfields-} or {$optimization NoOrderFields} in the same {$push}{$pop}block or around the class declaration that should be prevented from field reordering.
Afaik Delphi does not support this out of the box, although llvm can perform this as a post-compile optimization.
That also means that on the llvm back end it has no issues - within the same code - since it is post-compile.

It is documented only for optimization level4
https://wiki.freepascal.org/Optimization#Optimization_Switches