First, I realized that once you stored the sender, you didn't need to store the parent but I didn't want to send out an email just for the purposes of stating my realization.

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.

Shane

>> 01/07/00 02:30PM >>>

you wrote

I am working on the function GetWindowLong. You pass a handle (in gtk's

case it's the pgtkwidget being passed) and a constant that identifies what element you are looking for.

In this case we are interested in Window Style (GWL_STYLE), handle to the

parent (GWL_HWNDPARENT), the HInstance for the window (GWL_HINSTANCE) , the address of the wndproc (GWL_WNDPROC) and other things of that nature.

Without the class (the sender) I can't acceess the Parent property, or the

address of the classes wndproc so I was thinking of doing a

gtk_object_set_data when the widget is created to store the parent and

itself (the sender property) and then I can get most of that stuff from that.

Anyone have an alternative suggestion???

As the winapi now is implemented it has no knowledge of LCL and I think that a good thing.
So (a quick idea) why instead of setting the sender object and the parent object (?? ifyou have the sender you have the parent ??) just set GWL_STYLE, GWL_HINSTANCE, GWL_HWNDPARENT, GWL_WNDPROC as data.

Marc

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

you wrote

I am working on the function GetWindowLong. You pass a handle (in gtk's

case it's the pgtkwidget being passed) and a constant that identifies what element you are looking for.

In this case we are interested in Window Style (GWL_STYLE), handle to the

parent (GWL_HWNDPARENT), the HInstance for the window (GWL_HINSTANCE) , the address of the wndproc (GWL_WNDPROC) and other things of that nature.

Without the class (the sender) I can't acceess the Parent property, or the

address of the classes wndproc so I was thinking of doing a

gtk_object_set_data when the widget is created to store the parent and

itself (the sender property) and then I can get most of that stuff from that.

Anyone have an alternative suggestion???

As the winapi now is implemented it has no knowledge of LCL and I think that a good thing.
So (a quick idea) why instead of setting the sender object and the parent object (?? ifyou have the sender you have the parent ??) just set GWL_STYLE, GWL_HINSTANCE, GWL_HWNDPARENT, GWL_WNDPROC as data.

Marc

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.
GWL_EXSTYLE, GWL_STYLE
can
GWL_WNDPROC , DWL_DLGPROC
this one is incompatible with the windowproc we use (that's an object instance pointer this is a pointer) GWL_HINSTANCE
depends on application and doesn't have to be stored in the class
GWL_HWNDPARENT
obvious
GWL_ID
?? the gtkwidget as ID ??
GWL_USERDATA, DWL_USER
this is userdata and I think you want to store this in the class

DWL_MSGRESULT
??

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

I am working on the function GetWindowLong. You pass a handle (in gtk's case it's the pgtkwidget being passed) and a constant that identifies what element you are looking for.

In this case we are interested in Window Style (GWL_STYLE), handle to the parent (GWL_HWNDPARENT), the HInstance for the window (GWL_HINSTANCE) , the address of the wndproc (GWL_WNDPROC) and other things of that nature.

Without the class (the sender) I can't acceess the Parent property, or the address of the classes wndproc so I was thinking of doing a gtk_object_set_data when the widget is created to store the parent and itself (the sender property) and then I can get most of that stuff from that.

Anyone have an alternative suggestion???

Shane

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....

---------------------------------------
Shane Miller

Get paid to surf the net!
http://alladvantage.com/go.asp?refid=DEX-870

Home page : http://www.lakefield.net/~smiller

Auto-IP Publisher : http://www.lakefield.net/~smiller/autoip

Advanced Clipboard : http://www.lakefield.net/~smiller/advclipboard

Lazarus : http://www.miraclec.com/lazarus

MakeObjectInstance gets round this and gives a flat procedure pointer for a object/method address pair.

Sam

[some recompilation]

From: Shane Miller

+ From: "Marc Weustink"
+
+ > 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

I agree that there should be no GTK or QT code in the winapi header file. With the function GetWindowLong, all the code is found in the gtkwinapi file. This will make it possible to do what wwe plan on doing.

Eventually I would like to write the code to call X functions to get this information (in some cases) and bypass the gtk for certain things. This would be more efficient and also work better because we could still use those functions in QT and such.

Shane

>> 01/10/00 05:39AM >>>

[some recompilation]

From: Shane Miller

+ From: "Marc Weustink"
+
+ > 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

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