First, I say add the wndproc. As a matter if fact, I think I added the procedure already, but I didn't code it.

Also, about adding it for GTK. Michael is against it beacause GTK does such a nice job allowing each signal to call a sperate callback that it seems like a waste, but you know, I've been thinking about that. I think that the callbacks should be assigned to the wndproc and the wndproc would do exactly what it does in Windows. It will check to see if the control gets that message and if so call the appropriate procedure for that control. I think that's the best way to do it. It also gives the developer the ability to override the wndproc. All we do is have it send the wndproc the msg variable and it can then tell what message was sent, and who sent it (by the self pointer).

Thoughts?
Shane

>> "Michael A. Hess" 09/30/99 05:49AM >>>

Samuel Liddicott wrote

Because Michael Hess is dead set against it.

Hooooold on!

I am not dead set against windproc. I am against making any of the code WIN32 specific or following a WIN32 design. If you can add windproc without the need of ifdefs and the like to implement it then fine by me. I just don't want to see alot of ifdef stuff being added so that the code will work in a pure WIN32 invironment when we already have lots of tools for doing that already. If the windproc stuff can be added to the base Lazarus classes so that it can be used with a Windows API set well then fine. However, unless I misunderstood something you wanted to add WindProc to work with GTK. Isn't that right? Since that isn't how GTK does the message handling I don't see how you could add doing it using the windproc method that Delphi uses without tying the LCL directly to GTK. If you can show me how, by all means do it.

Here is where you are mistaken. Not PLATFORM independant, WIDGET (API) independent. This is refering to GTK, Qt, wxWindows, XForms, XLib, etc. etc. etc.

In many cases such as GTK, wxWindows this widget sets already have a Windows (WIN32) version which means they would also be platform independant if they adhere to these widget sets.

He thinks supporting wndproc makes it windows dependant, despite the fact I tried to show it is just an extra layer of abstraction and therefore makes it less dependant.

Again maybe I am missing something here. Please show me again how, in code if possible, how you could do this and not tie directly to the widget API.

We can take it off of the mailing list to discuss. Just email me directly.

Stefan Hille wrote

In fact until today I thought this discussion was over and Sam is already working on this topic.

To be honest I did to. While I wasn't keen on the idea I thought that Sam was working on a way of doing it. I didn't realize that he had considered it squashed.

I am still not exactly sure what is the best way to get our hands around it but we most certainly can try. I have had my head in VB for the last 2 months and I have to get back to thinking Pascal. Tomorrow is my last day at my contract working on VB. (Yeaaah!) Next week I will be able to get back into the LCL in a big way. I will be moving the GTK stuff out into a subdirectory so that we can more easily separate API sets. At that time I can also work on the wndproc stuff unless Sam already has a grip on how to do it or as Shane stated he is almost at that point already.

What it will boil down to is moving the Dispatch call from the interface code into the LCL itself. Currently all of the dispatch calls are basically done from the interface code for each of the messages. Instead we can make one pipe from the interface into the LCL that inturn calls the Dispatch code OR traps it and ignores it if so desired. I think this is what Sam is after.

I have to agree that this will help separate the APIs better. Currently all calls to the API go through the SendMessage call and by using some sort of wndProc scenerio all calls coming back from the API will go through just one routine as well.

Is this OK with everyone? Is this what we are looking for?

Let's do whatever sam needs to get him moving along....

As long as it does not blow the platform independance I am all for it.

my 2c

Cliff

Shane Miller wrote

First, I say add the wndproc. As a matter if fact, I think I added the procedure already, but I didn't code it.

I absolutely agree!!!!!

In fact until today I thought this discussion was over and Sam is already working on this topic.

bye,

Stefan

I'm back.

I see much of the thought against the wndproc was because of implementation confusion.
I'll give a more thorough response shortly.

Sam