> You can also do everything with packages - have a dedicated package of
> project-specific components for each project you create, and other
> packages containing sets of related components to use as required. But
> I don't always want to install components that have very specific uses
> into packages. I'm looking to reduce the administrative overhead when I
> just need one component on one form to have a few extra properties
> and/or a little extra functionality.
>
> Having said that, in a one form case I wouldn't really need TMyButton
> available in the interface. But that gets messy...
How about adding a new constructor to TMybutton and creating it in the form create
TMybutton = class(TButton)
public
constructor Create(Button :TButton);
end;
constructor TMyButton.Create(Button :TButton);
begin
inherited Create(Button.Owner);
Assign(Button); // Some properties can be assigned
Parent := Button.Parent; // ... Copy any other properties (like events)
end;
Call the constructor in the OnCreate and you should be fine... Not Ideal I admit
but since the design environment doesn't give you access to any properties of the
subclass under the proposed IDE change this should be fine.
The ideal situation would be for the IDE to operate as an interpreeter rather than
requiring
compiled components and implement a complete subclassing engine... Of course this is
rapidly drifting toward java territory instead of delphi ;)
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Offtopic List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
