the gnu utils are packed with the compiler...patch diff make etc etc...

Cliff

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)

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.

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.

ack! Better start again ah well.

I'm doing this in linux.

Thanks!

Sam

The point here is that the TWinControl does not have anything to do with GTK. It should be widget-set abstract. 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.

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.

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

any

more checkouts for fear of loosing mu own changes. Or can I somehow

combine

the current CVS and keep my own changes ready for checking in?

To keep your existing changes with CVS, create patches. Under Linux, it is simple.

1. Copy your existing lazarus stuff with changes (lazarus directory) into a new directory, say /usr/src/lazarus-new

2. Copy current CVS state into another directory, say /usr/src/lazarus-old

3. From both directories, remove binary files, *.ppu and *.o. You may also want to remove /CVS subdirs

4. From the /usr/src directory, write :
diff -ruN lazarus-old lazarus-new > mypatchfile.diff

5. Optionally, you may gzip the patch by issuing
gzip mypatchfile.diff

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.

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.

Michal Bukovjan