Difficult to tell. That was the reason I posted the original message. I didn't have a clear vision, but I'll try. (The more I think about it, the more I'm in doubt)

I now see two options:
1) The callbacks are set at one place at the lowest possible class level, based upon the compstyle. In our case this would be T(Win)control.

2) The callbacks are set the way it is done now. Every control set the event it needs.

In my thoughts you always wanted all the events possible, so that, as a developer in a later stage, you don't have to take care of "asking' for events.
If you do want that, what place knows better what events there are?... The interfaceobjects. So in my original message I saw just a routine that, based upon Compstyle, set the callbacks.
This way you just get your messages, you can handle them if you want. Like Delphi, I don't ask for events, they are just there. And if you want to handle a message wich isn't there... bad luck. It's like Windows, if you want to handle say WM_SETFOCUS in a TLabel, be my guest, but you wont get many messages.

Another point is platform dependency. You allways want the same set of messages. That pleads for a routine in LCL. So you can assure the same messageset is available on every platform

Now I start to see that here Lazarus might differ from Delphi. I think that you might not want every possible event.

The point is I resumed my work on TWinControl.CreateWnd (mwEdit didnt get any events) and I dived into loads of double/triple calls to the same SetCallBack, unused callbacks, events being there and no callback set...etc. I allmost drounded.

If this is indeed the point where LCL differs from VCL, I'll introduce T(win)Control.AttachEvents and T(win)Control.DetachEvents and that would be the place to call SetCallBack

Where would you think they should be???

See previous

Marc

Marc Weustink wrote

If this is indeed the point where LCL differs from VCL, I'll introduce T(win)Control.AttachEvents and T(win)Control.DetachEvents and that would be the place to call SetCallBack

I would like to see them not be called from in the component itself. For example the TButton.CreateWnd now calls the SetCallBack. I myself don't like it there because, as you pointed out, it isn't very Delphi like and some people coming from the Delphi world wouldn't even understand what it was for. I originally was located in TButton.Create and then moved to CreateWnd. It was in TButton.Create because it was at that point that the actual component/widget whatever was created. Things have really changed since then. We now use the CreateWnd and only create the component/widget whatever when it is needed. That being the case I would like to see the SetCallback moved down into the lowerlevel routines that call the components CreateWnd. As you pointed out they can use the style setting to determine which events need to have callbacks set. As you pointed out it doesn't prevent someone from adding a callback that isn't standard but there isn't any guarentee that it will be honored.

My concern was that your statement was that it should be moved out of the LCL which I think is a mistake. It should just be at a lower level in the classes.

I am for this move but think some other things need to be cleaned up first. Or shall I say get working. I myself haven't been digging around to much due to lack of time on my part but it has been pointed out to me that many of the previous controls and components that previous worked no longer do so. Take TButton for example. This doesn't even show up in any of the example programs any more. I assume this came about due to the change to CreateWnd but I hope we can get this working again.

Once we are sure that every thing is working correctly with SetCallBack were it is then I say move it to a lower control level.

What say thee???

+ From: Shane Miller

+ I have no problem moving the SetCallback into another
+ function and having it called at a "more appropriate" time.
+ However, we have made some changes (createwnd,
+ interfaceobject) that we shouldn't have made because we are
+ still recovering from these. Lets get something (ANYTHING)
+ up and running as is and then make these changes.

Sometimes you run into these problems because you want something to get running (and it allmost does :-)

+ The events
+ work now,

Great

+ let's geet the editor working and start developing
+ the IDE. I would hate to make changes that would delay the
+ development of the editor, which we need badly.

Thats true, but you need some changes (like message ranges overlapping each other ;-)

Marc

I have no problem moving the SetCallback into another function and having it called at a "more appropriate" time. However, we have made some changes (createwnd, interfaceobject) that we shouldn't have made because we are still recovering from these. Lets get something (ANYTHING) up and running as is and then make these changes. The events work now, let's geet the editor working and start developing the IDE. I would hate to make changes that would delay the development of the editor, which we need badly.

Shane

>> 12/05/99 03:48PM >>>

Thats the reason I came with T(win)Control.AttachEvents. At this place the SetCallbackCalls are made. And gets called somewhere in the line of Handle to CreateWnd. I personally was thinking of a call in CreatWnd, but there might be a "deeper" function

