+ From: Stefan Hille

+ On Mon, Jan 03, 2000 at 11:08:15AM +0100, Marc Weustink wrote:
+ > + From: Stefan Hille
+ > +
+ > + - There's a problem with all classes derived from TGraphicControl.
+ > + (currently these are TPaintBox and TBevel).
+ > + The problem is, that there are a lot of places where these
+ > + are casted to TWinControl, although TGraphicControl is
+ > + derived from TControl.
+ >
+ > Hmm... odd, I first thought this was an historical point,
+ > but since the introduction (1.15) is had been derived from
+ > TControl. I think these casts should be altered. +
+ Do you mean that we should derive TGraphicControl from
+ TWinControl or that we move some properties from TWinCOntrol
+ to TControl?
+ I have no particular opinion about this.

I mean that it should be derived from TControl (like Delphi). What properties of TWincontrol are needed ? LCL specific ?

Marc

Do you mean that we should derive TGraphicControl from TWinControl or that we move some properties from TWinCOntrol to TControl? I have no particular opinion about this.

Ok, I did that today and introduced the following new messages

- LM_GETVALUE - to get the value from the interface
- LM_SETVALUE - to set the value when it was changed by the application
- LM_SETPROPERTIES - to set all properties for a component

Example:

TTrackBar uses

LM_GetValue never, because any change is handled in the OnChange callback

LM_SetValue when someone set the Position property LM_SetProperties when any other property is changed that requires an update of the GTK object

TCheckBox uses

LM_GetValue whenever the 'checked' property is read LM_SetValue whenever the 'checked' property is written

bye,

Stefan

Hi,

hope you've all recovered now from your millenium parties;-)

Ok, here some things I've noticed during the last days of development:

- There's a problem with all classes derived from TGraphicControl. (currently these are TPaintBox and TBevel).
The problem is, that there are a lot of places where these are casted to TWinControl, although TGraphicControl is derived from TControl.

any suggestions how to solve this?

- TCheckBox is quite OK now, but if you assign OnClick and try to find out if the object is checked/unchecked you'll get the wrong state. Seems as if GTK is calling the handler before it actually changes the state.

- I'm not sure about it but it seems to me as if some controls (e.g. TCustomForm) don't recognize if their visual representation changes. For example if you resize a form the width/height properties won't get updated.
Could anybody please check this.

- To keep the properties of TTrackBar / TCheckBox up to date I introduced some messages (LM_GETCHECKBOX...) which will sync the state of the lazarus object with that one of the GTK library. I think that we'll need more of these messages in the future and I'd like to create one special message for this. In the gtk interface we could then make a new procedure

  which makes a "case fCompStyle of". Thus we could avoid a lot of
  different messages.
  Any comments?

bye,

Stefan

+ From: Stefan Hille
+
+ Hi,
+
+ hope you've all recovered now from your millenium parties;-)

:-)

+ Ok, here some things I've noticed during the last days of development: +
+ - There's a problem with all classes derived from TGraphicControl.
+ (currently these are TPaintBox and TBevel).
+ The problem is, that there are a lot of places where these
+ are casted to TWinControl, although TGraphicControl is
+ derived from TControl.

Hmm... odd, I first thought this was an historical point, but since the introduction (1.15) is had been derived from TControl. I think these casts should be altered.

+ any suggestions how to solve this?
+
+ - TCheckBox is quite OK now, but if you assign OnClick and
+ try to find out if the object is checked/unchecked you'll get
+ the wrong state. Seems as if GTK is calling the handler before
+ it actually changes the state.

It looks like the state is changed on a keyup instead of a key down The order of events is currently
LM_[KEY|BUTTON]DOWN : triggered by gtk event
LM_[CHAR|CLICK] : generated after down

LM_[KEY|BUTTON]UP : triggered by gtk event.

Hmmm... I just did some experiments in Delphi and it seems that I generate the click event to early. It should be part of XXXUP and not XXXDOWN. I'll fix that tonight.

+ - I'm not sure about it but it seems to me as if some controls (e.g.
+ TCustomForm) don't recognize if their visual representation changes.
+ For example if you resize a form the width/height properties won't get
+ updated.
+ Could anybody please check this.

Noticed that before. Could be caused by the recent change of messages. For me it had a low priority, but if somebody else can look after it...

+ - To keep the properties of TTrackBar / TCheckBox up to date
+ I introduced some messages (LM_GETCHECKBOX...) which will
+ sync the state of the lazarus object with that one of the
+ GTK library. I think that we'll need more of these messages
+ in the future and I'd like to create one special
+ message for this. In the gtk interface we could then make a
+ new procedure which makes a "case fCompStyle of". Thus we
+ could avoid a lot of different messages.
+ Any comments?

You mean a message like LM_UPDATEVALUES ??? Sounds ok for me.

Marc