Oh wow. Excellent.
[BTW I've not been skiving, I've been snowed under as 2 projects draw to a close]

Sam

I am going to begin to look at a method of converting GTK to use the wndproc while I also look at the editor with Curtis (and anyone else who wants to help). I just added the LMLButtonDown procedures and I feel that the wndproc is really the only way to handle those correctly.

Shane

The great winproc debate...

Guys let me know if I am designing the event model in the QT engine correctly to support this also.

Inside the QT engine this is what takes place.

Each widget is assigned its standard events when it is created. If a event fires for instance a button is pushed. The click event calls a internal procedure that will call the single pascal handler for the appropriate dispatch. In this model I assume a single call back procedure for each component. So all event calls are recieved by single procedure attached to each component. In this way you can use a override to customize the event handling if necessary.

pacalhandler(intEventMessage)

  case intEventMessage of
   WM_CLICK
        dispatch call
   WM_DOUBLECLICK
        dispatch call
   WM_PAINT
        dispatch call

Is this the type of thing we are shooting for...I tried to stay out of the debate before but need to know the direction so that I can change the base engine now if necessary.

Cliff

Yep that was exactly my intent. I am going to pass back a pointer to data. If I just pass back a pointer to some arbitrary data it allows me to keep as generic as possible on the C++ side of things where I intend to run the engine thru the two etern defined C calls.

I guess another cool fallout of this is that our QT engine can easily be used with other languages that are pointer capable. I intend on putting in a base widget set and then stabilize the code. Once that occurs I am going to publish the library and the documentation and send it to the world as a generic QT interface and Freshmeat and KDE it. There was a C implemented version around somewhere but can no longer find it. Michael C said that it pretty much sucked anyhow. Then I will work on porting the stuff to the LCL. I am going for a alpha release by next friday.

first stabalized version out will be alpha liblazqt.01.so

Cliff

If possible, send the message struct (if you use that) to the wndproc and have the wndproc send out a message via dispatch to the control. This is what I asm going to do with GTK.......That's how delphi does it too.. Shane

>> "Baeseman, Cliff" 10/21/99 12:32PM >>>

The great winproc debate...

Guys let me know if I am designing the event model in the QT engine correctly to support this also.

Inside the QT engine this is what takes place.

Each widget is assigned its standard events when it is created. If a event fires for instance a button is pushed. The click event calls a internal procedure that will call the single pascal handler for the appropriate dispatch. In this model I assume a single call back procedure for each component. So all event calls are recieved by single procedure attached to each component. In this way you can use a override to customize the event handling if necessary.

pacalhandler(intEventMessage)

  case intEventMessage of
   WM_CLICK
        dispatch call
   WM_DOUBLECLICK
        dispatch call
   WM_PAINT
        dispatch call

Is this the type of thing we are shooting for...I tried to stay out of the debate before but need to know the direction so that I can change the base engine now if necessary.

Cliff

Nearly. This handler could dispatch all those messages - but generally shouldn't. The ancestor implementation of this function will call self.Dispatch which then uses the very fast pascal message dispatcher to call routines declared like:

  Procedure Click(Sender : TObject); message WM_Click;

Of course the handler can be overridden and intercept messages the way you showed above, equally well new message handler routines could override the level [Dispatch is a Delphi method]

Sam

Yep. Oh, excellent!

Sam

TControl is 75% done
TWinControl 75% done
TCustomForm clientwndproc exists, but is empty now.

Cliff, you can start coding your end of it. The messages may not get dispatched correctly yet, but you sure can assign them to call the correct wndproc.

I haven't looked at it but I would guess that FORMS use TCustomForm's as the main entry point, etc and the TWINCONTROL get "inherited"?

Anyway, anyone else that wants to code come wndproc's take a free to grab a class and go for it.

Shane

>> "Baeseman, Cliff" 10/28/99 01:54PM >>>

Yes we do need the event thing solidified so that I can move on.

Cliff