My concern was that your statement was that it should be moved out of the LCL which I think is a mistake. It should just be at a lower level in the classes.

I start seeing that. Sometimes you have half an idea and you need to talk to someone to see the pros and cons

Some controls (wich arent used in lazarus itself) still create and setcallbacks in the constructor. Since I use the lazarus.pp as check if everything wors I hadn't seen them. I'll look at the examples. BTW buttons not correctly showing is fixed

Once we are sure that every thing is working correctly with SetCallBack were it is then I say move it to a lower control level.

That was what I had in mind first and the reason I wrote this.

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

Thats the reason I came with T(win)Control.AttachEvents. At this place the SetCallbackCalls are made. And gets called somewhere in the line of Handle to CreateWnd. I personally was thinking of a call in CreatWnd, but there might be a "deeper" function

My concern was that your statement was that it should be moved out of the LCL which I think is a mistake. It should just be at a lower level in the classes.

I start seeing that. Sometimes you have half an idea and you need to talk to someone to see the pros and cons

Some controls (wich arent used in lazarus itself) still create and setcallbacks in the constructor. Since I use the lazarus.pp as check if everything wors I hadn't seen them. I'll look at the examples. BTW buttons not correctly showing is fixed

Once we are sure that every thing is working correctly with SetCallBack were it is then I say move it to a lower control level.

That was what I had in mind first and the reason I wrote this.

I think all this is due to a lack of managagement and structure planning! =o) Instead of getting something (anything!) working, perhaps Marc's example should be followed, and it would be a very high priority to plan and complete the base classes first. Perhaps doing so in a way that will simplify using higher level inheriting classes as well as creating new ones, but while keeping extreme flexibility already offered by the OO design.

Perhaps developping the base classes in parallel with let's say a TButton, and once all is simplified and optimized for that, create something a bit more complex.. and adapt the base classes as well as TButton for the changes.. after a few components, the base classes should have the exact structure they need to accomodate the whole LCL.

If that did not make any sense.. then just ignore me =o)

Alex

--------------------------------------------------- Powered by Bell Canada / Commandit� par Bell Canada http://www.bell.ca/

Alex,

It does make sense. I agree that we should develop the classes to a point that they are "stable" and can be used to develop other things. I feel that they are at this point (barely) and I think that we should try to implement an editor based on these classes. Once that is complete I think the classes will evolve because it would be much easier to modify the classes with an editor that was meant for the pascal. Also, the reason we are pushing the editor is because it forces us to modify the LCL in a way that it's compatable with Delphi, and usable for the editor.

I have stated in the past that if we have a goal (an editor) we are more than likely going to find our problems in our components as we try to implement them.

If you have any idea's on how to manage or structure the development of this project, please let me know. i have found it quite difficult to get any structure/management in this project. I blame it on the internet, but it may be me....... :-)

Shane

I think all this is due to a lack of managagement and structure planning! =o) Instead of getting something (anything!) working, perhaps Marc's example should be followed, and it would be a very high priority to plan and complete the base classes first. Perhaps doing so in a way that will simplify using higher level inheriting classes as well as creating new ones, but while keeping extreme flexibility already offered by the OO design.

Perhaps developping the base classes in parallel with let's say a TButton, and once all is simplified and optimized for that, create something a bit more complex.. and adapt the base classes as well as TButton for the changes.. after a few components, the base classes should have the exact structure they need to accomodate the whole LCL.

If that did not make any sense.. then just ignore me =o)

Alex

--------------------------------------------------- Powered by Bell Canada / Commandit� par Bell Canada http://www.bell.ca/

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

What routines would these be? I think this is a mistake; I am certain that CreateWnd is the best place to set callbacks/attach events as it is part of binding the LCL control to its widget-existance, and if it is in CreateWnd then delphi users don't even need to really be aware of it at all.

I agree here.

Once we are sure that every thing is working correctly with SetCallBack were it is then I say move it to a lower control level.

I'm curious about what this low level would be.

Sam

Well, I stand corrected =o)

Marc Weustink wrote

