Borderstyle bsNone deaktiviert Global-Hotkey?

[Coder]

Hi, ( Delphi 5 - ist aber aktuell sicher immernoch so)

ich hab mal eine Frage: Wenn ich bei einer Form BorderStyle auf z.B. bsNone setze,
funktioniert kein Global-Hotkey mehr.
Auch wenn ich auf bsSingle oder Sizable setze.
Muß das so?

Hat jemand eine Erklärung - und weiß, wie man das eventuell verhindern kann?

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls;

type
  TForm1 = class(TForm)
    Edit1: TEdit;
    Button1: TButton;
    Button2: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private-Deklarationen }
    id1, id2, id3, id4: Integer;
    procedure WMHotKey(var Msg: TWMHotKey); message WM_HOTKEY;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

// Trap Hotkey Messages
procedure TForm1.WMHotKey(var Msg: TWMHotKey);
begin
  if Msg.HotKey = id2 then
  Edit1.Text := 'Taste gedrückt';
//    ShowMessage('Ctrl + Shift  + A  pressed !');
end;

procedure TForm1.FormCreate(Sender: TObject);
 // Different Constants from Windows.pas
const
  MOD_ALT = 1;
  MOD_CONTROL = 2;
  MOD_SHIFT = 4;
  MOD_WIN = 8;
  VK_A = $41;
begin

  id2 := GlobalAddAtom('Hotkey2');
  RegisterHotKey(Handle, id2, MOD_SHIFT + MOD_CONTROL , VK_A);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  UnRegisterHotKey(Handle, id2);
  GlobalDeleteAtom(id2);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  //////////////////////////////////////
  BorderStyle := bsSingle;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  Edit1.Clear;
  BorderStyle := bsnone;
end;

end.

Hat jemand eine Erklärung - und weiß, wie man das eventuell verhindern kann?

[jaenicke]

Zitat:

Zitat von Coder (Beitrag 1537176)

Hi, ( Delphi 5 - ist aber aktuell sicher immernoch so)

Das funktioniert ab mindestens Delphi 2007 (2005 und 2006 nicht getestet) problemlos. Bei Delphi 7 und früher lassen sich die Probleme nachstellen.

Es ist nun einmal so, dass es damals diverse Bugs gab (Randberechnung bei Fenstern, Alt-Tasten-Bug beim Zeichnen, Taskleistenvorschau, ...), die erst mit neueren Delphiversionen behoben wurden. Das lag auch daran, dass vieles erst mit neueren Windowsversionen auftrat. Deshalb sollte man auch eine Entwicklungsumgebung verwenden, die für die jeweilige Zielplattform gedacht ist.

In diesem Fall vermute ich, dass es am Handling des versteckten Application-Fensters liegt. Das wurde nämlich geändert, wonach dann auch die Taskleistenvorschau funktionierte. Ich bezweifle, dass du das ohne Nebenwirkungen einfach ändern kannst.

Wie wäre es mit einem Tastaturhook? Der funktioniert unabhängig davon immer.

[himitsu]

Das Umschalten des FormStyle zerstört das interne HWND (Window-Handle) und generiert ein vollkommen neues Form.
Somit ist auch ALLES weg, was im OnCreate registriert wurde, und was keine Kopie im Delphi-Objekt besitzt, also nicht automatisch wiederhergestellt wird.
siehe DestroyHandle im TCustomForm.SetFormStyle

Das Selbe gilt auch für alle untergeordneten HWND (Panels, Edits, Buttons usw.)

Außerdem kann sowas passieren, wenn der PC oder der Monitor/Grafikkarte in den Standby wechselt oder wenn man sich in eine Terminal-Sitzung einloggt oder von ihr trennt, sich per RDP mit dem Rechner verbindet und in tausenden anderen Situationen.

mögliche Lösungen:

Delphi-Quellcode:

procedure CreateWindowHandle(const Params: TCreateParams); override;
procedure CreateWnd; override;
...

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1537180)

Das Umschalten des FormStyle zerstört das interne HWND (Window-Handle) und generiert ein vollkommen neues Form.

In den alten Quelltext hatte ich nicht reingeschaut. Das erklärt dann natürlich, weshalb es dort nicht geht. Das machen aktuelle Delphiversionen nicht mehr. Die schalten wirklich nur den Style um.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1537181)

Die schalten wirklich nur den Style um.

