Hi,
Can someone pls enlighten me as to the purpose of the FakeComponentLink1, FakeComponentLink2 and FakeComponentLink3 properties defined in cxClasses? Related methods are overridden in numerous descendants. It seems odd that they are published (not public) but not stored and undocumented.
regards,
-randall
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hello Randall.
Thank you for your message. I'm afraid that we can't give you a precise answer. We need to discuss it with our developers. It may make some time. I'll get back to you once we have any results. Thank you for your patience.
Best regards,
Ingvar.
Hello Randall.
Please accept my apologies for the delay in responding. We've discussed the issue with our developers. These links are not documented because they are used for internal purposes only. Let me explain why they were implemented.
If some component contains a TPersistent object that refers to the TComponent (e.g. Properties with the underlying DataSource), we should track the deleting of this component.
If such component is declared in the root of the TComponent, and it is placed to another form/DataModule, then IDE automatically recognizes that this object is used, and it does not destroy this object. In case with TPersistent, the IDE does not recognize it. So, we've added these links to store information about such objects to prevent their destroying on closing objects parent form.
Hopefully, my explanation is clear.
Best regards,
Ingvar.
Thanx Ingvar that does make it clearer.
Might I make a suggestion then: That the TcxRTTIInspector filter out such information? The logic is that if Delphi's Object Inspector does not show a property then neither should the TcxRTTIInspector. Frankly I don't know how it is being masked from Delphi since it is Published. Perhaps somewhere in the Delphi internals it masks out properties that are not stored? Or you guys are doing something funky under the hood.
In either respect, it would be nice if TcxRTTIInspector also did not show such properties by default.
cheers,
-randall
Hello Randall.
Thank you for the response.
By design, the IDE shows all published properties in Object Inspector at design time. To hide these properties, we've unregistered property editors for them. Please review the cxClassesReg.pas unit, which contains the following code snippet:
procedure Register; begin RegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink1', nil); RegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink2', nil); RegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink3', nil); RegisterPropertyEditor(TypeInfo(TcxComponentCollection), nil, '', TcxComponentCollectionProperty); end;
So, at runtime, you can also unregister these properties editors as follows:
initialization cxRegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink1', nil); cxRegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink2', nil); cxRegisterPropertyEditor(TypeInfo(TComponent), TcxComponent, 'FakeComponentLink3', nil);
or use the Inspector's OnFilterProperty event handler to hide them.
Also, you can post a separate suggestion about making this behavior default. Our developers will consider it, and will possibly implement it in future versions of our controls. Please let me know if you need any additional clarification.
Best regards,
Ingvar.