+ From: Vincent Snijders
+
+ I just checked everything out and I do get an error when I
+ try do make lcl,
+ lazarus or the examples. I do not know if it is caused by
+ your conflicts.
+ This is the error I get:
+
[snip output]

+ This is not the first time a get this error of a missing
+ textrec.inc. Most
+ of the times it goes away after a few days and a few
+ checkouts. I do have a
+ textrec.inc in the rtl/inc directory.

This has nothing to do with lazarus. Try to build your rtl again. The point is your rtl sources are newer than your rtl objects and the compiler wants to rebuild your rtl. In my case this only works if I do a make in the rtl dir.

Marc

+ From: Stefan Hille
+
+ Hi!
+
+
+ I just committed my changes and both components (and
+ examples) are working
+ again.
+
+ I'm not absolutely sure if everything went right with my
+ commit, so it'd be
+ nice if somebody could check it. Specially I'm not sure if
+ everything is OK
+ with gtkobject.inc because I had to resolve a conflict there.

Hmm.... I see that some of my changes are gone. What works for me preventing this is after I've changed a lot, I do an update first, resolve the merging conficts, look what the differences are, look if it still compiles, do a update again and if nothing has changed... the commit. This way you are allmost sure that you didn't loose anything.

I'll try to fix it from here.

+ My approach is now to only create the basic object during the
+ Create without
+ caring too much about the current object properties. In the
+ InitializeWnd
+ proc I'll then send another message to the interface (e.g.
+ LM_ChangeTrackbar)
+ and the interface will then set the current object
+ properties. This seems
+ useful to me, because the component-properties may be changed during
+ program flow which would require recreation of the visual component if
+ I would set everything during create.

Nice work.

Marc

BTW, when I have the time I might implement RecreateWnd

I just committed my changes and both components (and examples) are working again. I'm not absolutely sure if everything went right with my commit, so it'd

be

nice if somebody could check it. Specially I'm not sure if everything is

OK

with gtkobject.inc because I had to resolve a conflict there.

I just checked everything out and I do get an error when I try do make lcl, lazarus or the examples. I do not know if it is caused by your conflicts. This is the error I get:

fpc]$ cd /opt/fpc/lazarus
lazarus]$ cd lcl
lcl]$ make clean
rm -f vclglobals.ppu lmessages.ppu utrace.ppu controls.ppu graphics.ppu interfac
es.ppu lcllinux.ppu interfacebase.ppu gtkint.ppu dialogs.ppu stdctrls.ppu comctr
ls.ppu forms.ppu menus.ppu spin.ppu buttons.ppu extctrls.ppu imglist.ppu tabnotb
k.ppu registry.ppu clipbrd.ppu messages.ppu
rm -f fpcmade.lnx ppas.sh link.res log
lcl]$ make
ppc386 -Fu/opt/fpc/rtl/linux -Fu/opt/fpc/units/linux -Fu/opt/fpc/fcl/linux - Fu/o
pt/fpc/packages/gtk -FE. -di386 vclglobals.pp
ppc386 -Fu/opt/fpc/rtl/linux -Fu/opt/fpc/units/linux -Fu/opt/fpc/fcl/linux - Fu/o
pt/fpc/packages/gtk -FE. -di386 lmessages.pp
linux.pp(750,2) Fatal: Can't open include file textrec.inc make: *** [lmessages.ppu] Error 1

This is not the first time a get this error of a missing textrec.inc. Most of the times it goes away after a few days and a few checkouts. I do have a textrec.inc in the rtl/inc directory.

I hope this a is clear enough. If not mail me or just let it be. It probably will go away again in a few days,

Vincent Snijders

+ From: Stefan Hille
+ I'm not absolutely sure if everything went right with my
+ commit, so it'd be nice if somebody could check it. Specially
+ I'm not sure if everything is OK with gtkobject.inc because
+ I had to resolve a conflict there.

Fixed.

Marc

Hi!

I just committed my changes and both components (and examples) are working again.

