Eigene Titelleiste

[MicMic]

Ich hatte mir mal was abgespeichert. Hab mal eine ZIP Datei daraus gemacht.
Eigene Titelleiste ist ja leicht aber bei dieser Version geht dieses Andocken an den Rändern (Win10). Also wenn man das Fenster nach oben an den Rand verschiebt, dann bekommt man erst mal einen optischen Rahmen (zur Info, Fenster füllt den Monitor aus). Lässt man los, dann wird das Fenster maximiert. Verschiebt man das Fenster z.B. nach links, gibt's wiederum einen anderen optischen Rahmen (Fenster wird mit anderen geteilt). Lässt man los, kann man anschließend ein anderes Programm auswählen, dass die anderen 50% des Monitors ausfüllt. Kennt ihr sicherlich. Diese Windows Funktion hat auch einen Namen, nur fällt es mir gerade nicht ein.

Es gibt jedoch ein kleines Problem. Liegt irgendwie am "Border" von einer Form. Im Projekt habe ich dazu ein Panel ganz unten hinzugefügt. Mit einem rechtsbündigen Text. Startet man das Programm mit den aktuellen Fenster Einstellungen (also nicht maximiert), stimmt hier der Border-Abstand. Macht man es dann zu einem maximierten Fenster, dann gibt's da mit der Borderbreite wohl ein Problem. Deswegen der Text im Panel ganz rechts, damit man es sieht.

Ein Fix wäre wohl, die Rahmendicke für Fenster abzufragen und darauf zu reagieren. Vielleicht hat jemand eine andere Idee.

So eine eigene Titelleiste mit diesem MS-zum-Rand-verschiebe-Funktion (wie die auch immer sich nennt) wäre schon klasse. So könnte man eigene Designs machen, ohne diese Delphi-Design-Dingens zu benutzen. Jedenfalls ist diese "MS-zum-Rand-verschiebe-Funktion" schon Goldwert. Das nutzen Anwender und mit dieser Version hier (ZIP-Datei) geht das auch. Nur halt das Problem mit dem Border besteht.

Vielleicht kann ja mal jemand drüber schauen. Könnte mir vorstellen, dass andere so etwas auch gebrauchen könnten.

Euch einen schönen kommenden Sonntag und vergesst nicht Mama. Aber nicht nur morgen, auch sonst. :)

[Medium]

Werde Mamma nie vergessen, aber seit (ziemlich exakt) Anfang 2017 sind ihr (bzw. ihrer Asche) Blumen und Pralinen wohl egal. Ähnliches gilt für Titelleisten in "custom design" - das ist ehrlich gesagt Unfug. Ich mag Konfigurierbarkeit eines UIs an sich sehr gern, aber insbesondere so fundamentale Dinge wie Titelleisten gehören für mich zu 100% in die Herrschaft des OS. Ich kann gut mit individuellen Programmen umgehen, und verstehe dass hier je nach Einsatzzweck und/oder Standard der jeweiligen Industrie bzw. Kunden viel Spielraum nötig ist. Aber Titelleisten und Standardverhalten von Fenstern ist (in 99,9% der Fälle) etwas, wo ich nichts anderes als OS-Standard haben will. Wer auch immer meint damit Unfug treiben zu müssen, landet bei mir schneller im Uninstaller als ich potenziell coole Funktionalität entdecken könnte.
Oder in Kürze: Ohne sehr trifftigen Grund ein absolutes No-Go für mich.


Davon ab ist die Beschreibung recht vage. Ich musste 3x lesen um zu verstehen um was es hier geht. Und dennoch bin ich unsicher, ob du hier eine Frage zu einem Problem stellst, oder einen Code zur ungeprüften weiteren (fragwürdigen) Verwendung bereitstellen willst.

[venice2]

Zitat:

Oder in Kürze: Ohne sehr trifftigen Grund ein absolutes No-Go für mich.

Dann wird dir unter umständen wirklich einiges entgehen.
Zudem ist das absolut nicht zeitgemäß zu sagen

Zitat:

Titelleisten gehören für mich zu 100% in die Herrschaft des OS

Mit verlaub aber was wurde denn bei den unterschiedlichen OS versionen denn großariges verbessert?
Nichts! Richtig.
Und deshalb ist das einfach nicht zeitgemäß so eine Aussage zu treffen.
Was ist da schlimm dran die Titelleiste einfach zu vernachlässigen.

Aber natürlich liegt es in deinem ermessen was du für gut oder schlecht hälst.
Im aktuellen OS dürfte das egal sein ist eh -> Scheis... wird sich wohl auch nicht mehr ändern.

[blawen]

Zitat:

Zitat von venice2 (Beitrag 1464169)

Zitat:

Oder in Kürze: Ohne sehr trifftigen Grund ein absolutes No-Go für mich.

