I want to remember this Patch, its good and as i see the correct Way. Why it is not applied ?

best regards
Christian Ulrich

Christian U. wrote

I want to remember this Patch, its good and as i see the correct Way. Why it is not applied ?

What LCL components listen to WM_COPYDATA?

Vincent

Why needs lcl components have to lissen to this ?
Its not possible to interface at example Winamp or Skype and a lot of other Win32 Applications becouse the lcl eats up this message.

Why the Win32 LCL message Handler can not transfer all Messages that he not process to the Application ? this is no overhead for the Message Handler.

best regards
Christian

This patch was not for the LCL but for general Windows compatibility. At the moment the Windows part of the LCL eats up the WM_COPYDATA-Messages, so you can't interact with quite some application using this message to exchange control information with other apps.

With this patch WM_COPYDATA will get throug the LCL-Messagehandler untouched and can be handled in the application specific messagehandler.

regards
Lukas

Compatibility with windows?

At the moment the Windows part of the LCL eats up the WM_COPYDATA-Messages, so you can't interact with quite some application using this message to exchange control information with other apps.

If you want to use WM_COPYDATA messages on windows, you can add your own windows handler with windows.setwindowlong. No need to polute own LCL-message handler with it.

With this patch WM_COPYDATA will get throug the LCL-Messagehandler untouched and can be handled in the application specific messagehandler.

I don't think we should add this to our event handler. Let the application specific message handler handle it. Maybe it should be easier to add one, but OTOH, what is difficult about this? Windows.SetWindowLong(MyForm.Handle, GWL_WNDPROC,
PtrInt(SubClassWndProc));

Let's keep the LCL win32 widgetset interface clean and just add things that are used by the LCL and keep custom extension outside it.

Vincent

If you want to use WM_COPYDATA messages on windows, you can add your own windows handler with windows.setwindowlong. No need to polute own LCL-message handler with it.

We want to be Delphi comaptible, right ???
And i dont know if this is real an pollution, i suggest to transfer all unknown Messages to the Application so we never have the problem and its no overhead for the lcl.

Let's keep the LCL win32 widgetset interface clean and just add things that are used by the LCL and keep custom extension outside it.

Then please remove the WM_USER message support.
We cannot decide one time for something and next ime for another.

best reagrds
Christian

In the past I thougth that using SetWindowLong was hard. It isn't. It will return the address of the current WndProc, so you can just have your WndProc like this:

begin
  if Msg = WM_COPYDATA then
 ...
  else CallOldWindowProc;
end;

And you don't lose anything. With a clever code you can even use the same wndproc for any control, just take care to call the correct old wndproc in each case.

No. To a certain height, we want the LCL to be *VCL* compatible. Currently LCL doesn't need handling of WM_COPYDATA, so no need to let the interface send it to the LCL.

And i dont know if this is real an pollution, i suggest to transfer all unknown Messages to the Application so we never have the problem and its no overhead for the lcl.

That would break the LCL, removing or not adding WM_COPYDATA would not. I do suggest to create component specific windowproc and move all relevant parts to that. But that is a different subject.

That would be my favorite too.

Vincent

SetWindowLong is an option I've to check.

But IMHO this is not a real solution to the problem. The Pascal-way of handling Messages is to define a custom messagehandler. This is how it is done in countless applications.

In some later post in this thread you write "...we want the LCL to be *VCL* compatible..." and in the VCL this is the way to go.

So I'm quite shure, that this should work in Lazarus accordingly.

So perhaps we should take a look at the LCL messagehandler in total to stop it from eating up messages that are not necessary for the LCL.

I, for my part will keep my patch till there is a better solution - I'm not willing to change all the custom Message-Handlers I wrote in the last 15 years (or something like that - I use WM_COPYDATA quite a lot) if there is a simple way to avoid this.

regards
Lukas

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080218/20d43486/attachment.pl

Mattias G?rtner wrote

Where is this documented?

On MSDN. Unless you are implying this should also be on the wiki, which is only true if it's really decided that WM_COPYDATA shouldn't be sent to the application, and the discussion doesn't seam to be over.

Zitat von Felipe Monteiro de Carvalho :

As far as I am concerned the discussion is over: There is SetWindowLong to setup win32/64 specials messages. Where is this trick documented? I would expect it either under tipps/tricks and/or the win32 interface page.

Mattias

To a certain height. I should have added, as long as we can make it work cross widgetset, cross platform.

Maybe this patch works:
Index: win32/win32callback.inc
===================================================================
--- win32/win32callback.inc	(revision 14180)
+++ win32/win32callback.inc	(working copy)
@@ -2141,14 +2141,10 @@
          exit(TWin32WidgetSet(WidgetSet).FOnAsyncSocketMsg(WParam, LParam))
      end;
    else
-    // pass along user defined messages
-    if Msg >= WM_USER then
-    begin
-      LMessage.Msg := Msg;
-      LMessage.WParam := WParam;
-      LMessage.LParam := LParam;
-      WinProcess := False;
-    end;
+    // pass along all messages
+    LMessage.Msg := Msg;
+    LMessage.WParam := WParam;
+    LMessage.LParam := LParam;
    end;
    if WinProcess then

If this is accepted, we never have to worry about blocked messages, only about messages that may crash the LCL (because of an unexpected message), slower applications because some messages are sent to the LCL unnecessary and messages that are only sent on windows.

Vincent

In some later post in this thread you write "...we want the LCL to be *VCL* compatible..." and in the VCL this is the way to go.

100% agree.

So I'm quite shure, that this should work in Lazarus accordingly.

