[Re: [lazarus] Where is customlistbox.inc?????]

[Michal Bukovjan]

Now, I am responsible of all of these, so try to explain.

"Michael A. Hess" <mhess at miraclec.com> wrote:
> Curtis White wrote:
> > 
> > I had the same problem. The only way I could get it to compile, so I
> > could work, was to comment out all the listbox interface definition
> > and the include.
> 
> I did the same thing as a temporary measure.
> 
This looks like Shane did not succeed in applying a patch I sent. I do not
know where is the mistake, and will communicate with Shane to resolve the
problem. (We are trying to make use of this diff/patch thing and apparently it
did not work as expected).
Meanwhile, I send the file.

 
> > I also noticed two new units, gtklistsl.inc and gtklistslh.inc. What
> > are these?
> > They are done completely different than all the rest of the components
> > (they are a GTK specific listbox). Was that done for a reason? Or is
> > it just some work code?
> 
These units are to replace gtkcombosl.pp and gtkcomboslh.pp, respectively.
This unit contains a specific implementation (GTK specific) of TStrings done
for GtkList, in a way that is transaprent for all components. I suggest we use
more of these where appropriate.
Note that this inclusion files are meant for inclusion in gtkint.pp ONLY (it
is a part of it). The basic idea is, that a list box (or any other component)
that manages its strings may do it two ways :
1) Maintain its own TStringList. This duplicates the string in memory, since
they are held in components' memory and its respective widget memory.
2) Use an abstract interface to communicate with its widgets strings
directly.
The second way is quite efficient and in fact this is the way it is done in
Delphi. In Delphi, TStrings is just a base abstract class and its strings are
managed only in its descendants. TStringList is one of its descendants,
managing its strings in its own memory.

So the idea, used in TComboBox and TListBox, to create a GTK component through
CreateComponent, and then call a message to the InterfaceObject LM_GETITEMS
which returns a pointer to a newly created TStrings descendant. The descendant
is GTK specific, but QT implementation creates its own TStrings descendant and
so on. Not the the actual component, TComboBox, knows only about TStrings (no
GTK dependency).


> Yeah I saw that myself. I didn't get a change to look at it yet to see
> what it is doing. I will as I move the gtk stuff to a separate
> directory.
>  
> > Michael, do you need us all to change our components to work with the
> > new SendMessage layout?
> 
> The change is simple. I have incorporated a change in all the code
> (except notebook just didn't get to it yet). All of the
> InterfaceObject.IntSendMessage and ..2 and ..3 calls have been boiled
> down into one call
> 
> function SendMessage(themessage : integer, Self : TObject, data :
> pointer) : integer;
> 
> This is a global function placed in controls.pp. Since just about every
> unit uses this unit this should always be available. So as long as you
> just placed uses controls in your unit you can call the above procedure.
> This means that controls.pp should be the ONLY unit that will need to
> reference the interfaces unit. I want to get this separation so it will
> be easier for me to redo the current layout and move the gtkint stuff
> down into a subdirectory.
> 
> The SendMessages is just a combination of IntSendMessage2 and
> IntSendMessage3. It returns an integer value. If you are written NEW
> code that needs to send a message place it in the IntSendMessage3 method
> in gtkobjects.inc. I have moved most of the IntSendMessage2 messages
> over to IntSendMessage3 but check over the next day or so if you need to
> call something that you know was originally in IntSendMessage2. I might
> be about a day before I get it all cleaned up and moved over.
> 
> So to answer your question, no you don't have to change your components
> I have already done so or am doing so.
>  
> > Also, we should probably rename the stdcontrols unit to stdctrls so it
> > matches Delphi. Just one more easy thing we can do to provide more
> > compatibility. Don't you think?  I can do it if everyone agrees.
> 
> Might not be a bad idea but let's not touch that one for now. Give it a
> few days for alot of these changes to settle down.
> 
> -- 
> ==== Programming my first best destiny! ====
> 
> Michael A. Hess      Miracle Concepts, Inc.
> mhess at miraclec.com   http://www.miraclec.com
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00006.bin
Type: application/octet-stream
Size: 5009 bytes
Desc: "customlistbox.inc"
Url : http://localhost/pipermail/lazarus/attachments/19990807/28682f34/bin00006.bin