Dann wird dir unter umständen wirklich einiges entgehen.
Zudem ist das absolut nicht zeitgemäß zu sagen

Ich habe das Demo ausgeführt und für mich hat es sich "ungewohnt/uncool" angefühlt.

Zitat:

Zitat:

Titelleisten gehören für mich zu 100% in die Herrschaft des OS

Mit verlaub aber was wurde denn bei den unterschiedlichen OS versionen denn großariges verbessert?
...
Im aktuellen OS dürfte das egal sein ist eh -> Scheis... wird sich wohl auch nicht mehr ändern.

Was kann/soll sich vom Grundsatz her in einer Titelleiste grundsätzlich derart verbessern, dass es jeder haben muss? Ob jetzt oben Rechts nun ein X oder Y sitzt, spielt mir keine Rolle.
Hauptsache, ich kann das Programm im Grundsatz gleich bedienen, wie alles andere auch.

@MicMic
Deine Beschreibung ginge auch einfacher.
Grundsätzlich besteht das Problem immer, wenn es maximiert ist. Dies geht übrigens auch mit der Tastenkombination "Windows" + "Pfeil nach oben".
Das Problem wird vermutlich daher kommen, weil bei der Maximierung kein Rahmen dargestellt wird und bei Dir die Anzahl Pixel "fälschlicherweise" abgezogen werden.

[Medium]

Zitat:

Zitat von venice2 (Beitrag 1464169)

Mit verlaub aber was wurde denn bei den unterschiedlichen OS versionen denn großariges verbessert?
Nichts! Richtig.

Das hängt wohl vom jeweilligen OS ab, nicht? Die Kernaussage ist: Ein einheitlicher Standard ist 100x wertvoller als was auch immer man sich für sein Programm vorstellt. Der Durchschnittsnutzer will eine Durchschnittsbedienung, und die nötige Einheitlichkeit diktiert das jeweilige Ökosystem (aka Betriebssystem). Besser oder schlechter spielen hier kaum eine Rolle.

Zitat:

zeitgemäß

Was wäre denn deiner Meinung nach "zeitgemäß"? Jeder kocht sein eigenes Süppchen? Wie in den 70ern?

Zitat:

Im aktuellen OS dürfte das egal sein ist eh -> Scheis... wird sich wohl auch nicht mehr ändern.

Unter der Annahme, dass du auf Windows 10 anspielst: Wir hatten bisher selten ein so gefälliges übergeordnetes System, dass in Sachen Multi-Monitor, Multi-Desktop und der Begrenzung derer wo nötig, so freizügig war. Ich kann mich nicht daran erinnern, wo ich (als >15-jähriger Nutzer 2-3 Monitore, teils in 90° gedreht und/oder über Bereiche eines physikalischen Bildschirms verteilt) größere Probleme seit frühestens Windows 7 hatte. Wo genau ist dein Problem?

[Daniel]

Stop - die Diskussion über die persönlichen Befindlichkeiten kann man kürzer fassen. Der Hinweis als solcher ist ja durchaus berechtigt - Änderungen an zentralen UI-Elementen wie der Titelleiste müssen mit Bedacht vorgenommen werden, sonst geht der Schuss nach hinten los.

Dennoch ist das Vorhaben keinesfalls ungewöhnlich - Chrome, FireFox, selbst MS Office nutzen die Titelleiste für eigene Zwecke und die Mehrheit der Nutzer scheint durchaus einen Nutzen daraus zu ziehen. Windows selbst bietet über die Funktionen des DWM genug Werkzeuge, um diese sog. NonClient-Area des Fensters zu kontrollieren.

[MicMic]

Der MS Edge hat auch ne andere Titelleiste mit ein paar Extras. Also ein Standard (sogar von MS selbst) gibt es nicht mehr. Ein eigenes Design bedeutet ja nicht, man macht alles anders. Aber auch wenn es doch ein wenig speziell wird (Farben bei Adobe) kommt das gut an.

Jedenfalls macht so ein Panel (align=alBottom und alignment=taRightJustify) mit einem normalen bsNone und wsMaximized alles richtig. Aber im Beispielprojekt halt nicht. Dafür geht aber diese "MS-zum-Rand-verschiebe-Funktion". Die nennt sich übrigens "Snap In" :)

Ich mach übrigens mein Programm, was das Design angeht, recht offen für Änderungen. Der Anwender selbst kann dann entscheiden, ob's im Windows-Standard-Stil angezeigt wird oder er es doch sehr Benutzerdefiniert haben möchte.

Deshalb sind "Eigene Titelleisten, runde Buttons, dies und das" nicht gleich eine Fehlprogrammierung. Es kommt halt immer darauf an.

