Hello Remy,
thank you a lot for your very detailed response!
As i'm not as far so indepth those usbclassing matters as you are, let me try to summarize my understanding of the proceeding of the component:
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:
constructor TMyCustomListView.Create(AOwner: TComponent);
var WinCtl: TWinControl;
begin
...
WinCtl := TWinControl( AOwner );
FWndHandle := WinCtl.Handle;
DragAcceptFiles( FWndHandle, True );
// DragAcceptFiles( Self.Handle, True ); // --> exception
As result of that, the winproc of the owner (eg. a panel) will receive the drop message, but not the winproc of the custom listview
TMyCustomListView = class(TCustomListView)
protected
procedure WndProc( var Message: TMessage ); override;
...
procedure TMyCustomListView.WndProc(var Message: TMessage);
begin
with Message do begin
Case Msg Of
WM_CREATE : ShowMessage('WndProc: received WM_CREATE'); // --> will be called
WM_DROPFILES : ShowMessage('WndProc: received WM_DROPFILES'); // --> will NOT be triggered by an outside drop
Due to that - so my understanding- the component introduced the subclassing bound to the owner.
In fact the drop message could be received now fine. And the processing of listview messages is not negatively touched either.
At the end of the process, the window proc had been restored to the original one.
But so - as you directly noticed :-) , the reference is not pointing to the custom listview proc, but to the proc of the owner.
Maybe, that's what i'm thinking now, the DragAcceptFiles could have a listview-xyz as parameter, so that this whole detour is not necessary perhaps. And proabbly it had been more appropriate to let the two message loops distinct rather than to do tht subclassing.
I'm myself not emphasized about this construct, but that had been the context i had when i found that MakeObjectInstance threw an error, which leaded to my OP.
Apparently .... meanwhile it's overdue to have a small test project for that.
i created one, which is minimalistic shrinked to the topic in speech.
- It does not contain more than to open a message box if the drop message is passed to an (empty) custom listview.
- Accompanying with the suffix "_0" is the same --> but without the subclassing stuff .... only with a simple listview winproc.
With no messagebox appearing here of course, because the Drop is registered for the owner.
Both projects are Delphi (7) of course.
As for Lazarus a possible solutinn had been just discussed above. I'm happy with that. The more, as i meanwhile did read somewhere, probably Embarcadero did mark the MakeObjectInstance as a deprecated procedure.