[lazarus] object creation

[Michael Van Canneyt]

On Thu, 20 May 1999, Shane Miller wrote:

> I believe each component should do it's own object creation.  I know that it was put in that one spot for ease of use initially.  
> 
> We have to seperate it from the classes eventually anyway if we are going to make
> this work with QT and the like.  I would say that there should be an external
> file that we call  to do all the creates.  Each class (tform, tbutton, tsomething)
> would call a procedure to create it's gtk/qt/lmnop widget and assign the appropriate
> events.  That way the source is seperate and we could act like we are doing a WINAPI
> call if we want.

It's very simple. Delphi uses a similar mechanism in TWinControl. TWinControl sets
a bunch of options (depening on properties) and then calls something like
CreateWindowControl which createss the actual control. This method is overridden
by all specific controls. (I'm using a slight simplification here)

You could do the same: Implement a abstract CreateWindowControl which creates the
actual GUI object. Call it from TControl and voila...

> 
> Shouldn't be that difficult, and if someone wants to move them, that's fine by me.  
> 
> I don't see any problem for people constructing their own components because they will
> simply fake a winapi (or whatever) call that will construct the widget.  If they are
> going real "low" level and creating a new gtk_widget, it simply gets added to the
> lazarus_gtk file (where the widgets are created) and they create a class called
> TCustomNewWidget where "NewWidget" is the name of their new widget.

> 
> I haven't really spent much time on this.
> I think instead of throwing out this info, perhaps we could get our strategy
> documented in HTML and displayed on the Lazarus site?  Any volunteers?
> A nice Component/Class structure tree would be cool.  That way we all see what the plan is and can talk about something concrete.

A component chart exists in the FPC docs. It's in PostScript (really easy)
and displays at the moment the classes in the FCL, together with their status.

The look is more or less the look of the Delphi Class Chart.

> 
> (get me talking and you can't shut me up)

Sure we can. Just throw you out of the mailing list :-)
Not very refined, but it would do the job :-)

Michael V.