(Solved?) Pointer to TForm.Caption (pass to procedure)

[rvk]

The code doesn't have access to the original objects and may need to change different properties without referring to them from the objects.

Not yet mentioned here is that you can use SetOrdProp, SetStrProp etc. in that case.

You only need to know the property name. You can even use GetPropInfo to determine what kind of property it is.

https://www.freepascal.org/docs-html/rtl/typinfo/setordprop.html
https://www.freepascal.org/docs-html/rtl/typinfo/setstrprop.html
https://www.freepascal.org/docs-html/rtl/typinfo/getpropinfo.html

Much more flexible than working with pointers (which might not work in half of the cases because of the getters and setters).

[jamie]

In the case of the original intent, since forms and most other controls are based from TCONTROL
and seeing at this point it seems that the properties being edited are in the TCONTROL

 So place all controls/Forms in an Array of Tcontrol and at some point you can simply edit the values in the array which will effect the controls/Forms that they point to..

Var
 MyARrayOfControls:Array of TControl;

Begin
 SetLength(MyArrayOfControls, ?);

 MyARrayOfContros[1] := SomeFormInstance;


I think you get the picture..

 At a later date you can simply change the values on any one of those objects sitting in the array and it will effect the control it came from.

 In this case.
   Width, Height and Caption are in there.

Just an idea

[rvk]

In this case.
   Width, Height and Caption are in there.

Isn't TControl.Caption protected?
But that's hackable so besides the setstrprop that's also a way.

[jamie]

In this case.
   Width, Height and Caption are in there.

Isn't TControl.Caption protected?
But that's hackable so besides the setstrprop that's also a way.

Protected ? why should it be and why is that a hack?

 My point was that the fields he's accessing are available from the Tcontrol and thus can use any form to change the values he is changing..

[rvk]

Protected ? why should it be and why is that a hack?

I can't test it right know but can you really set TControl.Caption without problems?

Okay, maybe it can in Lazarus.
In Delphi it's protected at TControl level and needs to be published by it's descendants.
Maybe Lazarus handles it better 

[jamie]

Protected ? why should it be and why is that a hack?

I can't test it right know but can you really set TControl.Caption without problems?

Okay, maybe it can in Lazarus.
In Delphi it's protected at TControl level and needs to be published by it's descendants.
Maybe Lazarus handles it better 

All common properties in TControl are published and those that aren't are in the Public district.

[rvk]

All common properties in TControl are published and those that aren't are in the Public district.

TControl.Text, ParentColor, ParentFont etc. too?
I see that those are under protected.
https://lazarus-ccr.sourceforge.io/docs/lcl/controls/tcontrol.html

And indeed, it was only in Delphi that Caption is protected.
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/!!MEMBERTYPE_Properties_Controls_TControl.html

[Warfley]

Holy cow, I didn't think that taking references from Properties would work. This completely breaks properties:

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

1.   TTest = class
2.   private
3.     FTest: Integer;
4.     procedure SetTest(AValue: Integer);
5.   public
6.     property Test1: Integer read FTest;
7.     property Test2: Integer read FTest write SetTest;
8.   end;
9.  
10. { TTest }
11.  
12. procedure TTest.SetTest(AValue: Integer);
13. begin
14.   Writeln('set to ', AValue);
15.   FTest := AValue;
16. end;
17.  
18. var
19.   t: TTest;
20.   p: PInteger;
21. begin
22.   t := TTest.Create;
23.   p := @t.Test1;
24.   p^ := 42; // just set a read only property
25.   p := @t.Test2;
26.   p^ := 52; // Just circumvented the setter
27. end.

About the original problem, if you want to address published properties of a control, you can use RTTI, otherwise you probably need some form of dispatching function to do that (for example write a bunch of functions and put them in a string-function pointer map to look up the correct function to call).
Funnily enough, (@t.Test1)^ := ... gives an error that this is not assignable, but the information gets lost when written to p. Note, with a const type concept like C has this would be completely fine to just return a pointer to const, but in pascal this breaks the whole concept of properties

[jamie]

I got code that won't work without it and it's Delphi compat…..

I love it!
 

[PascalDragon]

Holy cow, I didn't think that taking references from Properties would work. This completely breaks properties:

I agree with you. But in this case Delphi compatibility trumps this...

[Thaddy]

Protected ? why should it be

Not every control has a caption....

[Warfley]

I agree with you. But in this case Delphi compatibility trumps this...

Well, just because it has to be supported does not mean the fpc has to like it. How about adding a warning that mentions that this could potentially break the functionality of a component?

[GreatCorn]

Not yet mentioned here is that you can use SetOrdProp, SetStrProp etc. in that case.

Didn't know about those, switched to using them by passing the TObjects as pointers and everything worked like a charm. Ended up creating my own aliases for the LCL component classes (TForm, etc) to correctly assign all the properties. So, that solved my problem. As for the topic of this question, I guess I tapped into a bug, which, in my book, could be a feature...