Michal Bukovjan wrote

I presume that gtkint.pp, as well as lmessages.pp, should now only about TControl, NOT its descendants.

No that is not the case.

Here is what is going on in a nut shell. We are trying to remove gtk, gdk, and glib dependence from the LCL (Lazarus class libraries). We are doing this by placing ALL gtk+ calls within one unit. At this point in time it is called gtkint.pp (plus .inc's). The LCL components and controls don't know anything about the gtkint and how it does anything. The LCL just passes requests to the gtkint unit with the SendMessage function. However the gtkint knows ALL about the LCL. It can access, refer to, place in uses clause ANY LCL unit and use the information found there. So if you want to declare a unit in the uses clause of gtkint for an LCL control so that you can access class information, go right ahead.

Again let me repeat this. In the end all of the standard LCL units will NOT reference gtk, gdk, glib, or gtkint (aka interfaces). The only unit that will reference the gtkint (aka interfaces) unit will be controls.pp and the only unit that will reference the gtk, gdk, glib will be gtkint (aka interfaces).

**************************************
|-------| * |--------| |-------| | |----> calls from LCL ---->| |--> calls to -->| | | LCL | to widget set * | gtkint | | gtk+ | | | via SendMessage * | |<--callbacks <--| | |-------| * |--------| from |-------| ^ * |
| calls to anyplace * |
|--- in the LCL accessing <---------|
a class object *
**************************************

Everything with the asterisk section is what is GUI API specific. By keeping this type of separation we will be able to plunk a different set of code for different API's into this area with out modifing the LCL. The LCL just talks to this via the SendMessage function. It doesn't know what the API must do to honor that message request.

I think this is far more information than you were asking about but I thought it might also help the lurkers on the list. :-)

Hmm, that was just an idea.
The problem I am trying to solve is more about efficiency and architecture. I presume that gtkint.pp, as well as lmessages.pp, should now only about TControl, NOT its descendants. Now I need to pass information in messages, like the TComboBoxStyle information, so that the GTK dependent object could set up the things properly. So I would need the lmessages.pp know about TComboBoxStyle, therefore make it use stdctrls.pp, not only controls.pp (I want to avoid this typecasting thing where possible). Now this would result in linking in a lot of stuff from that unit, or not?
Is it legal for me to reference the stdcontrols.pp unit in lmessages.pp?

Once again, I may be completely wrong (that's why I request for comment, rather than making a suggestion). I have an experience form one of my project, that I needed some simple type information about TTable (maybe TFieldType ? - don't remember now). I had to include a unit (DB?, or DBTables?). Thanks to this, the project size rose about 100k, and of course, the unit had some initialization stuff, doing things I did not need.

So in short, the problem is, how to reference a TComboBoxStyle type in lmessages, preferebly without typecasting in both lmessages and gtkobject, or even declaring new types or constants, the most efficient way.

Michal Bukovjan

____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.