The set of CallBacks is per ComponentStyle allways fixed, so why not doing this after to (gtk/qt/win/whatever)component is created (and move this out of LCL since IMHO it doesn't belong there)

Why do you think this????

Where would you think they should be???

OK; Once CreateWnd is working properly and a few basic controls (button, notepad form) I am ready to start porting the form editor.

Sam

Hi,
Just wondering, shouldn't the calls to SetCallBack be part of the creation of a window/widget ?

I mean, now the component is created in CreateWnd and the callback functions are set in CreateWnd/InitializeWnd (depends on the time you read this). The set of CallBacks is per ComponentStyle allways fixed, so why not doing this after to (gtk/qt/win/whatever)component is created (and move this out of LCL since IMHO it doesn't belong there)

Marc

Alexandre Grenier wrote

I think all this is due to a lack of managagement and structure planning!

I don't think it is totally fair to say this. I will admit we might not be using a complex plan but that is exactly what Megido tried to do and it fell flat. Also, Lazarus has changed and flowed in it's design and goals since it was started. In the beginning it was being coded strickly for use with GTK. Then we looked at coding to use Glade. Then we decided to make it completely API independent. Then we setup the messaging scheme toward that end. Then we motified that to more closely parallel how messaging is done in Win32 and Delphi. If you look at the code we started with around 7 months ago and look at what is being done now it is completely different. I personally think it is this lose managagement and flexible structure which has allowed us to progress as far as we have with this project.

Instead of getting something (anything!) working, perhaps Marc's example should be followed, and it would be a very high priority to plan and complete the base classes first.

Well in fact for the most part the base classes have been written along time ago. We have had the various dialogs available, most of the standard controls, Lables, Buttons, Menus, Tabs, etc. The problem is that as the final goal changes as in the case now where we have focused on getting tools like mwedit to work with minimal changes, we need to go back down into those base classes and rework that code that had previously been working OK.

I understand what you are saying but then I wonder if you have looked at some or any of the base classes found in the LCL and the FCL on which we are building our code. It is very tight and complex allowing for the inheritence you mentioned. Had we stuck with the straight GTK model we could have had working tools long ago. But by chosing the flexible model and now building it so that it can more closely port Delphi code we just need to go back into those base classes to change how messaging and things like that are dealt with.

All I have been trying to say is that please don't be confused or think that the LCL isn't being build on a good foundation, aka. base classes. It is and has been and in fact very little has changed in the TControl, TComponent, TObject classes for months. What has changed is the color paint we have been deciding to paint the blocks making up the foundation. Very soon the mwedit tool will be able to be used as an IDE base which will allow us to work even better on building the Forms Editor tool.

OK. I'll get off my soapbox now. :-)

Alexandre Grenier wrote

From reading the messages, I fell under the impression that the LCL was deisgned in a way that we (the users) would have to do stuff we should not have to do.

No, that is exactly what we are trying to avoid. We want what would be normal basic Delphi code to work in both Lazarus and Delphi. In fact it already does that. It is a simple matter to write an application using buttons, labels, etc. in a window.

The Hello program in the "lazarus/examples" directory shows that point. It is simple the main file which in Delphi would be the .dpr file. The main form file which is helloform.pp. It defines the form and assigns methods to events such as button1Click. The only difference at this point is that you must include a ".Create" as the constructor because it doesn't deal with .DFMs yet. This also means you need to define those properties in the .Create you would normally define in the DFM file. Other than that it works and looks exactly like a Delphi application. In fact I used the indentical code in Delphi to build the same application.

As soon as we get through the IDE and then the Form Editor we will be able to code the TForm to not required the .Create but use the information found in the .LFM in the same fashion as Delphi does. While it might not be possible to port some programs originally written in Delphi it will be very easy for an experienced Delphi programmer to immediately be able to code using FPC and the LCL.

Maybe there is a way one component could be built with 2 interfaces, and in delphi compatibility mode it would abstract Delphi's interface.. this sounds dumb, but that way we'd be independent from borland's "innovations"

I don't think we intend to make Lazarus be totally compatible into the future. We are building Lazarus to match some of the Delphis features and capabilities as it now stands. Once that is done I would invision Lazarus going on a different path from Delphi. Look at it this way. The reason we want compatibility now is so that someone who has already written a Delphi app can port it as easily as possible. If after Lazarus is release they do not use Lazarus to build their Win32, Linux, or whatever application and continue to use Delphi it isn't our concern to make their port easy. They should just use Lazarus in the first place.