I don't remember enough about what all WndProc does, but we should to be careful here because from what I remember (and have gained from the discussion), I think the WndProc procedure handles API specific messages that are passed to the control. If this is the case, then it seems to me that it is going to require a lot of API calls from the WndProc procedure. So that means it would be calling right back to gtkint. That seems like extra overhead that may not be necessary (performance). But like I said, maybe I don't know enough about how WndProc works. I just want to make sure we don't miss something here.

Curtis

makes no difference to me I am for it...

Cliff

wndproc is not out of favor for windows controls, but for GTK it is. Each control sets a callback for EACH signal so we dispatch them that way.

The msg's aren'tr being passed back yet because no one has coded them yet. A few of them are already coded, like keydown.

I'm not sure about converting everything to use wndproc. How does wndproc handle it then? Does it simply do a dispatch? I haven't looked at Delphi's method of handling this, so I'm not awarer of it.

Shane

>> "Samuel Liddicott" 08/16 11:49 AM >>>

Are wndprocs are completely out of favour in lazarus?

I see the gtkcallback uses dispatch directly; also it seems many of the callbacks do not pass back the result of the dispatched message to gtk.

Is this right?

I think the callbacks should not call Dispatch, but WndProc.

It is TControl.WndProc (first object where wndproc is declared (virtual, not override) that calls dispatch for all messages that have made it thus far (usually unhandled messages, not always - I'm not sure if dispatch will pass on messages that have been handled).

WndProc acts like a pre-dispatch interceptor, and DefaultHandler acts like a post-dispatch interceptor.

In delphi the DefaultHandler calls the window-controls own default wndproc.

Broadcasts are sent to the wndproc of controls - also VERY useful for messages unknown at design time - RegisterWindowMessage et al.

So; I'm suggesting that instead of calling Dispatch, gtkcallback calls the wndproc. (Maybe if it is a TControl descendand - otherwise (for csCanvas etc call dispatch)?

Is this OK? If so I will make the changes to include in the diff's I will send up.

Sam

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

hmmm..I see that. I don't see why it would be bad to call TControl(Data).wndproc(Message) instead of dispatching them right away. I think that would be a good idea plus it would help with our Delphi compatability. I would also think that this would help in making it easier to add other widget tool sets.

Anyone against this change?
Shane

>> Marc Weustink 08/16 2:14 PM >>>

In delphi the WndProc is merely a big case Message.Msg of.... where finally (in TControl) a call is made to Dispatch

Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Only because its windows. In lazarus the wndproc will handle other messages. Wndproc is just a centalised message handler called before dispatch, if we want delphi compatability we must call wndproc before dispatch because it affects the ways in which messages can be overridden and intercepted.

Sam

you wrote

I don't remember enough about what all WndProc does, but we should to be careful here because from what I remember (and have gained from the discussion), I think the WndProc procedure handles API specific messages that are passed to the

Ever since the very beginning of the Windows SDK there have been two functions that every piece of Windows software has had:

1. Winmain()

This one creates the window, makes some initialization stuff, for instance and then enters the message loop:

     	while (GetMessage (&msg, NULL, 0, 0)) {
	         TranslateMessage (&msg) ;
	         DispatchMessage (&msg) ;
	  }
	2)	WndProc
	This one processes the windows messages:
	long    FAR PASCAL WndProc (hWnd, iMessage, wParam, lParam)
	HWND     hWnd ;
	UINT iMessage ;
	WPARAM   wParam ;
	LPARAM   lParam ;
	{
	/* variable stuff etc */
	switch (iMessage) {
        	case WM_DESTROY:
                /* Clean up and quit */
                KillTimer(hWnd,1);
                PostQuitMessage(0); /* Quit */
                break ;
        	case WM_CREATE:
                /* some stuff from an old app...*/
                pLogPal = (NPLOGPALETTE) LocalAlloc( LMEM_FIXED,
                                            (sizeof(LOGPALETTE)
			+ (sizeof(PALETTEENTRY)*(MAXP
                if (achFileName[0] && !InitDIB(hWnd))
                        PostQuitMessage (3) ;
	/* lots of case XX_XXX lines, including
	  mouse and keyboard messages etc,
	  API related stuff, anyhow*/
	}

In delphi the WndProc is merely a big case Message.Msg of.... where finally (in TControl) a call is made to Dispatch

Marc