control sets a callback for EACH signal so we dispatch them that way. A few of them are…
Show quoted text 13 lines
I don't know what you mean "bound to windows". How about "can be bound to windows"? But the only reason I'm interested in Lazarus is because it might compile Delphi source code with little change. The claim on the web site is that we are porting Delphi to linux because Borland won't. We even have the penguin wearing the Delphi wig. If we are only interested in superficial compatability, why even bother with that?
2) Leave out some Delphi solutions which had to be created/were suited for Windows, and supply our own, more versatile ones (be their Delphi-incompatible).
Ho ho. Don't forget we want to bind to more GUI's that GTK. OS/2 is also very win-like with a wndproc. We get speed OR flexibility.
Again, remember that Delphi is VERY designed for Windows, and if we want Lazarus for as much platforms as possible, we definitely will need to abandon some Delphi approaches.
If we want Lazarus for as much platforms as possible, we definitely do not need to rule out platform approaches.
The shiny example of the 2) is Handle, which is rarely found anywhere beyond Windows, and since Windows get COMized, not even there in the future (my guess).
The handle is "some" reference to the "real" object that is managed by the bound GTK. This is going to be used with whatever gui we bind to. OK, handle isn't the best name UNDER GTK but its a better name under some others (like Win or OS2).
The only reason for thinking a .wndproc slows things down is if you think what's in the wndproc isn't needed - and yes its faster if you do less. Wndprocs *are*
a) A primary place to intercept and *modify* ALL messages to a component before the dispatch
b) A place to intercept messages whose message number is not known at design time
There are a lot of *components* out there that rely on this mechanism! Honest! Few applications use it, but MANY components do.
We need support from existing Delphi components to make Lazarus more useful quickly. We don't want much (if any) work involved in porting over components.
If you like, let each component have a flag which says whether or not wndproc can be skipped. The GTK callback handler could check this flag and only call wndproc if it is not set.
But the fact is, wndproc ONLY slows things down to any degree if there is a lot in it - in which case it is obviously important; OR because there are a lot of messages going round - in which case the computer must be quite busy doing something so quite naturally the user expects it to take much more time than the wndproc overhead is going to add.
Trust me, we NEED .wndproc - HEY the delphi form designer "requires" .wndproc so it can intercept the paint messages to the form and paint the grid. The ability to intercept the wndproc of another component is also VERY COMMONLY USED. So we can't even presume that the primary .wndproc for a control is control.wndproc - but we can implement this later.
Sam