Yes.

Seems taht the core developers work against the users here. WM_COPYDATA is an thing that is used very often in Windows. For my opinion the best way is to pass this message also to the lcl. The overhad is minimal and only on windows there and the compatibiliy we win with this is big.

Who from you (The core developer) works realy on windows ? And who on "real world" Applications ?

best regards
Christian Ulrich

Maybe an define is the best way to hide this. Who realy needs all messages can define

-dPassAllWin32MessagesToLCL

so everyone is happy....

best regards
Christian

Christian U. wrote

> In some later post in this thread you write "...we want the LCL to be > *VCL* compatible..." and in the VCL this is the way to go. >

Please, use complete quotes, IOW, don't misquote me.

100% agree.

Vincent

I tried it and it didn't work. Too much tabs were created in the IDE, causing an out of index exception for the pages. But maybe it is ok for real world applications. ;-)

Vincent

If you implement WM_COPYDATA on qt and/or gtk to prove that it can be implemented platform independently, then it can be added to the LCL. Otherwise it is a win32 special and should be kept there (i.e. the win32 intf).

Mattias

I guess people working on real world applications use TSimpleIPC for interprocess communication, it is crossplatform and cross widgetset. I just inspected its implementation and not much to my surprise it uses WM_COPYDATA on windows.

So using TSimpleIPC instead of WM_COPYDATA has a minimal overhead, is not only on windows and the cross platform compatility we win is big.

Vincent

*grml* ;)

So maybe we can just add the WM_COPYDATA patch ? Also possible in an define ?

best reagards
Christian

I dont want it in the LCL, i want that only the WIN32 Interface posts this message to the Application.
An Cross Plattform Version of this makes no sense for me, we have bedder IPC Services in other OS.

I use also the IPC Classes when i can but a lot of already exising Win32 Apps use WM_COPYDATA so i have no choice.

That's needs a definition of "real world applications". I have to interact with a bunch of applications outside the Lazarus world - so TSimpleIPC is not an option.

So using TSimpleIPC instead of WM_COPYDATA has a minimal overhead, is not only on windows and the cross platform compatility we win is big.

This is true for applications which are built from scratch using Lazarus /FPC and without interaction to software built outside of Lazarus.

I think there are quite some developers out there that have (like me) several millions lines of code they don't want to throw in the waste basket. For us compatibility is a real big issue.

I, for my part, need a solid tool to earn my living with, and I'm willing to improve this tool in the areas I'm working on. But my main focus has to be my business and the usability for my customers and not the tool itsself.

regards
Lukas

I think we should apply the WM_COPYDATA patch.

I don't think this small modification, specially if well commented and documented on the wiki would alone increase the difficulty of developing the win32 interface.

Lazarus exists exactly to be useful for people, and if this will make it more useful then it's a good thing. Of course we need to balance that with having a consistent and easy to maintain framework, but being a small patch which covers an important use case I'd go for it.

Similarly I'd be against sending any message to the application, because it's a change with multiple repercussions.

thanks,

Maybe it becomes an 'important use case' if it mentioned on http://wiki.lazarus.freepascal.org/Projects_using_Lazarus

;)

We should leave the final decision to the win32 devels. They have to maintain it the next years.

Similarly I'd be against sending any message to the application, because it's a change with multiple repercussions.

Mattias

Felipe Monteiro de Carvalho wrote

I think we should apply the WM_COPYDATA patch.

I don't agree on that.

The messages received by the LCL are for VCL compatebility only. That they happen to have the same values as the messages the win32 widgetset uses is just a "coincidence"
Like we won't pass all events/signals/messages available for carbon/gtk/qt, we won't pass all for win32.
For the simple reason that messages are not cross platform.

I agree that we should think of a way that users can simply hook into the main message/event/signal loop it they want to write an app specific for one widgetset.
Adding all these messages/evets/signals to the LCL is not the way to do this.

Marc

Maybe Win32Widgetset.AllowMessage('WM_COPYDATA') ?

Best regards,
Paul Ishenin.

Paul Ishenin ha scritto:

or
{$ifdef PASS_WM_COPYDATA}
..Patch
{$Endif}

Then those who really need it (because of zillions of source code lines already written) will compile LCL with -dPASS_WM_COPYDATA. The others will never notice.

Giuliano

^Thats what i mean with "real World" Applications

regards Lukas

Maybe Win32Widgetset.AllowMessage('WM_COPYDATA') ?

I think this makes the Interface much more complex and for what ? Maybe this discussion happens for again 2-3 Messages. I dont think that it will be more.
The overhead of these 2-3 real importand messages that are passed to the LCL is minimal.
Also makes no sense to try to make some crossplatform stuff of them they have to exist only in win32.
Lazarus can,must and is not 100% cross plattform.

best regards
Christian

Speaking of that specific WM_COPYDATA patch we're talking about: That patch only influences the Win32-part of the LCL and not the carbon/gtk/qt-part.

What I don't understand is, why the LCL eats up messages at all - IMHO it should handle the messages it knows and leave all others untouched.

regards
Lukas

Please, can you provide an complete Example ?
Ill get silly exceptions every time when i try the stuff in C it works.

best reagrds
Christian

Christian U. wrote

Please, can you provide an complete Example ?

I don't have enougth free time for that. Maybe we could do the inverse? You create a complete example and posts here and we try to find out what you did wrong.

I havend declared the new windowproc as stdcall. Works now. I will see what i can do to make an usefiull example (i think it will be an winamp interface) that we can put to the lazarus examples.

best regards
Christian