Also die Breite des Fensterrahmens kann man sicherlich durch die API ermitteln. So könnte man es wohl irgendwie fixen, dass es wieder stimmt. Jedoch nehme ich solche Werte (auch andere Daten wie Farbwerte) aus der API nicht mehr gerne. Einiges ist wohl auch nur noch vorhanden, wegen der Abwärtskompatibilität. Also man muss heute schon überlegen, was man so aus der API noch nimmt. Bevor ich mich hier probiere, wollte ich nur mal dieses Beispielprojekt hochladen und mal fragen, ob jemand eine Idee dazu hat.

Ich find's halt toll, diese einfache Möglichkeit, sozusagen eine Form zu haben, die ganz leer ist (alle Möglichkeiten offen zum Design) aber mit dieser "Snap In" Funktion, die dabei erhalten bleibt. Die "Snap In" Funktion finde ich eine tolle Sache und sicherlich nutzen das viele Anwender in der heutigen Zeit mit größeren und oder mehreren Monitoren. Also die Funktion sollte dann natürlich erhalten bleiben.

[MicMic]

Ich habe jetzt was gemacht.
Hier die neue Unit1:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.ExtCtrls;

type
  TForm1 = class(TForm)
    Panel1: TPanel;
    Panel2: TPanel;
    procedure FormCreate(Sender: TObject);
    procedure Panel1MouseMove(Sender: TObject; Shift: TShiftState; X,
      Y: Integer);
    procedure FormResize(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  protected
    procedure WmNCCalcSize(var Msg: TWMNCCalcSize); message WM_NCCALCSIZE;
  end;

var
  Form1: TForm1;
  r : TRect;
  rr : integer;

implementation


{$R *.dfm}


procedure TForm1.FormResize(Sender: TObject);
begin
 if WindowState = wsMaximized then
 begin
  padding.Right := rr;
  padding.Bottom := rr;
 end else
 begin
  padding.Right := 0;
  padding.Bottom := 0;
 end;
end;

procedure TForm1.Panel1MouseMove(Sender: TObject; Shift: TShiftState; X,
  Y: Integer);
const
  sc_DragMove = $f012;
begin
  ReleaseCapture;
  Perform(wm_SysCommand, sc_DragMove, 0);

end;

procedure TForm1.WmNCCalcSize(var Msg: TWMNCCalcSize);
begin
  Msg.Result := 0;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  SetWindowLong(Handle
               ,GWL_STYLE
               ,WS_CLIPCHILDREN or WS_OVERLAPPEDWINDOW
               );
  AdjustWindowRectEx(R, GetWindowLong(Handle, GWL_STYLE), False, GetWindowLong(Handle, GWL_EXSTYLE));
  rr := trunc(r.width/2); // <- trunc/ceil/Floor/round???
end;

end.

Also in "r.width" habe ich 26. Das sind dann wohl 13 Pixel Breite für den Fensterrahmen? Wenn dieser Wert aus einem Breitenwert (dann x 2) berechnet wird, dann geht die Zahl ja immer auf. Also kann man es gut teilen. Bin mir aber nicht sicher, ob das auch so ist. Nicht das 27 mal als Ergebnis zurück geliefert wird.

Das Ergebnis beim maximieren schaut gut aus (nutze den Wert für's padding). Glaubt ihr damit könnte man arbeiten? Das sind immer so Sachen, die ich aber nicht gerne mache... am Ende gibt's evtl. beim Anwender unterschiede.

[Daniel]

Naja, Du kannst das selbst testen, indem Du Deinem Windows mal verschiedene Anzeige-Einstellungen aufzwängst - inkl. verschiedener DPI-Skalierungen.

Wenn Dein Code am Ende das tut, was Du Dir vorstellst (und ich bin mir noch nicht sicher, was genau das sein soll), wäre es der beste Zeitpunkt, um die globalen Variable loszuwerden. Es sei denn, der hier gezeigte Code ist nur ein Auszug zur Demonstration. In dem Fall wäre das mit den globalen Variablen natürlich mehr oder weniger egal.

[MicMic]

Zitat:

Zitat von Daniel (Beitrag 1464185)

Naja, Du kannst das selbst testen, indem Du Deinem Windows mal verschiedene Anzeige-Einstellungen aufzwängst - inkl. verschiedener DPI-Skalierungen.

Wenn Dein Code am Ende das tut, was Du Dir vorstellst (und ich bin mir noch nicht sicher, was genau das sein soll), wäre es der beste Zeitpunkt, um die globalen Variable loszuwerden. Es sei denn, der hier gezeigte Code ist nur ein Auszug zur Demonstration. In dem Fall wäre das mit den globalen Variablen natürlich mehr oder weniger egal.

Naja, mein Programm wird auch nicht Rosa, wie im Beispiel :) Schon klar.
Das war jetzt mein erster Versuch, nur kurz getestet und wollt es schnell posten.