Nein, Doch.

Delphi-Quellcode:

procedure TScrollBox.SetBorderStyle(Value: TBorderStyle);
begin
  if Value <> FBorderStyle then
  begin
    FBorderStyle := Value;
    RecreateWnd;
  end;
end;

Teilweise wird es aber an anderen Stellen inzwischen selektiver gehandhabt.
Und wie gesagt, es gibt auch Sitiationen, wo sowas ohne eigenes Eingreifen ausgelöst wird.

z.B. könnten theoretisch die Handles auch freigegeben werden, wenn das Fenster ausgeblendet oder minimiert wird, um Systemressourcen zu sparen.

[Coder]

danke.

mh, ja, vielleicht sollte ich doch mal 2300? € ausgeben (oder was kostet Delphi jetzt?) :D
(oder Community Edition, oder gleich Lazarus)
(ach, 1430, oder ... 5600 .. Oh - naja, brauch's ja nicht kommerziell)

mh, ja, sorry, ich find Delphi 5 einfach schnell, geladen und compiliert.

Vieles mach ich heut auch in Python/tkinter.
Aber für manches/ alle Fälle hab ich unter Win10 halt noch Delphi5 installiert, bei alten Programmen.


Andere Frage (dürfte aber vielleicht ähnliche Ursache haben):

Wenn ich nun OnMouseUp() in der Form mache, fängt der nur den (Mouse)Button = mbright ab.
mbleft ignoiert der.

Der Linke funktioniert nur im Form.OnMouseDown(), komischerweise..?
Oder ist das so gewollt?
Gerad getestet - bei rechter Maustaste geht er auch nur in Form.MouseUp() rein - (wtf)??

is mir vorher nie so aufgefallen/ genutzt

[jaenicke]

Zitat:

Zitat von Coder (Beitrag 1537186)

Wenn ich nun OnMouseUp() in der Form mache, fängt der nur den (Mouse)Button = mbright ab.
mbleft ignoiert der.

Das hat nichts mit der Delphiversion zu tun. Das funktionierte auch bei Delphi 5 und früher korrekt.

Da ist wohl eher dein Testquelltext nicht in Ordnung. Ein beliebter Fehler ist z.B., solche Events mit Dialogausgaben oder Haltepunkten zu debuggen. Hier bietet sich die Ausgabe auf dem Formular oder per OutputDebugString an.

[Coder]

öhm,
huch, jo.
hab weiter oben auch

Delphi-Quellcode:

procedure TForm1.FormMouseMove(...) ...
  ReleaseCapture; // Image verschieben
  Perform(WM_SYSCOMMAND, $F012, 0);
end;

damit ich die Form bei links-Klick simultan rumschieben kann,
da wird der wohl verschluckt.

jedenfalls geht der Links-Klick danach wohl nicht mehr in den MouseUp()

[dummzeuch]

Zitat:

Zitat von Coder (Beitrag 1537186)

mh, ja, vielleicht sollte ich doch mal 2300? € ausgeben (oder was kostet Delphi jetzt?) :D
(oder Community Edition, oder gleich Lazarus)
(ach, 1430, oder ... 5600 .. Oh - naja, brauch's ja nicht kommerziell)

mh, ja, sorry, ich find Delphi 5 einfach schnell, geladen und compiliert.

Vieles mach ich heut auch in Python/tkinter.
Aber für manches/ alle Fälle hab ich unter Win10 halt noch Delphi5 installiert, bei alten Programmen.

Wenn Du kein Geld ausgeben willst, nimm Lazarus. Delphi 5 ist inzwischen wirklich nicht mehr zu empfehlen. Nachteil: Alte Projekte müssen konvertiert werden. Keine Ahnung, wie gut inzwischen der Import von Lazarus ist.

[himitsu]

Jupp, OnMouseUp geht natürlich immer nur an das Control, welches den Capture besitzt.

Drum kann man z.B. auf einen Button (oder sonstwo) Linksklicken, dann die Maus vom Button ziehen und Loslasen ... das Loslassen landet beim Button und nicht da, wo die Maus jetzt ist.
Nur das OnClick wird in diesem Fall nicht mehr ausgelöst, wenn der Maus nicht mehr über dem Button liegt.
Ebenso beim Drag&Drop der VCL, wo das Loslassen bei der Source landet, nicht beim Dest.