Greetings,

I just added the dialogs.pp unit with gtk dependence removed.

One note. Do NOT destroy the Open File Dialog with the 'X' at this time. I will fix this problem but it currently doesn't clean up some widgets correctly. The "OK" and "Cancel" work correctly.

I also add SetBounds to the TControl. This allows you to modify the dimensions and position of a component and only fire the resize event once instead of each time for each position changed.

Added a SendMessage method to TControl so that any component can send messages to the interface unit with out having to directly use the unit.

I added a DoEvents method so that if you are in an extended loop in your code you can call this to make sure events get taken care of.

Modified the CreateComponent so that it passes Self to the interface. Most of the items currently passed are already in Self and I needed Self to be able to complete the dialogs. This will make some of the messages easier to manage.

Shane,

I left the IntSendMessage, and IntSendMessage2 as they are and added IntSendMessage3. We should try and modify the other to also use Self. Don't pass individually what we can pass as class data.

All of use seem to be doing some major work at this point and I tried to avoid touching more than I had to to get dialogs working. With the new messaging stuff it should prevent much of this in the future. I was able to compile lazarus as it stands in CVS right now.

I understand what you mean but don't forget that none of this code is gtk specific. It doesn't have ANY gtk code in it. The above SetLeft or SetBounds calls something like

  InterfaceObject.IntSendMessage2(LM_SetSize, Self, @R);

It sends a LM_SetSize message to the interface object which is whatever API is attached to it. The only thing that needs to be changed if the API changes or even if gtk changes is the call in the gtkint.pp unit and all the class libraries will then work correctly.

We could have half a dozen different class library routines modify size, captions, colors, etc. etc. etc. and only the modifications for the API only need to be made in one place, the gtkint.pp unit.

The way we are writing it absolutely none of the class library will need to be edited to use a different API.

In principle, all other Position/Size stuff should call SetBounds in the end. This way you only need 1 call to be ported when going to a new toolkit; namely setbounds.

Just a thought.

Michael.

What I meant whas that you could implement it like

Procedure  TControl.SetLeft (Value : Integer);
begin
  SetBounds(Value,FTop,FRight,FBottom);
  FLeft:=Value;
end;

This way the code is reduced to a minimum. In the event GTK changes, or you go to a new toolkit, You only have to adjust SetBounds.

Michael.

Actually they all call the same routine as far as porting goes. It is just that when you do something like

Left := 100;

it calls the appropriate gtk routines to adjust the component which then fires a resize event. If you have to set all 4 coordinates it does the whole process 4 times, somewhat wasteful. By using SetBounds it sets all the coordinates with just the one gtk call and resize event. Just somewhat more effecient.