Component Development: Publishing events from ancestors
When developing a new component and deriving from TGraphicControl the list of events in the Object Inspector looks rather empty.
Does this mean we have to implement any user interaction like OnDblClick or OnClick ourselves?
If we look closer at the ancestor TControl we clearly find the definition of the events:
property OnCanResize: TCanResizeEvent read FOnCanResize write FOnCanResize; property OnClick: TNotifyEvent read FOnClick write FOnClick stored IsOnClickStored; property OnConstrainedResize: TConstrainedResizeEvent read FOnConstrainedResize write FOnConstrainedResize; property OnContextPopup: TContextPopupEvent read FOnContextPopup write FOnContextPopup; property OnDblClick: TNotifyEvent read FOnDblClick write FOnDblClick;
In the source code you can also find the implementation of these events. Windows API messages are being processed and the event references are being called. Still, they do not appear in our component.
The reason for that is rather obvious as all these properties are defined in the protected-section of the class. For things to show up in the Object Inspector they have to be defined in the published-section.
That is exactly what we will do for the barcode component. We simply add these lines to the published section:
property OnClick; property OnDblClick; property OnResize;
There is no need to specify any types or field variables as we simply want to use what is defined in the protected section of an ancestor. The ancestor does not even have to be a direct ancestor for its properties to be published (TFlxVlcBarcode inherits from TGraphicControl which inherits from TControl ).
After reinstalling our component in the IDE, the component shows up the three events and implementing the methods yields the correct functionality with regard to clicking, double clicking and resizing. Remember how we implemented the AutoSize property. We never touched OnResize just because of this fact. TControl handles the resizing event and if we had made changes to OnResize , these would have an impact now. It would not stand in the way of publishing OnResize, but it would not yield the result that is desired.