Klar geht das
Ich habe doch selbst auf ähnlichen Code verlinkt, und erklärt warum es Probleme damit geben kann und das unsauber ist. Die Kommentare in dem Link sagen ähnliches.
Zitat:
Zitat:
In WM_NCLBUTTONDOWN und Co. könnte man dann die Nachricht nicht an DefWindowProc() weiterleiten um somit den Windows-eigenen Drag-Drop-Prozess zu verhindern. Ob das auch die Option abfängt, über die Tastatur ein Fenster zu verschieben, wäre zu testen.
Sorry das ist schlichtweg falsch.
Vielleicht missverstanden
(siehe triviales Beispiel unten). Wenn man die entsprechenden Window-Messages abfängt, wird natürlich kein Drag&Drop eingeleitet, da Windows nie mitbekommt dass man die Maustaste auf der Titelleiste gedrückt hält.
Der Sinn dahinter ist, dass man dann selber ein eigenes Drag&Drop implementieren kann, ohne sich mit der Windows-eigenen Implementierung zu verheddern.
Ein Test zeigt auch dass Alt+Leertaste|Verschieben und Verwenden der Pfeiltasten zum Verschieben noch funktioniert.
Also das was ich gesagt habe...
Beispiel, einfach eine neue
VCL-Anwendung erstellen, dann den Quelltext von Unit1.pas mit folgendem ersetzen:
Delphi-Quellcode:
unit Unit1;
interface
uses
Winapi.Windows,
Winapi.Messages, System.SysUtils, System.Variants, System.Classes,
Vcl.Graphics,
Vcl.Controls,
Vcl.Forms,
Vcl.Dialogs;
type
TForm1 =
class(TForm)
private
procedure WMNCLButtonDown(
var Message: TWMNCLButtonDown);
message WM_NCLBUTTONDOWN;
public
{ Public-Deklarationen }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.WMNCLButtonDown(
var Message: TWMNCLButtonDown);
begin
Message.Result := 1;
end;
end.
Zitat:
Das hat nichts mit einem Hack zu tun.. ich verwende das schon seit Jahren und hatte keine Probleme.
Man muss es nur richtig machen.
Wie setzt man eine systemweite Einstellung zurück wenn die eigene Anwendung abstürzt? Und es braucht auch nur eine Änderung in der Abfrage dieses systemweiten Flags passieren (innherhalb vom Windowscode/neue Versionen), so dass dann eben nicht mehr erst beim Draggen abgefragt wird und somit Windows deine Änderungen nicht mehr mitbekommt.
Ähnliches ist schon mal passiert was Toplevel-Fenster und die Behandlung von Besitzern/Ownern anging, und prompt waren eine Menge Hacks die sich auf undokumentierte Systeminterna verlassen haben plötzlich buggy. Windows hat sich darauf verlassen dass die Owner richtig angegeben wurden, und man nicht mehrere TopLevel-Fenster hat.
Die bekannten plötzlich verstecken Fenster bei Delphianwendungen die dann auch nicht mehr aktiviert werden können (weil das falsch platzierte Fenster modal war) hatten eben solch einen Grund: verlassen auf Interna, die so nicht dokumentiert waren und sich ändern können. Das fing glaube ich auch erst bei XP an ein Problem zu werden, vorher ging alles gut.
Dann kann es noch Probleme geben wenn der Fokus sich ändert oder z.B. eine andere Anwendung in den Vordergrund kommt, oder Mousecapture verloren geht (gibt es auch viele Gründe warum das regulär passieren kann), usw.
Der Grundsätzlich Denkfehler ist hier: Systemweites Flag wird gesetzt, aber es soll nur lokale Auswirkungen haben. Kann nicht gut gehen, da Windows ein nebenläufiges System ist und daher während das SPI_GETDRAGFULLWINDOWS-Flag "falsch" ist, auch andere Anwendungen davon betroffen sein können.
Das mag häufig/bei üblichen Szenarien funktionieren, aber wie bei race conditions im Allgemeinen hin und wieder unerklärliche Bugs hervorrufen.