Drag & Drop vom Explorer auf unterschiedliche Steuerelemente

[himitsu]

Wer sagt, dass die Anwendung beendet wird, nur weil "eine" Form geschlossen/freigegeben wird?

Nee, es wäre nicht nötig, denn wenn das Handle (HWND) gelöscht wird, dann ist auch das daran aktivierte Drag&Drop mit weg.
Aber wer verbietet es dir, dennoch brav aufzuräumen? (siehe meine Signatur und RAM gibt man doch auch ordentlich frei, obwohl Windows das beim Programmende ebenfalls macht)

Nein, sowas kommt nicht (nur) ins FormCreate oder Create rein, sondern in CreateWnd, wenn es direkt an der Form hängt. Bei Subcontrols isses eventuell bissl schwerer.
Ansonsten darf man auch noch mit CM_RECREATEWND und Dergleichen rumkämpfen, denn werden die internen Controls freigegeben und später wieder neu erstellt, dann ist dieses auch weg.
Und sowas passiert gern, wenn man z.B. nach dem DragAcceptFiles(True) an TopMost und am Fensterrahmen rumspielt, wobei wofür Fenster neu generiert wird,
oder wenn man das Fenster minimiert oder ausblendet (Hide), denn was man nicht sieht, muß nicht unbedingt sinnlos Speicher/Handles belegen, weswegen man es dann doch auch freigeben könnte.

[Jim Carrey]

Zitat von himitsu:

Nein, sowas kommt nicht ins FormCreate oder Create rein, sondern in CreateWnd, wenn es direkt an der Form hängt.

Mh?

Zitat von himitsu:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject); // <==
begin
  DragAcceptFiles(Edit1.Handle, True);
  DragAcceptFiles(Edit2.Handle, True);
  Application.OnMessage := AppMessage;
end;

[himitsu]

Ich hab ihn nochmal bissl ausgeschmückt, meinen Text.

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  DragAcceptFiles(Edit1.Handle, True);
  DragAcceptFiles(Edit2.Handle, True);
  Application.OnMessage := AppMessage;
  PopupMode := pmAuto; //BorderIcons := [biSystemMenu];
end;

Und jetzt sag mir, ob deine Edits immernoch Drag&Drop akzeptieren?
[edit] doch nicht BorderIcons ... da wird es nur bei MDI-Childs ausgelöst , aber auch durch anderen Aktionen wird TWinControl.RecreateWnd ausgelöst.



Ach ja, noch was gaaaaaaanz Wichtiges .. Niemals Application.OnMessage verwenden, sondern TApplicationEvents.OnMessage ,
denn wenn man das hier auf zwei Forms so macht, dann wird es nur bei einer Form funktionieren, da man das Application.OnMessage der ersten Form überschreibt.

[Jim Carrey]

Zitat:

Ach ja, noch was gaaaaaaanz Wichtiges ..

Und wenn ich Application.OnMessage nur ein einziges Mal verwende, ist das dann OK so?

Zitat:

Und jetzt sag mir, ob deine Edits immernoch Drag&Drop akzeptieren?

Muss ich gleich mal austesten

[himitsu]

Joar, ist es, aber in 10 Monaten hast du es vergessen und willst es nochmal für was Anderes benutzen.
Und ich wette du würdest Application.OnMessage nicht auf Assigned prüfen, vor der neuen Zuweisung.

[dummzeuch]

Vielleicht auch eine Moeglichkeit:

Delphi-Quellcode:

///<summary>
/// Enables dropping of files (folders) from explorer to the given WinControl
/// @param WinCtrl is a TWinControl for which dropping should be enabled
/// @param Callback is a TOnFilesDropped event that is called when files are dropped on the control.
/// @returns the TDropFilesActivator instance created.
///          NOTE: You do not need to free this object! It will automatically be freed when the
///                TWinControl is destroyed. </summary>
function TWinControl_ActivateDropFiles(_WinCtrl: TWinControl; _Callback: TOnFilesDropped): TObject;

Fuer jedes Control wird exact ein Aufruf dieser Funktion benoetigt, und natuerlich ein Callback, der aufgerufen werden soll, wenn der User eine Datei auf das Control dropt. Der Rest passiert automatisch.

https://sourceforge.net/p/dzlib/code...Utils.pas#l936