Skalierbare Fensterinhalte

[stalkingwolf]

Wir haben und erlaubt unsere Fenster an moderne Monitorgrö0en anzupassen.
D.h größere Schriften Segoe UI mindestens 10 und Fenstergrößen von 1400/1700 x 800/900 (teilweise auch FullHD). Kommt immer etwa auf das Programm an.

Das dies ein Echo geben würde war uns bewusst. Wir hatten im Vorfeld auch in unserer Software Bildschirmgrößen und Anzahl ausgewertet. Kunden natürlich auch informiert, aber Emails ließt ja keiner

So nun kommen einige die arbeiten tatsächlich mit Notebooks mit 1366x768. Kurze Recherche sind das entweder 300€ Notebooks mit Billigpanel oder so Mikro 10" Notebooks. Kp wie man seinen Mitarbeitern das eine oder andere antun kann.

Nun die Frage. Hat sich schon jemand einmal mit skalierbaren Fensterinhalten beschäftigt?
Ich stelle mir das extrem kompliziert und aufwändig vor, wenn ich eine Maske mit 20 Label, Eingabefelder inkl Listen, Checkboxen, Radiogroups etc. auf der Form sitzen habe.
Diese alle in Abhängigkeit zu skalieren und neu zu positionieren.

Schon jemand einmal gemacht oder wie geht ihr mit solchen Sachen um? Immer am unteren Ende der Auflösungen zu bleiben hält einen auch in der Entwicklung/Darstellung doch stark zurück.
Wenn ich ein Fenster auf nur 1366x720 ( die haben ja auch die Taskleiste dauerhaft anzeigt ) optimiere, dann wirkt das bei einem Kunden mit Ultrawide oder 4k wie eine verlorene Briefmarke.

Gruß und schönes WE
Sven

Edit : Delph 11 VCL

[Sherlock]

Unter FMX sollte das alles ohne Dein zutun möglich sein, die richtigen Einstellungen vorausgesetzt. Uraltes Emba-Video dazu: https://www.youtube.com/watch?v=gyEUKNCwZvo

Sherlock

[stalkingwolf]

Wir arbeiten mit VCL.
Habe es oben einmal erweitert.

[Jasocul]

Bevor dort Zeit und Geld investiert wird:
- Wieviele Kunden sind betroffen?
- Wäre es tragisch, wenn die Kunden verloren gehen?

Ihr habt die Kunden rechtzeitig informiert. Wie ihr schon selbst festgestellt habt, ist die Bildschirmgröße eigentlich grundsätzlich nicht zumutbar.
Ich würde eine Kosten-Nutzen-Kalkulation machen, ob es sich überhaupt lohnt, diese Kunden zu berücksichtigen.
Vermutlich werden die Kunden gar nicht verloren gehen, aber sie werden sich natürlich beschweren. Wenn ihr damit leben könnt, würde ich keinen Finger krum machen, um die (vermutlich) sehr wenigen, betroffenen Kunden zufrieden zu stellen.

[stalkingwolf]

Es sind wirklich nur sehr wenige Kunden welche so kleine Auflösungen haben.
Dazu kommen noch einige welche gern 5 Programm gleichzeitig geöffnet haben möchten und sich weigern einen zweiten Bildschirm oder Widescreen einzusetzen.
Wir sagen immer das mit FullHD alles einwandfrei genutzt werden kann. Natürlich bezogen auf ein Programm und nicht 5. Aber jeder interpretierte dies anders

Dachte mir nur wenn es "relativ" einfach umzusetzen wäre, das man sich das ganze in ein paar Programmen einmal schauen könnte.
Das was FMX macht wäre ja z.b schon was. Aber will die Programm nun nicht von VCL auf FMX portieren.

[Uwe Raabe]

Es ist natürlich schwierig dafür pauschal Empfehlungen zu geben. Es hängt ja auch stark davon ab, was ihr abliefern wollt.

Einiges lässt sich schon mit Align, Anchors und Constraints regeln - dann werden die Controls eben je nach Monitor erstmal kleiner. Man kann mit TGridPanel, TFlowPanel und TRelativePanel schon recht komplexe dynamische Anpassungen realisieren. Auch die gute alte TScrollBox kann hilfreich sein. Wer dann einen zu kleinen Bildschirm hat, muss dabei halt etwas Komfort einbüßen. Als wirklich letzte Möglichkeit käme noch ein dynamischer PageControl-Ansatz in Frage (je nach Platz gibt es 0..n Tabs). Das lässt sich am besten umsetzen, wenn man die Controls in Frames gruppiert.

Es bleibt natürlich immer ein gewisser Aufwand und man muss vorab klären, ob man den betreiben will.

[anse]

