[RE: [lazarus] CVS updated]]

Samuel Liddicott sam at campbellsci.co.uk
Mon Aug 23 06:21:11 EDT 1999




> -----Original Message-----
> From: Michal Bukovjan [mailto:mbukovjan at netscape.net]
> Sent: 17 August 1999 04:34 PM
> To: lazarus at miraclec.com
> Subject: Re: [RE: [lazarus] CVS updated]]
>
>
>
> > "csComboBox" that is currently held in fCompStyle.
> >
> > This value will be filled by the control when when CreateParams
> is called.
> >
> > I have:
> >
> > Procedure TWinControl.CreateWnd;
> > var
> >   Params : TCreateParams;
> > begin
> >   CreateParams(Params);
> >   // Params.WinClassName now contains GTK compstyle
> >   { Somehow use the GTK unit to create object but I haven't
> looked that up
> > yet }
> > end;
>
> The point here is that the TWinControl does not have anything to
> do with GTK.
> It should be widget-set abstract.

It is widget-set abstract.  Well actually its not its tied into windows api
and windows window model but on examination we wouldn't do things much
differently to make it abstract; we can cope easily.

In fact in this respect gtk is similar to windows; CreateWnd and
CreateParams merely decide which widget of the bound widget-set should be
used to repesent this TWinControl descendant on screen.  It is this that
allows loose coupling between the FCL and any particular widget set (we
don't want to rely too strongly on the similarity between FCL properties and
widget set properties for a particular component)

> It just calls SendMessage with
> the message
> LM_CREATE (I think it is in CreateComponent method now), and the
> SendMessage
> is mapped to whatever interface unit you need. If you are creating your
> project for GTK widgets, it calls the (Int)SendMessage(3) from
> GtkInt.pp, if
> you are creating for Win32, the Win32Int.pp, and so on.

Hmmm.  CreateWnd should probably be what contains (or calls) whatever
LM_CREATE does.  Certainly LM_CREATE is not a Delphi way of creating
controls, in fact WM_CREATE is a message sent AFTER a control has been
created.  From winapi help:

The WM_CREATE message is sent when an application requests that a window be
created by calling the CreateWindowEx or CreateWindow function. The window
procedure for the new window receives this message after the window is
created but before the window becomes visible. The message is sent to the
window before the CreateWindowEx or CreateWindow function returns.

> So since handles and stuff like this is one widget set specific (Win32
> widgets), it should be not present in TWinControl (in spite of
> its ridiculous
> classname). The CreateWnd stuff should be inside LM_CREATE
> message handler in
> Win32Int.pp, if possible.

I think that the LM_CREATE handler contents should be called by CreateWnd,
yes, but I'm not certain of the wisdom of LM_CREATE; esp. the with confusing
and different use of WM_CREATE.

> Also note that fCompStyle is a helper property only, and may be
> obsolete by
> now. It does not have anything to do with GTK.

Right.  I move for its obselesance; and that any control override
CreateParams in order to provide an indication of which RAW XXX-widget it is
linked to.  In Delphi certain controls (buttons, list boxes, edit boxes
memos and LITTLE else) are based on native windows controls, and with GTK
could be based in similar raw gtk controls, but practically all other Delphi
controls are based on raw do-nothing windows.  CreateParams is where a
VCL/FCL control identifies its GUI-widget preferbce.  Although in win32
WindowClassname is a pchar, we could also use it as a longint in FCL+GTL to
hold the csComponentThingy values we pass on to GTK.  All we really care is
that it is some kind of token/cookie used by the widget-manager.

> 6. Please note that the original CVS state (lazarus-old dir)
> should be created
> when you begin to make your changes. If it is not, be VERY
> careful, because
> the patch would recognize and add your changes, but would delete
> any changes
> commited to CVS by others during the time you coded. Always
> review your diff
> file (it is a plain text file) to see what it is doing.

ack!  Better start again ah well.

> 7. Send the patch for someone to review, I think someone from the
> core team
> (Shane? Cliff?). If he likes it, he will apply that into the CVS.
>
> 8. The patch may be applied by issuing from the CVS root dir :
> patch -p1 -i mypatchfile.diff
>
> { You will apply that patch after you checkout the CVS for latest
> changes, and
> viola, your changes are within too :-)
>
> 9. The patch may be reverted (i.e. puts the CVS tree back to its original
> state) by issuing
> patch -R -p1 -i mypatchfile.diff
>
> {This is for core member team, if he does not like your changes :-)
>
> If you are in Windows, God bless you :-)
> No, seriously, I think that the GNU utils are for Windows somewhere, too.

I'm doing this in linux.

Thanks!

Sam






More information about the Lazarus mailing list