[[lazarus] Design issues]

Marc Weustink Marc.Weustink at cuperus.nl
Tue Feb 22 09:57:09 EST 2000


+ From: Michal Bukovjan [mailto:mbukovjan at netscape.net]

+ Yes, I am thinking about this same thing. The virtual method
+ concept would be much more clear, maybe some abstract interface
+ object and then for each widget there could be a mapping
+ extended interface object descendant.

In fact we already have a great part implemented by an abstract interface.
Look at the interfacebase object. Only a few calls are through messages
(where Create is the largest one)

+ BTW, I wonder even Borland uses CM_??? concept which seems to
+ me redundant on many places. Does anybody know why use these
+ internal CM_ messages at all?

One set of CM_ messages were in the early days the raw WM_ messages windows
sent and the WM_ messages we saw were sometimes already handled by borland.

Another set of CM_ messages is used for internal notification in cases you
don't know if you are talking to a control. (More or less, once I found out
the reason why you use messages in some rare cases, but I can't remember at
this moment)
+
+ > - Also the tgtkcomponent.createcomponent seems to be a
+ >   rather strange idea to me!
+ >   As far as I can see you have always to modify the lazarus
+ >   sources if you're creating a new type of component?

Nope. This only is the case if a new base component is introduced. For now,
the answer is yes since not all gtk components are implemented. This will be
the case till we have a more stable environment, then we'll think of
something better.

+ > Both things have some impact on performance: FPC and the
+ > processor tries to do good branch prediction :), but you
+ > puzzle them by using a lot of case statements,
+ > let it me point out more precisily:

These cases statements are (AFAIK) now only a small part of the execution
path, so I think it wouldn't cost that much performance.

+ >
+ > Example TProgressBar.SetPosition:
+ >
+ > It calls ApplyChanges, well quite ok, but we wouldn't need
+ > to change all properties,
+ > but now SendMessage is called and here you loose two pieces
+ > of information in the data flow:
+ > the object type and what you want to do: SendMessage
+ > figures out again what you want to do by testing a lot of
+ > cases and setproperties figures out again of what class
+ > type the sender was! I think the processor has to do better things!

Again, fist get some things working, then try to speed up some things. In
the whole lot of statements executed these are only a small part (except if
you keep them calling)

+ >
+ > Clean proposal for a solution:
+ >
+ > twincontrol or tcontrol gets a pointer to a class ttoolkitinterface
+ > (similiar to the handle under windows) and ttoolkitinterface has
+ > childs like ttoolkitbutton with a appropritate methods.

Hmmmm.... seems a lot like tinterfaceobject, only then with more (clearer)
methods.


Marc






More information about the Lazarus mailing list