[lazarus] GetWindowLong

[Marc Weustink]

[some recompilation]

From: Shane Miller [mailto:smiller at lakefield.net]

+ From: "Marc Weustink" <weus at quicknet.nl>
+
+ > At 14:05 07-01-2000 -0600, Shane wrote:
+ >
+ > >Second, just setting those specific items as data won't work
+ > >because there are more than just those.  I just gave those as
+ > >an example.  there are a few more I would use so I was thinking
+ > >of storing the class which would encompass everything.
+ >
+ > Hmm... if I look at the winhelp there are only 6 more :-)
+ > But some of them you can't put them in the class.

[snip styles]

+ >
+ > seen this I think it makes not a big difference of storing
+ > them all, you have to store some of them anyhow. Besides that
+ > GetWindowLong is an API function and I think that it is not
+ > a good thing to mess up the LCL with these.
+ >
+ > Marc
+ >

+ Yes, I see there are only 6 more and I began adding them like you
+ suggested....
+ I'm not sure what you mean about messing up the LCL with
+ these though....

You all might have sometimes have an idea how to solve something, but you're
not complete finished with it. At such a moment it is hard for me to express
my thoughts in english and it might result in expressions which do not cover
the thoughts I have. This was an example of that.
In general one of the ideas I have for the far future (Lazarus starts to be
a design IDE) is to extract the winapi functs from LCL. I mean here that the
api is no part of LCL but has a life of its own. A requirement for this is
that there are no LCL dependencies in the winapi. The way everything is
implemented now, I think this is possible.
What's the fun of it? It gives cleaner code. All functionality is
implemented at their own level. It makes also porting easier.
I'm I dreaming? I don't know. As I said, it's one of these unfinished
thoughts and I haven't examined all pros and cons

Marc