Skalierbare Fensterinhalte

[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.