Quickreport: Alle Größenangaben sind mit 25,4 multipliziert

[BlueStarHH]

Hallo,

ich nutze Quickreport. Wenn bei einem Kunden ein Report erstellt wird, sind dort alle Größen/Positionen mit 25,4 multipliziert. D.h. in meiner Ini steht z.B. für ein Text-Objekt Left = 1 mm und Top = 10 mm, dann wird das Textobjekt aber bei Left = 25,4 mm und Top = 254 mm plaziert. Warum? Windows 10, Skalierung 100 %. Auf vielen anderen PCs läuft der selbe Code ohne Probleme.

[DeddyH]

Da stimmt die Einheit nicht. 2,54 ist der Umrechnungsfaktor von cm zu Zoll.

[Jumpy]

Das sieht dann so aus, als ob auf dem Rechner deine 1 als 1 Inch = 25,4 mm interpretiert wird.
Könnte also eine Lokalisierungs-Sache sein.

[BlueStarHH]

Zitat:

Zitat von DeddyH (Beitrag 1505969)

Da stimmt die Einheit nicht. 2,54 ist der Umrechnungsfaktor von cm zu Zoll.

Alle Quickreport-Komponmenten haben die Eigenschaften Size.Left und Size.Top. Diesen weise ich einfach einen Wert zu. Z.B. eine 1 für einen Milimeter. Ich selber rechne gar nichts um. Der Fehler liegt also im Quickreport? Komisch, dass das Problem dann all die Jahre unentdeckt blieb.

[BlueStarHH]

Danke an alle. Ich habe das Problem in der QuickRpt.pas gefunden:

Delphi-Quellcode:

initialization
...
  LocalMeasureInches := GetLocaleChar(DefaultLCID, LOCALE_IMEASURE, ' ') = '1';
...

Hier wird versucht die Maßeinheit Millimeter oder Inch vom System auszulesen. Auf dem Kunden-PC wird Inch erkannt, obwohl in der Systemsteuerung Millimeter eingestellt sind. Da keiner mit Inch arbeiten soll, habe ich einfach LocalMeasureInches := false gesetzt und alles klappt. (Ein ähnliches Problem gab/gib? es ja mit den Tausender- und Dezialtrennern in Formatsettings.)

[BerndS]

Ich bzw. unsere Kunden hatten das Problem noch nie.
Trozdem hab ich die Zeile in der Unit gleich geändert.
Danke für den Tip.:thumb:

[Frickler]

Zitat:

Zitat von BlueStarHH (Beitrag 1505983)

Auf dem Kunden-PC wird Inch erkannt, obwohl in der Systemsteuerung Millimeter eingestellt sind.

Das passierte früher bei der Vorinstallation von OEM PCs bei verschiedenen Herstellern; gesehen habe ich es bei Dell und HP.

Abhilfe: in der Systemsteuerung einmal die Ländereinstellung umstellen auf Englisch (US), speichern, und dann zurückstellen nach Deutsch (Deutschland).

Das hatten wir eine Weile so oft bei Kunden, dass ich ein kleines Testprogramm geschrieben hatte...

[himitsu]

Es kommt drauf an, was "Left" für eine Einheit hat.
Pixel, Millimeter, Inch, Dots, oder sonstwas

Kann man irgendwo QuickReport sagen, in welcher Einheit es rechnen soll?

[BlueStarHH]

Zitat:

Zitat von himitsu (Beitrag 1506002)

Es kommt drauf an, was "Left" für eine Einheit hat.
Pixel, Millimeter, Inch, Dots, oder sonstwas

Kann man irgendwo QuickReport sagen, in welcher Einheit es rechnen soll?

Ja, jede Komponente hat diese Einheit Eigenschaft "Units". Und diese wird u.a. über LocalMeasureInches festgelegt. Siehe oben und hier:

Delphi-Quellcode:

constructor TQRUnitBase.Create;
begin
  if LocalMeasureInches then
    Units := Inches
  else
    Units := MM;
...
end;

[Rolf Frei]

Die richtige Lösung ist die von Frickler erwähnte einmalige Umstellung der Spracheisntellungen. Danach passt alles. Wenn du das ncht machst wirst du auch mit anderern Einstelugn eproblem haben, weil das alles mit den US-Einstellungen kommt, also auch das Zahlenformat, Währung, Datumsformat, etc.

Bei bestimmte OEMS wie HP wird nur der UNocode teil der Einstelluggen richtig konfiguriert und die ANSI-Einstellungen bleiben auf dem Standart US. Somit sehen alle ANSI-Programme nur die englischen Einstellungen. Durch ein Um- und Zurückstellen der Sparcheinstellung wird der ANSI Teil der Einstellung richtig gespeichert.

[BlueStarHH]

Zitat:

Zitat von Rolf Frei (Beitrag 1506035)

Die richtige Lösung ist die von Frickler erwähnte einmalige Umstellung der Spracheisntellungen. Danach passt alles. Wenn du das ncht machst wirst du auch mit anderern Einstelugn eproblem haben, weil das alles mit den US-Einstellungen kommt, also auch das Zahlenformat, Währung, Datumsformat, etc.

Bei bestimmte OEMS wie HP wird nur der UNocode teil der Einstelluggen richtig konfiguriert und die ANSI-Einstellungen bleiben auf dem Standart US. Somit sehen alle ANSI-Programme nur die englischen Einstellungen. Durch ein Um- und Zurückstellen der Sparcheinstellung wird der ANSI Teil der Einstellung richtig gespeichert.

Danke für die Erklärung. Aber das kann ich meinen Kunden nicht zumuten. Die wären damit überfordert.

[himitsu]

Es gibt keine andere befriedigende/einfache Lösung.

Es ist ein Fehler im vorinstallierten Windows, wo jemand die Einstellungen manuell in der Registry teilweise vergessen hat zu setzen. (und jener ist seit Jahrzehnten zu doof das zu reparieren)
In der Registry gibt es verschiedene Stellen, wo gleiche/ähnliche Einstellungen gespeichert sind.
* teilweise ANSI- und Unicode-API getrennt
* teilweise für 64 und 32 Bit getrennt
* teilweise auch noch alte "Legacy"-Settings, welche aber einige Programme immernoch auslesen
* ...

Durch das Ändern und zurücksetzen der Einstellungen, wird das "überall" durch Windows neu richtig eingetragen.

Du darfst das gern einmal machen, dabei alle Änderungen in der Registry mitschneiden, da dann das Nötige rausfiltern, denn es ändert sich ständig was in der Registry, was dann aber hiermit nichts zu tun hat,
und dann kannst du dass als .reg oder .cmd (reg add) deinem Kunden geben, was er nur noch einmal im Explorer auszuführen braucht.


Andere Lösung: Ein englisches Windows nutzen, da stimmt alles noch. :roll:

[bcvs]

So etwas ähnliches gab es doch schon mal bei Windows 7.
Das hatte auf einigen Rechnern ein amerikanisches Datumsformat, obwohl die Ländereinstellung auf Deutschland stand. Die Lösung war damals auch, die Ländereinstellung hin- und zurüchzustellen.

Oder diese beiden Codezeilen:

Delphi-Quellcode:

    SetThreadLocale(LOCALE_USER_DEFAULT);
    GetFormatSettings;

Vielleicht hilft das ja auch hier