Because CM_ messages are not interpreted by windows default wndprocs; it supposedly stops accidental message storms.

I think.

Having done it that way makes debugging easier because you can instantly rule out a lot of scenarios; cm_ is never processed by windows wnd_procs.

Sam

Hi!

I think you're right although I'm not absolutely sure about it (we'll have to look at this one day).

Again, fist get some things working, then try to speed up some things.

I agree!

If I understand it right, the original author talked of a secondary class hierarchy. Taken to the extreme, this could result in lazarus being only a Delphi-compatibility layer, wrapping a complete & fully functional class hierarchy. Nice idea, but IMHO we should really focus on getting things up and running.

This means: I'd really like to have a working library round about June! Since I've still a lot of work to do, I can't help much before mid of march, but if things go well I can then spend a week or two.

bye,

Stefan

+ From: Shane Miller
+
+ I agree this sounds good. We need to look into it a bit
+ further but I would still like to get those people familiar
+ with this project working on the editor code and not this. I
+ would prefer to get the editor working before we rip apart
+ and redo the base classes. Unless this is hindering us, I
+ feel we should continue on. If we had someone new to the
+ project that isn't involved in another part of it currently,
+ then they could look at this and try to change it but I want
+ this editor up and running first. That would make things a TON easier.

Thats the same I try to say.
(and if you look really close, we aren't that far from the opposed solution)

+ What are the major issues with the editor that need changing
+ at this point?

Hmmm... can't think of major issues, the only things I can remember are:

* Focus. I think I forgot somwhere a focus in the gtkwinapiwidget so the editor doesn't get focus (and isn't drawn like that)

* Caret. Hide caret need to be implemented (minor, not really needed now)

* Fontcache. This weekend I received the code for a fontcache. I'm thinking of adding it tonight

* Instantiating a second editor sometimes crashes

* Keep focus of the arrow keys (I'll look at that)

* The rest is IMHO more IDE related.

Marc

Hola,

Escrib�a Michal Bukovjan , hablando de Re:
[[lazarus] Design issues] con fecha 22 Feb 00 11:57:31 MET,

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?

Did you mean "CN_"?

These are component notification messages. Application fetches all messages from app queue provided by Windows in the loop inside Application.ProcessMessages. In conventional Windows programs the message is sent unchanged to the... (I think that it's sent to the) parent window of the control (~the form). In Delphi the message is converted to a CN_ notification message and sent directly to the component.

The component is able to preview it, overriding its CN_xxx method. By default it converts the message back to a standard Windows message and call its own default proc (the associated Windows control). From this moment, the message runs the "normal" journey in non-Delphi Windows apps.

Why this intermediate step?. Because Delphi lets the component to review what's coming for it before it's thrown to the Windows way of message distribution. In other words: components code are part of the application logic that is descentralized.

greetings

Nico

I agree this sounds good. We need to look into it a bit further but I would still like to get those people familiar with this project working on the editor code and not this. I would prefer to get the editor working before we rip apart and redo the base classes. Unless this is hindering us, I feel we should continue on. If we had someone new to the project that isn't involved in another part of it currently, then they could look at this and try to change it but I want this editor up and running first. That would make things a TON easier.

What are the major issues with the editor that need changing at this point?

Shane

>> 02/22/00 05:39AM >>>

methodpointers

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

I, too, don't like huge case statements, it just doesn't feel good :-)

- 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? If you want to be toolkit independend you could create functions like CreateButton, CreateToolbar etc. The same applies to tgtkobject.setproperties

That would end up being the same - creating new functions for new widgets.

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,

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

(similiar

to the handle under windows) and ttoolkitinterface has childs like ttoolkitbutton with a appropritate methods.

Hmm, definitely worth considering.

Michal Bukovjan

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

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

CM_ messages are used for posting messages, when you need not some action to be executed immediately, but rather be posted to the message queue. This is used rarely, but sometimes it is the easiest way.

Dmitry Osinovsky,

methodpointers

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

I, too, don't like huge case statements, it just doesn't feel good :-)

- 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? If you want to be toolkit independend you could create functions like CreateButton, CreateToolbar etc. The same applies to tgtkobject.setproperties

That would end up being the same - creating new functions for new widgets.

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,

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

(similiar

to the handle under windows) and ttoolkitinterface has childs like ttoolkitbutton with a appropritate methods.

Hmm, definitely worth considering.

Michal Bukovjan

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

I think it was an evolutionary thing. The current way in which components are created is far different from how it was done at the start. It might very well be a good idea to look back at how this transfer of information takes place.

I think I understand what you mean but could you explain it a little better? When is the above pointer information loaded?

+ From: Michal Bukovjan

+ 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

Hi,

I'am still curious about some design decisions of lazarus:

- Why do you still use the strange message concept to communicate with the toolkit interface??? Virtual methods or another class ttoolkitinterface could easily do the trick. I know messages are a clean OOP concept but in compiled languges they are replaced by virtual calls or methodpointers
- 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? If you want to be toolkit independend you could create functions like
CreateButton, CreateToolbar etc.
The same applies to tgtkobject.setproperties

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:

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!

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.