[lazarus] More Native Win32 stuff (Pascal, can youhelphere?)

[Michael A. Hess]

Jeff Wormsley wrote:
> 
> On 8/10/99, at 9:52 AM, Shane Miller wrote:
> 
> >Each component would have it's own unique windows procedure because
> >each control create's it's own unique TControl.
> 
> Currently TControl does not define a windows procedure, and adding one
> would mean putting Win32 directly into the LCL, not moving it out
> under Interfaces.  Could it be that the windows procedure would be
> ignored under linux?

As long as the procedure itself is located in the interfaces or
win32int.pp (madeup file name) then it is still separating things. We
would then just have to include the same procedure in the gtkint unit
but it would just be empty and not do anything.

I'm not totally sure of what I am talking about because I have never dug
down into the Windows messaging stuff to see how it works. So I'm not
sure how the window procedure works or what it does.

The idea of the separation of the LCL and API is so that you don't need
to change your application code when using a different API. If we need
to add some variables and the like to the LCL TControl class so that it
can work with an API well then we do that. We just have to make sure
that each API interface we write deals with the calls or variables
correctly. In some cases that might mean just having empty procedures
that don't do anything other then exists so that linking works.

I'm quite sure we will find more of the same problems when we try a QT
version or even a Gnome version for that matter.

Do you get my drift here? For example if you look at the Hello World
example. It talkes only to the LCL. It doesn't know from API and
shouldn't. The user should just be able to link his code with a
different xxxint.pp file and it should work with xxx API. How the LCL
and the different API's handle this is up to the LCL and API developers.
Namely us at this point.

Did that make any sense???

-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com