Jump to content
msd

VCL Wrap

Recommended Posts

Hello, 

 

I saw in one of the demo sources from DevExpress that they use TdxForm or TdxRibbonForm instead of TForm, but there are no VCL components in the DevExpress VCL list of components.

In the description of the source I just need to change the class from TForm to TdxForm, and I have new properties for development and design.

So, my question is: can I or how can I wrap some VCL without creating a new VCL component and adding some properties and events?

 

Thanks in advance...

Share this post


Link to post

If you want access to the properties and events at design time, there is no other way than creating and installing a new component having those properties and events.

 

If you want access the properties and events only at runtime, then no need to create a component. Just create a new class deriving from some ancestor and add the properties and events.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
TSuperButton = class(TButton)
...
end;

TButton = TSuperButton // ! the trick

Tform1 = class(TForm)
  btn: TButton; // <- will be TSuperButton in fact

Type reassignment trick

  • Like 2
  • Thanks 1

Share this post


Link to post

Wouldn't it be more clean to use the interposer without the intermediate class wrapper TSuperButton ?

https://zarko-gajic.iz.hr/delphi-interceptor-classes-tbutton-classtbutton/

 

type
  TButton = class(stdctrls.TButton)
  private
    fLastClickTime: TDateTime;
  public
    procedure Click; override;
  public
    property LastClickTime : TDateTime read fLastClickTime write fLastClickTime;
  end;

 

Edited by Rollo62
  • Like 1
  • Thanks 1

Share this post


Link to post
On 6/21/2023 at 5:01 PM, Rollo62 said:

Wouldn't it be more clean to use the interposer without the intermediate class wrapper TSuperButton ?

https://zarko-gajic.iz.hr/delphi-interceptor-classes-tbutton-classtbutton/

This is EXACTLY how I "injected" my own extended DBGrid in my app before I put it in an installable package. Good to know it's an "accepted" way of solving this 🙂

Share this post


Link to post

Accepted, yes, but maybe from a purist's standpoint this is not what is recommended.

What I like from the imposer is, that this perfectly can extend or repair missing standard components' behavior, without the need to install new components,

while still working well under the IDE Designer if you don't mess up things.

Existing projects still work and can be easily extended.

The drawback is that this is kind of "magic", just to add your wrapper unit in the uses clause and suddenly a new behavior appears, I think this is the reason why many people dislike it.

 

Another approach, which is maybe more clean, but clumsy, would be to use consequently your own set of standard component wrappers.

Like TEdit => TEditEx, TLabel => TEditEx, TButton => TButtonEx, ... as intermediate wrapper-layer around every standard components.

That way you need to install small wrappers to any existing components by default, with the option to extend or repair those wherever needed.

This is maybe more clean, but has also a huge impact on projects, since you should only use your new components then and never use a normal standard TButton anymore.

 

Edited by Rollo62

Share this post


Link to post
8 hours ago, Rollo62 said:

to use consequently your own set of standard component wrappers.

Like TEdit => TEditEx, TLabel => TEditEx, TButton => TButtonEx, ... as intermediate wrapper-layer around every standard components.

Main reason of this redeclaration magic is not to have to install descendant component with all that boring stuff of building a package, registering unit, adding components to palette, renaming all existing components and so on.

Share this post


Link to post
36 minutes ago, Fr0sT.Brutal said:

Main reason of this redeclaration magic is not to have to install descendant component with all that boring stuff of building a package, registering unit, adding components to palette, renaming all existing components and so on.

Not sure what you mean, didn't I say exactly that above ?

Anyway, a third approach could be thinkable, a complete "interposer-replacement", by replacing all the original system units of the original installation at once, by their same unit names with imposer wrappers.

Which then have the effect that you don't need to install new components or replace existing ones, just adding an intermediate layer to all system units with the same system unit name and classes.

That's just an idea, never checked that, because it's too much effort, but maybe that is a reasonable combination of my 1st and 2nd approach, to replace all system components at once to be their interposers.

Must check that idea one day, should be possible too.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×