DPI awareness empfehle ich, sodass die Controls mehr Pixel bekommen je höher die DPI-Einstellung des Benutzer unter Windows ist. Das stellt schon mal sicher dass die Controls nicht briefmarken-klein werden bei hohen Auflösungen. Siehe Projektoptionen > Anwendung > Manifest. Den Rest würde ich per Anchors und Scrollbars lösen, wenn noch nicht geschehen.

Wichtig ist dabei aber dass man beim Formular-Design schon an die kleinstmöglichen Bildschirme denkt, und nicht einfach den Platz verbraucht den der Entwickler auf seinem 34 Zoll-Bildschirm zur Verfügung hat.

Responsive Webseiten passen ja heutzutage bei kleinen (Smartphone-) Auflösungen sogar die Anordnung der Elemente an den Bildschirm an. Z.B. mit dem Bootstrap Grid System . Dabei wird ein div-Container in 12 Spalten eingeteilt, und der Entwickler definiert für Bildschirme von XS bis XL die jeweilige Spaltenanzahl eines Elements. Bei einem simplen "TLabel: TEdit" wäre das bei XS: "12, 12" (2 Zeilen) und bei XL eher "4, 8" (eine Zeile). Aber sowas wird in Delphi soweit ich weiß nirgends unterstützt.

[Uwe Raabe]

Zitat von anse:

Das stellt schon mal sicher dass die Controls nicht briefmarken-klein werden bei hohen Auflösungen.

Na ja, wenn man die App als DPI-unaware kennzeichnet, dann sorgt Windows schon für eine entsprechende Größenanpassung. Das kann dann halt manchmal etwas pixelig aussehen, aber briefmarken-klein dann auch wieder nicht. Blöd ist dann nur, wenn man Windows sagt "Ich kann DPI", aber das dann nicht (oder nicht vollständig) hinkriegt.

[QuickAndDirty]

Ich habe die DPI bezogene Skalierung damals von Hand gelöst...

Delphi-Quellcode:

var ScaleValue96Factor:Double;
Procedure InitScaleValue96factor;
begin
  ScaleValue96Factor := Screen.PixelsPerInch / 96;
end;

Function ScaleValue96(Value:integer):integer;
Begin
  Result := Round(ScaleValue96Factor * Value);
End;

Procedure ScaleControl(aControl:TControl; ScaleFonts:Boolean=false; NoWordWrap:Boolean=false);
var i,x:integer;
MetaRecord : PPropInfo;
o:Tobject;
begin
  aControl.Setbounds(
                      ScaleValue96(aControl.left),
                      ScaleValue96(aControl.top),
                      ScaleValue96(aControl.width),
                      ScaleValue96(aControl.height)
                    );

  if ScaleFonts then   
  Begin
    MetaRecord := getpropinfo(aControl,'Font');
    if MetaRecord <> nil then begin
      o := getobjectProp( aControl,'Font');

      if getpropinfo(o,'Height') <> Nil then begin
       x := GetOrdProp(o, 'Height');
       x := ScaleValue96(x);
       SetOrdProp(o, 'Height',x);
      end else begin
       x := GetOrdProp(o, 'Size');
       x := ScaleValue96(x);
       SetOrdProp(o, 'Size',x);
      end;

    end;
  End;

  if NoWordWrap then 
  begin
    MetaRecord := getpropinfo(aControl,'NoWrap');
    if MetaRecord <> nil then
      SetOrdProp(aControl, 'NoWrap',-1);
  end;

  if aControl is Twincontrol then
  Begin
    For i  := 0 to Pred(Twincontrol(aControl).ControlCount) do
    Begin
      ScaleControl(Twincontrol(aControl).Controls[i],ScaleFonts,NoWordWrap);
    End;
  End;
end;

nachteil = In der Version werden glaube ich "Tabs" nicht richtig berücksichtigt.

[stalkingwolf]

Moin,

das mit der DPI würde aber nur bewirken das auf HighDPI Monitoren die Fenster nicht winzig sind. Ich würde keinen Fensterinhalt dadurch gewinnen.

Da wir nun fast alle Kunden auf unseren neuen Programmstand umgestellt haben, kommen doch noch ein paar mehr mit so billigen 15" Notebooks und 1366x768 Auflösungen.

Wer in Gottesnamen gibt seinem Mitarbeitern für ein ERP Software Displays mit 1366x768. Ich hasse meine Branche

btw. weil es oben angesprochen wurde. Wir haben extra 27" 1920x1080 Schirme als Drittmonitore um darauf unsere Software zu testen. IMO sollte das heute überall Standard sein, aber man erlebt halt jeden Tag was neues.
Im POS Bereich haben einige Kunden sogar noch 1024x768. Weil da vor Jahren was zusammengezimmert wurde wo kein moderner Monitor Platz drin hat und umbauen kostet halt Geld.