From an other thread in the forum i did read that's implemented with Win32, but for Win64 it's only a stub that throws an exception. And in fact in source\rtl\win64\classes.pp it does read:Correct, seems it was never really implemented for Win64 (https://github.com/graemeg/freepascal/commit/d547ade9b4ad6204a7018fa6faa7aa1c103ce1ed). I believe a similar approach as for Win32 (https://github.com/graemeg/freepascal/blob/2d3976f39531ea8fe167600014bd3069f333b52d/rtl/win32/classes.pp#L111) should also work for Win64.
function MakeObjectInstance(Method: TWndMethod): Pointer; begin runerror(211); MakeObjectInstance:=nil; end;
As from other threads within the forum it did not really got the clue: what might be the recommended technique to replace the MakeObjectInstance now?Which thread do you mean?
As from other threads within the forum it did not really got the clue: what might be the recommended technique to replace the MakeObjectInstance now?MakeObjectInstance is a thread-safe version of the WndMethod wrapper without creating a window. If you are not confused by a hidden window for the same purpose, use LCLIntf.AllocateHWnd.
Directyl applying the Win32 coding won't work (that's just what i had expected),You need to adapt the asm to follow the x64 calling convention and also to use the 64-bit registers (otherwise the register values are pointing to wrong addresses if you call them). Thus simply copying the Win32 asm won't work.
because a lot of other stuff (structures and callbacks) are needed as well as some assembler code
which fails to compile (at: call %ecx and at: popl %eax). So that's probably not the right way to go..
It's simply for to receive WM_DROPFILES message passed from outside of the app. That one wouldn't be catched by the default WndPro message loopc.
Yes: i just got aware (by another thread from ASerge) that MSDN mentions that WM_DROPFILES should be avoided for that if possible https://docs.microsoft.com/en-us/windows/win32/shell/datascenarios
Why subclassing the Owner's window? Well, that's i found in the code, and i interpreted it's needed because that one would receive the message (it did work in fact using MakeObjectInstance)
The custom listview has an own window, but the default WndProc never did receive the WM_DROPFILES nessage (i retested that in den Delphi 7 version)
Meanwhile i had have a couple of tests (unfortunately i had not much time left today), and those are, in short, the results:
WinCtl := TWinControl( Owner ); FWndHandle := WinCtl.Handle; FMessageSubClassedHandle := AllocateHWnd(WndProcSubclassed); // FMessageSubClassedHandle: HWnd FMessageSubClassedProc := Pointer( GetWindowLong( FMessageSubClassedHandle, GWL_WNDPROC )); // FMessageSubClassedProc : Pointer
// Attempt 1: ----> would lead to exception. Maybe due to wrong data types. Didn't pursue that further yet //SetWindowLong( FWndHandle, GWL_WNDPROC, Longint( FMessageSubClassedProc ));// For_subclassed
// Attempt 2a: -----> receives only WM_ACTIVATEAPP (or some Message.Msg 799 / unknown) //SetWindowSubclass(FMessageSubClassedHandle, FMessageSubClassedProc, 1, DWORD_PTR(Self) );
// Attempt 2b: ----> compöiler error: Variable identifier expected //SetWindowSubclass(FWndHandle, @WndProcSubclassed, 1, DWORD_PTR(Self) );
// Attempt 2c: ----> result same as 2a (mostly WM_ACTIVATEAPP) //SetWindowSubclass(FWndHandle, FMessageSubClassedProc, 1, DWORD_PTR(Self) ); // Attempt 2d: ----> result same as 2a (mostly WM_ACTIVATEAPP) //SetWindowSubclass(Application.Handle, FMessageSubClassedProc, 1, DWORD_PTR(Self) );
So meanwhile i suspect that the LCL maybe does not pass the message to the custom controls.
In fact, receiving of drops is activated via DragAcceptFiles here.
As parameter, the handle of the owner (eg. a panel) has been spent, as this is a wincontrol, and the the DragAcceptFiles won't accept the handle of a custom listview as parameter (exception)
For that reason - this is my assumption - it's done somehow/roughly like such:
With no messagebox appearing here of course, because the Drop is registered for the owner.
Both projects are Delphi (7) of course.
The more, as i meanwhile did read somewhere, probably Embarcadero did mark the MakeObjectInstance as a deprecated procedure.
.... after a couple of minutes i realized. hey, that's normal, it (the call of DragAcceptFiles) is done within the constructor = the handle is not yet accomplished!
For the custom listview, i found the equivalent OnDropFiles property.
I would move DragAcceptFiles() into an overridden CreateWnd() instead
...
Or, override CreateParams() to enable WS_EX_ACCEPTFILES, and not use DragAcceptFiles() at all
f you are trying to write a component that works in both Delphi and FreePascal. ..