I'm not absolutely sure if everything went right with my commit, so it'd be nice if somebody could check it. Specially I'm not sure if everything is OK with gtkobject.inc because I had to resolve a conflict there.

[..InitializeWnd and/or AttachSignals...]

Thanks for your explanation. I now derived both of them for TTrackBar and TProgressbar.

My approach is now to only create the basic object during the Create without caring too much about the current object properties. In the InitializeWnd proc I'll then send another message to the interface (e.g. LM_ChangeTrackbar) and the interface will then set the current object properties. This seems useful to me, because the component-properties may be changed during program flow which would require recreation of the visual component if I would set everything during create.

I hope this clears most of your questions, if still unclear you can allways ask.

Tahnks again.

bye,

Stefan

That's exactly the way I work so I wonder a little how it happened. In my case cvs gave me a conflict message, retrieved two versions of gtkobject and made marked some lines in the source at the beginning of TGtkObject.SetCallback. Is this the place where your changes were lost?

BTW: After resolving the conflict I did another update to ensure that nobody else modified the file while I was fixing the problem.

I'll try to fix it from here.

Thanks.

bye,

Stefan

you wrote

Hi, I just started to update TTrackbar & TProgressbar to the new interface

Great

None!

You only need to override InitializeWnd and/or AttachSignals. The control is created based upon FCompStyle (however in the future it might be based upon CreateParams (and API))

AttachSignals: Here you place your calls to SetCallBack for all events not yet defined by TWinControl. (In most cases only some specific events for your control) Allways call inherited.

InitializeWnd: (Shouldn't be used it but I'll describe the initial idea) The control caches values as long as no visual component is needed. For instance to set the value of a trackbar, you dont need the visual part. The code in InitializeWnd gets called after the component is created. Here you can code to initialize to newly created component. On second toughts this routine shouldn't be needed. The routine (your create routine in gtkobject) which creates the visual part should take care of this.

- Is it neccessary to call HandleNeeded in every method which requires the object instance?

Yes, but I think in most cases you only need it for the visual property (and thats handled in TWinControl). For properties like height width value and thinks like tat you don't need the visual part (and no call to handleneeded)

- What about BeginUpdate / EndUpdate methods?

????

I hope this clears most of your questions, if still unclear you can allways ask.

Marc

Hi,

I just started to update TTrackbar & TProgressbar to the new interface but I'm not sure how to do things.
Currently both crash whenever the first action takes place which needs the instantiated object, which has not been created at that time. Since I don't know the new functions in detail I'd like to know:

- which of the above methots have to be overriden?
- Is it neccessary to call HandleNeeded in every method which requires the object instance?
- What about BeginUpdate / EndUpdate methods?

BTW: When updating my system I noticed that some stuff has moved to the packages directory which has to checked out from cvs. Could somebody please update web-pages accordingly.

bye,

Stefan

Yes I made changes in the same place. Think I was'nt careful enough when resolving the conflicts, sorry.

I've now started to do some work on TCheckBox and will continue with TRadiobutton. Hope to get something done until weekend because next week I have to start working again.

bye,

Stefan

+ From: Stefan Hille
[snip]
+ Yes I made changes in the same place. Think I was'nt careful
+ enough when resolving the conflicts, sorry.

No worries, as long as people tell that there were conflicts, you can easily reapply your changes. (better than finding out later while debugging and discovering: ??? I thought that I had fixed this ???)

Marc

+ From: Stefan Hille

+ That's exactly the way I work so I wonder a little how it
+ happened. In my case cvs gave me a conflict message,
+ retrieved two versions of gtkobject
+ and made marked some lines in the source at the beginning of
+ TGtkObject.SetCallback. Is this the place where your changes
+ were lost?

Yes. I moved the code to retrieve a GObject from a TObject to a separate func. Somehow the tree of if statements came back. Probably because you also changed the same piece of code.

+ BTW: After resolving the conflict I did another update to ensure that
+ nobody else modified the file while I was fixing the problem.

I do the same (and as a practical side effect I see what files I had changed :-)

Marc