HI,
I started to implement some WINAPI functions, becouse mwEdit dumps on some unimplemented results.
Since the implementation is platform dependent, this should go to the interface object. The only way to communicate was through sendmesseges. For a few functions I think this is OK, but for loads of API, whrapping parameters in structs an pass them.... nah

This reminded me of a discussion a while ago about an (abstract) baseclass. This could be a way to implenment all these functions. I started on this and committed the basic idea. If peaple have other thoughts I can change it back.

TInterfaceBase has an abstract declaration of
AppTerminate,
DoEvents,
HandleEvents,
Init,
IntSendMessage3,
SetCallback,
RemoveCallbacks

and WINAPI parts are defined in winapih.inc as virtual. Interfacebase.inc
implements all winapih.inc methods like:
  procedure TInterfaceBase.MyApiFunc;
  begin
  end;

It has NO code. This way not all functions have to be implemented in the specific platform InterfaceObject. (Thats the reason why they arent abstract)

The platform specific code (in this case GTK) goes in gtkwinapih.inc and gtkwinapi.inc

since these are still object.member functions, they are mapped through
normal calls' in LCLLinux (for now, I still have no idea where this should
go)
by winapih.inc and winapi.inc. The latter one just contains calls like:
  procedure MyApiFunc;
  begin
    TInterfaceBase.MyApiFunc;
  end;

This way I can now create my own say gtk GetDC and can mwEdit happily draw on it.

Marc

Apart from the TBaseClass discussion, wouldn't it be better to change mwedit so it doesn't use GetDC ?
A TCanvas will do the same, and TCanvas can be made platform independent.

I am not very fond of your solution, because it leaves too much platform specific stuff in your components; if you want to do some portable work, this should be avoided, IMHO.

Just my idea;

Michael.

Marc Weustink wrote

If you look in another way, what's the diference between InterfaceObject.Sendmessage(LM_DrawRect...) and

Actually I would hope you are not doing it this way. You should just be calling:

SendMessage(LM_DrawRect...);

The SendMessage routine is located in the controls.pp file. It isn't a part of TControl it is just located in this file since 95% of the time all components needs to use the controls unit. If you are calling InterfaceObject.whatever then that means your file must know about the Interface unit. The only unit that SHOULD know about and call it is the controls unit unless there is some overwhelming reason you must call interfaceobject yourself. This should be avoided.

InterfaceObject.Rectangle(...) ?

You wouldn't want to do this for the above reason. It would be better to create a Rectangle routine in controls.pp that called the interface unit. If we can keep all calls to the underlying GUI API going through just one place we can more easily adapt the LCL to other APIs.

michael wrote

Apart from the TBaseClass discussion, wouldn't it be better to change mwedit so it doesn't use GetDC ?

This is just an axample. If you leave out all API stuf, you'll end up creating an editor yourself.

A TCanvas will do the same, and TCanvas can be made platform independent. I am not very fond of your solution, because it leaves too much platform specific stuff in your components;

There will be absolutly no platform specific stuff any component this way. The only place is in the ???object (and their include files)

if you want to do some portable work, this should be avoided, IMHO.

Here I lost you, why do I lose portability if I add say GetDC as a function. (In fact I did and drew my first rectangles with Rectangle(DC, 1,2,3,4))

I won't say that all WINAPI stuff should be added. But for grapical things, it can be done.

If you look in another way, what's the diference between InterfaceObject.Sendmessage(LM_DrawRect...) and
InterfaceObject.Rectangle(...) ?

Marc

I think LM_DrawRect will be gone soon ( but thas something different ;-)

I know, I know, it was just an example to so the similarity between the way I implemented Rectangle and the way SendMessage is implemented. I somewhere wrote this in my original message.

For now I placed the includes in the LCLLinux, since there were already some API funcs

If we can keep all calls to the underlying GUI API going through just one place we can more easily adapt the LCL to other APIs.

Oops that was what I ment to say, was it that unclear ?

The only thing I wanted to say that all stays the same, except that instead of encoding your params in a struct, send them through a sendmessage and decoding them, you can call this function directly (like SendMessage)

Marc