TFruit class moved to component

[WalkingAway 1]

Let say I have this class, TFruit:

 

unit MyUnit;

interface

uses
  SysUtils;

type
  TFruit = Class
    private
      color  : string;
    protected
    public
      constructor Create(color: string);
    published
      property color: string
        read   string
  end;

I can make the instance
rocedure TForm1.FormCreate(Sender: TObject);
var
  banana : TFruit;
begin
  banana := TFruit.Create('red');

 

Now:

How I can achive the same functionality if it would possible to make component - the same TFruit and visible property color in IDE?
And then if I drop component,  this instance of TFRuit is made for me automatically...

Is it possible?

For now only I can imagine - some / any TComponent descendant and some FFruit: TFruit property...

Thanks

[Anders Melander 1784]

You (mostly) just need to derive your class from TComponent:

type
  TFruit = class(TComponent)
  private
    FColor: string;
  protected
  public
    constructor Create(AOwner: TComponent); override;
  published
    property Color: string read FColor write FColor;
  end;

...and then you also need to register your component:

procedure Register;
begin
  RegisterComponents('Cool Stuff', [TFruit]);
end;

 

I suggest you read the documentation.

[David Schwartz 426]

There are a few books on the subject of building components. The Bad News is ... they're all from the 90's. The Good News is ... very little has changed. 

 

I'm familiar with all of them except the last one. If you like print books, grab one of these at a cheap price and it'll teach you most of what you'll need to know.  The link above is from Embt and can help you fill in the gaps.

 

NOTE: These are Amazon affiliate links because they're really easy to get. I found prices lower on eBay, although there may have been shipping costs as well.

 

Delphi Component Design

by Danny Thorpe

https://amzn.to/3K2hzwm

(I don't know why this book is so frigging expensive everywhere, maybe b/c Danny is no longer with us. It's an excellent book and worth grabbing a copy if you can get one cheap.)

 

Developing Custom Delphi Components: Master the Art of Creating Powerful Delphi Software Components 

by  Ray Konopka

https://amzn.to/44jMe09

Visual Developer Developing Custom Delphi 3 Components: Master the Art of Creating Powerful Delphi 3 Software Components 

by  Ray Konopka

https://amzn.to/3NN4J68

 

Programming Delphi Custom Components 

by  Fred Bulback 

https://amzn.to/3Q0Nn8G

 

I think there's also a book by Ray Litchke. I'm not sure if I spelled his name right or not, and I couldn't find anything.

 

 

 

[Anders Melander 1784]

52 minutes ago, David Schwartz said:

I think there's also a book by Ray Litchke.

Ray Lischner. He wrote 3 Delphi books, AFAIR, none of them about component design. I've got "Delphi in a Nutshell" (basically just a reference book) and "Hidden Paths of Delphi 3" (about the old open tools API). Both had horrible binding and fell apart right away.

[David Schwartz 426]

On 7/16/2023 at 5:20 PM, Anders Melander said:

Ray Lischner. He wrote 3 Delphi books, AFAIR, none of them about component design. I've got "Delphi in a Nutshell" (basically just a reference book) and "Hidden Paths of Delphi 3" (about the old open tools API). Both had horrible binding and fell apart right away.

Ahh, you're probably right. Thanks for clarifying that. 

[WalkingAway 1]

Thank you guys!

 

I have got it.

Just came here to ask next level's question and saw unread messages

 

I will check those books of course

 

But anyway, is it possible to achieve something like this (I mean totally in IDE, design time):

I have basic class TSQLBuilder and then it has property TSQLBuilderProvider - abstract, it can be let say FireDac, UniDac, AnyDac...

 

1) For every of them then can be setted up Query + Connection: for FD - TFDQuery and TFDConnection, for UniDAC - TUniConnection and TUniQuery and so one

So far I did it through connectionString property, but it's boring as I have to build it outside this component

Something similar to this - drop TSQLBuilder to the form and then there is some abstract property TSQLBuilderProvider, but if on form on f.e. TSQLBuilderProviderFD or TSQLBuilderProviderUniDac, it was possible to set it in design time.

 

2) Second thing: property that makes sence for one TSQLBuilder, but not usable / posible for other. For example if I chose FD as type, then there is type string property - MySQL, MSSQL or SQLite. I dont need obviously this property forTSQLBuilderProviderFireBird. Probably this option have to be hidden according to other property

 

Thank you so much

Of course, its pretty hard to make something good enough, this topic more about education I guess.

Thanks again
 

[Remy Lebeau 1398]

2 hours ago, WalkingAway said:

But anyway, is it possible to achieve something like this (I mean totally in IDE, design time):

Yes, certainly.  And very much as you described it.

 

You have a base component class named TSQLBuilderProvider, which has virtual/abstract methods as needed.  Then you derive several DB-specific classes from it, which implement those methods.  Each class can have its own DB-specific properties as needed.

 

Then you have a TSQLBuilder component, which has a published property of type TSQLBuilderProvider.

 

Now, you can drop a TSQLBuilder component and a DB-specific TSQLBuilderProvider component onto your Form, and assign the Provider to the Builder.  And then the Builder can use the abstract/virtual methods to interact with the Provider.

2 hours ago, WalkingAway said:

For every of them then can be setted up Query + Connection: for FD - TFDQuery and TFDConnection, for UniDAC - TUniConnection and TUniQuery and so one

For that, it would make sense to expose additional properties on each DB-specific Provider component.  TSQLBuilderProviderFD could have published properties to assign TFDConnection and TFDQuery components to.  TSQLBuilderProviderUni could have published properties to assign TUniConnection and TUniQuery components to.  And so on.  Then the implemented methods can use those properties as needed.

2 hours ago, WalkingAway said:

Something similar to this - drop TSQLBuilder to the form and then there is some abstract property TSQLBuilderProvider, but if on form on f.e. TSQLBuilderProviderFD or TSQLBuilderProviderUniDac, it was possible to set it in design time.

Yes.  That is basically what I described above.

2 hours ago, WalkingAway said:

2) Second thing: property that makes sence for one TSQLBuilder, but not usable / posible for other.

That is why they should be exposed by the individual Provider components, not by the Builder component.

[Uwe Raabe 2057]

On 7/17/2023 at 1:15 AM, David Schwartz said:

Delphi Component Design

by Danny Thorpe

https://amzn.to/3K2hzwm

(I don't know why this book is so frigging expensive everywhere, maybe b/c Danny is no longer with us. It's an excellent book and worth grabbing a copy if you can get one cheap.)

I luckily managed to grab a copy in good condition (including CD) for unbelievable 12.38€ - sometimes it pays to have relatives in the U.S.

Now I only have to wait for them visiting us in November, but looking at the ~65€ they tried to charge for shipping it to Germany that is definitely the better option.