With memory management in mind we also need to instantiate “Properties” and free it when the component is freed: constructor TBarcodeProperties.Create Thus, the component class also uses assign for the property “Properties”: procedure TBarcodeProperties.SetQRProperties(const Value: TQRProperties) If we simply used FQRProperties := (Source as TBarcodeProperties).QR we would be in big memory management trouble … check for type of Source, call Assign of inherited class if neededįStretch := (Source as TBarcodeProperties).Stretch įType := (Source as TBarcodeProperties).&Type įHeight := (Source as TBarcodeProperties).Height įQRProperties.Assign((Source as TBarcodeProperties).QR) For that reason we also use Assign for more nested types: procedure TBarcodeProperties.Assign(Source: TPersistent) It is important to provide the method Assign as values need to be assigned by value. Property QR : TQRProperties read FQRProperties write SetQRProperties Property InvertColors: Boolean read FReverseColors write FReverseColors Property Border: Boolean read FBorder write FBorder Property Value: String read FValue write FValue Property TextSize: Byte read FTextSize write FTextSize Property ShowText: Boolean read FShowText write FShowText
Property Height : Word read FHeight write FHeight Property Width : Word read FWidth write FWidth Property Stretch : Boolean read FStretch write SetStretch Property &Type : TBarcodeType read FType write SetType Procedure Assign( Source : TPersistent ) TBarcodeProperties and TQRProperties are defined as follows: type The IDE starts with your form and serializes all “owned” components on the form, one after another. In order to do that, your class needs to be derived from TPersistent . What is the reason for this? Well, Delphi needs to be able to serialize the object instance into the form file (dfm). This magic happens if you rememer one basic rule:ĭerive your “nested” types from TPersistent The object inspector “magically” offers the nesting and sub-properties in a way: This property allows me to configure the properties of the Barcode and not the visual aspects of the component. Note the property called “Properties” of type “TBarcodeProperties”. The component offers context menu support and also a whole lot of properties to support the complete Barcode4Me API ( link).
However, as it has been quite some time since I developed a VCL component that had a “nesting” of this sort, I needed to read up on the topic again. I might add that this post will be nothing out of the ordinary for the skilled Delphi developer. I never got used to it as the property was never in the category I expected it to be in. I have to admit that I never use the category arrangement for propties – ever since it has been introduced in Delphi 3. Thus, while developing a VCL component that generates a barcode using the Barcode4Me webservice API, I noticed that when adding all my properties the component looks rather cluttered in the Object Inspector. I am always a fan of keeping the amount of customization limited to things that really will be used, but – let’s be honest – sometimes you can hardly imagine what people will be able to do with your components… When developing components it always comes to the point where you say: Do I really need that property? Does it make sense to offer even more customization?