SL1+Windows 7: GraQueryTextBox() funktioniert n. rtg.! [Erl.

[Martin Altmann]

Moins,
ist da von Euch auch schon jemand drüber gestolpert? Ich bin ja jetzt unter Windows 7 unterwegs und nutze Xbase++ 1.90.355
Wegen einer Anfrage in der Alaska-Newsgroup habe ich mir (seit Monaten) mal wieder einen meiner Programmteile angeschaut. Ich drucke Text auf einer Seite und mische dabei unterschiedlich Schriftschnitte. Dazu ermittele ich immer, wie lang der gedruckte Text ist um dann nach Umschalten auf den anderen Schriftschnitt direkt dahinter weiter zu drucken.
Das ging bisher auch immer recht gut.
Nun nicht mehr - wobei ich nicht weiß, ob es am SL1 liegt oder an Windows 7 oder an beidem gemeinsam.
Ich hänge mal ein Bild an, wie der Ausdruck rauskommt:

GraQueryTextBox.JPG (88.45 KiB) 6590 mal betrachtet

Wie ihr anhand des fetten Textes sehen könnt, fängt dieser immer zu weit links an.
Die restlichen Blocksatzdrucke funktionieren auch nicht mehr korrekt - dort nutze ich ebenfalls GraQueryTextBox().
Hier mal der Code für einen Teil:

Code: Alles auswählen

GraSetFont( oPS, oFontnvsmall )
nY -= 55
blocksatz( oPS, nY, 60, 665, "Nach der neuen Tierschutz-Hundeverordnung gilt ab" )
nY -= 25
blocksatz( oPS, nY, 60, 665, "01. Mai 2002 ein Ausstellungsverbot für folgende" )
nY -= 25
GraStringAt( oPS, { 60, nY }, "Hunde aus dem " )
aTextBox := GraQueryTextBox( oPS, "Hunde aus dem " )
lb := ( aTextBox[ 3, 1 ] - aTextBox[ 2, 1 ] )
GraSetFont( oPS, oFontfvsmall )
GraStringAt( oPS, { 60 + lb, nY }, "In- und Ausland:" )
GraSetFont( oPS, oFontnvsmall )
nY -= 32

Die beiden Schriftarten unterscheiden sich nur in ihrem Schnitt (fett bzw. nicht fett) - ansonsten ist Schriftart und -größe identisch.

Hat diesen Effekt noch jemand beobachtet?

Viele Grüße,
Martin

[AUGE_OHR]

hi,

sind es 4 Pixel ? (ich hätte da eine Vermutung ...)

[Martin Altmann]

Hmm - auf 4 Pixel würde ich mich da nicht festlegen wollen - das kann durchaus mehr sein, würde ich mal denken! Sind ja immer hin 1-2 Zeichen, die sich da überschneiden...

Viele Grüße,
Martin

[Martin Altmann]

An Windows 7 scheint es nicht zu liegen!
Unter XP SP2 kompiliert - gleiches Ergebnis!
Also liegt es wahrscheinlich am SL1 - gibt es hier jemanden, der das SL1 noch nicht nutzt und die Probleme auch hat?

Viele Grüße,
Martin

[brandelh]

Hallo Martin,

ich habe eben mit meiner Druckerklasse (im TEST.PRG ist ein Beispiel für PrintMemo() mit Blocksatz)
auf Win XP SP3 geprüft und keine Unterschiede (also keine Fehler) im rechten Rand zwischen
1.90.331 und 1.90.355 gefunden. Mit Win 7 kann ich erst heute Abend probieren.

Eventuell liegt es aber gar nicht am "Messen", sondern an der Rückgabe der "neuen Pen Position".
Eigentlich müsste man ja ohne Angabe von Werten immer direkt hintereinander drucken,
aber wenn ich mich recht erinnere hat das nicht funktioniert. Ich meine ich führe selbst die
Druckposition in Variablen mit und gebe diese an. Es ist aber schon Jahre her, dass ich diese
Methode geschrieben habe und weiß es deshalb nicht mehr so genau

[Martin Altmann]

Hallo Hubert,
darum gebe ich ja auch immer die Koordinaten an.
Wie Du oben siehst, drucke ich den Text, ermittele die Breite des gedruckten Textes und drucke an die neue Position den Rest.

Viele Grüße,
Martin

[brandelh]

Hallo Martin,

sorry ich hatte dein Beispiel nicht so genau gelesen, sondern gleich meines probiert.

Die obere Zeile mit der Funktion für Blocksatz müsste das gleiche Machen wie meine Funktion,
aber nur ein Wort überschneidet sich, das kann ich mir nicht erklären. Auch der Wechsel
des Fonts müsste eigentlich gehen. Aber je nach Druckertreiber hatte ich gelegentlich auch
mal Schwierigkeiten - speziell bei der 10cpi Simmulation.

Teste doch mal auf einem PDF Druckertreiber bzw. einem anderen Drucker ob das Ergebnis variiert.
Es könnte nämlich sein, dass ein Font (oder wer auch immer) eine falsche Breite zurückgibt,
speziell bei PS Druckern die interne Schriften verwenden ...

Ein einfacher Test wäre auch wenn du die Array Werte einfach ausdruckst.
Unter 1.90.331 und 1.90.335 sollte auf dem gleichen Rechner das gleiche Ergebnis kommen

[Martin Altmann]

Hallo Hubert,
ich habe direkt gedruckt (Brother Laserdrucker), mittels Microsoft XPS-Writer in ein .xps - dies beides auf dem Windows 7 Rechner.
Hier im Büro (unter XP SP2) habe ich gedruckt in ein PDF (mittels CutePDF-Writer) und ein .TIF (mittels Microsoft Office Document Image Writer).
Übrigens - hier meine o.g. Schriften:

oFontnvsmall := XbpFont():new( ::oPresSpace ):create( "7.Arial" )
oFontfvsmall := XbpFont():new( ::oPresSpace ):create( "7.Arial" + FONT_STYLE_BOLD )

Viele Grüße,
Martin

[Martin Altmann]

So,
habe jetzt mal eine Art Lineal auf die Seite kurz über den fraglichen Stellen gedruckt.
Das Problem ist GraQueryTextBox() - dies liefert die falschen Ergebnisse!
Es wird genau an die Stelle gedruckt, die vorher auch berechnet wurde. Und da die Berechnung fehlerhaft ist, fließt der Text halt falsch.

Viele Grüße,
Martin

[brandelh]

Hi,

und sind die Werte unter XP richtig ?

Hast du mal alle Werte angesehen (links unten, links oben, rechts unten, rechts oben) ?
Eventuell meint dein Font er wäre kursiv etc.

[Martin Altmann]

Hallo Hubert,
wie geschrieben - es gibt keinen Unterschied zwischen Windows 7 und XP.
Der berechnete Wert ist fehlerhaft! GraQueryTextBox( oPS, "Hunde aus dem " ) liefert (als berechnete Breite) 143. Gemessen muss es aber 178-180 sein!

Viele Grüße,
Martin

[AUGE_OHR]

wie geschrieben - es gibt keinen Unterschied zwischen Windows 7 und XP.
Der berechnete Wert ist fehlerhaft! GraQueryTextBox( oPS, "Hunde aus dem " ) liefert (als berechnete Breite) 143. Gemessen muss es aber 178-180 sein!

hm das wären ja > 30 Pixel ...

... und verschiedene Drucker (Treiber) hast du ja auch schon ausprobiert ... hm

zugegeben habe ich es noch nicht für Drucker versucht, aber meine ganzen Ownerdraw arbeiten ja auch mit GraQueryTextBox() und da wären mir > 30 Pixel aufgefallen.

... wenn ich mir nochmal deine "Ausdrucke" ansehe glaube ich aber nicht an > 30 Pixel ... das sind doch nicht so viele Zeichen (1-2 Buchstaben Breite), deshalb noch mal die 4 Pixel versuchen !

rücke jedesmal, nach dem "umschalten" auf einen anderen Font, das ganze um +4 Pixel weiter wenn du es "druckst" ob es dann passt. wenn ja ... "Border Padding" ...

[Martin Altmann]

Jimmy,
Du kannst das mit den 40 ruhig glauben
Es sind drei Zeichen, um die es verschoben ist! Der Ausdruck beginnt auf dem "e" - es sollte aber nach dem "dem " erfolgen. Also drei Zeichen weiter rechts.
Schriftgröße ist 7 Punkt.

Viele Grüße,
Martin

[Jan]

Hallo Martin,

bei mir funktioniert das. SL1 auf XP SP3. Hier mit Fett und Farbwechsel.

Muster.jpg (23.03 KiB) 6471 mal betrachtet

Kleinere Probleme gibt es, wenn das in einer alten Umgebung ohne SL1 kompiliert wurde, aber mit der Runtime-Umgebung des SL1 läuft.

Jan

[Martin Altmann]

Hallo Jan,
prima. Und wie sieht Dein source dazu aus? Und funktioniert der auch, wenn Du eine Schrift mit 7 Punkt Größe nimmst (wie in meinem Fall 7.Arial)?
Ich habe es ja auf Arbeit unter XP SP2 neu kompiliert - das ist also nicht das Problem.

Viele Grüße,
Martin

[brandelh]

Hallo Martin,

ich nutze in meiner Druckerklasse intern eine Funktion, die ich um die Ausgabe der Arrayelemente erweitert habe:

Code: Alles auswählen

*------------------------------------------------
static function GetTxtLen(aTextBox, nDrehen)
   local nTxtLen
   if nDrehen = 90 .or. nDrehen = 270           // Drehwinkel beachten - rotated ?
      nTxtLen   := aTextBox[4,2] - aTextBox[1,2]
   else   // nur richtig fr 0 und 180 ø, only correct for 0 and 180 ø
      nTxtLen   := aTextBox[3,1] - aTextBox[2,1]
   endif
   set alternate to d:\GetTextLen.txt additive
   set alternate on
   ? "1.90."+version(3), "GetTxtLen(aTextBox)",aTextBox
   set alternate to
return nTxtLen

Diese Funktion wird aufgerufen immer wenn BLOCKSATZ oder RECHTSBÜNDIG benötigt wird.
Die Druckausgaben in 6.Arial und 7.Arial sind bei mir genauso OK wie die alten mit 12. Times New Roman.
Hier die gespeicherten Log-Dateien

GetTextLen-331.txt

(16.04 KiB) 152-mal heruntergeladen

GetTextLen-355.txt

(16.04 KiB) 162-mal heruntergeladen

Ich kann keine Unterschiede feststellen, weder in der XPP Version, noch mit Win2000 oder Win7.

[Martin Altmann]

Hallo Hubert,
Du nutzt an der Stelle ja kein GraQueryTextBox(). Wie ermittelst Du denn mittels GetTextLen() die Länge?
Oder ist das Array, das Du als Parameter aTextBox übergibst das Ergebnis von GraQueryTextBox()?
Und wie bereitest Du denn die Seite vor? Setzt Du GraSegDrawMode()? Ich nicht - damit sollte ja eigentlich GRA_DM_DRAWANDRETAIN als Standardwert eingestellt sein - mit GRA_DM_RETAIN soll es ja Probleme bei GraQueryTextBox() geben - laut Hilfe! Oder muss ich das so verstehen, dass dieser Hinweis auch für GRA_DM_DRAWANDRETAIN gilt?

Viele Grüße,
Martin

[Martin Altmann]

Moins,
ich noch Mal...
Habe das Problem jetzt auch mit dem Beispielprogramm von Alaska nachstellen können (latürnich - das ist ja auch das, welches ich im Prinzip nutze)
Ich rede von ALASKA\XPPW32\SOURCE\samples\solution\Preview\Preview.prg - die Datei ist bei mir vom 10.04.2009.
Wenn man folgende Änderungen einbaut:
Zeile 151 aukommentieren (senkrechte Linien über die Seite)
in Zeile 161 schreiben:

Code: Alles auswählen

nI:=aPosX[1]

(initialisieren des Startpunktes)
Zeile 175 (GraStringAT(....)) auskommentieren (die alte Ausgabe) und direkt davor die folgenden Zeilen einfügen:

Code: Alles auswählen

GraStringAt( oPS, { nI, nY }, alltrim( xValue ) )
nBla := GraQueryTextBox( oPS, alltrim( xValue ) )
nI+= (nBla[ 3, 1 ] - nBla[ 2, 1 ])+ 5
GraStringAt( oPS, { nI, nY }, "|" )
nI+=5

Und schon hat man den bei mir beschriebenen Effekt!
Kann das mal bitte jemand bei sich kurz probieren? SL1 oder davor, Windows 7 oder XP - völlig egal.

Vielen Dank,
Martin

[brandelh]

Hallo Hubert,
Du nutzt an der Stelle ja kein GraQueryTextBox(). Wie ermittelst Du denn mittels GetTextLen() die Länge?
Oder ist das Array, das Du als Parameter aTextBox übergibst das Ergebnis von GraQueryTextBox()?

Klar, die Methode, welche drucken soll ermittelt die Array Koordinaten und übergibt diese an die Funktion,
wobei ich ja eine Drehung zulasse, daher kann ich das nicht direkt machen ...

Und wie bereitest Du denn die Seite vor? Setzt Du GraSegDrawMode()?
Ich nicht - damit sollte ja eigentlich GRA_DM_DRAWANDRETAIN als Standardwert eingestellt sein -
mit GRA_DM_RETAIN soll es ja Probleme bei GraQueryTextBox() geben - laut Hilfe!

Im Moment versteh ich nur Bahnhof ich seh mal nach ...

hier der Aufruf der Funktion ...

Code: Alles auswählen

      aTextBox  := GraQueryTextBox(::oPS, cTxt)
      nTxtLen   := GetTxtLen(aTextBox, nDrehen)

GraSegDrawMode(), GRA_DM_DRAWANDRETAIN und GRA_DM_RETAIN gibt es nicht in meinem Quellcode.
Ich nutze keine grafischen Segmente !

[Martin Altmann]

Habe gerade gesehen, dass in dem Programm von Alaska neuerdings der GraSegDrawMode() auf GRA_DM_RETAIN gesetzt wird! Das gibt ja Probleme.
Habe mal die beiden GraSegDrawMode()-Zeilen auskommentiert - gleicher Effekt.
Dann habe ich explizit am Anfang (also den ersten GraSegDrawMode) auf GRA_DM_DRAW gesetzt - damit funktioniert es! Es wird zwar nichts mehr angezeigt (da die Segmente ja nicht gespeichert werden können) sobald man sich an einen refresh der Anzeige macht, aber wenn man beispielsweise stark zommt und dann blättert, wird es (kurz) richtig angezeigt!
Es ist also tatsächlich der GraSegDrawMode() (wie ja auch bei GraQueryTextBox() beschrieben), der die Probleme macht!
Und nun? Hat jemand eine andere Idee, wie ich zuverlässig die Länge des Textes (in seiner grafischen Direktive) herausbekommen kann???

Viele Grüße,
Martin

[brandelh]

Hallo Martin,

jetzt haben wir den Unterschied gefunden

schmeiß den Segment Kram raus und drucke direkt Der Drucker braucht kein segment.

Ich nutze die Segmente nur bei der Vorschau mit den Standardeinstellungen von GraSegDrawMode() ...
und jetzt weiß ich auch warum da dann ab und zu die Vorschau nicht so exakt stimmt, aber der Monitor ist klein
und Hauptsache die Druckausgabe stimmt.

Ansonsten könntest du auch hingehen und die Texte in Arrays mit (leeren) Positionselementen vorhalten.
Dann für alle Strings der gleichen Schrift die Schrift einstellen, Breite berechnen und Breite und Position merken.
Danach baust du dann einmalig das Segment mit den ermittelten Werten...

[Martin Altmann]

Hallo Hubert,
die Segment kann ich nicht raus schmeißen, da ich ja mit Vorschau arbeiten will
Aber ich werde einfach zwei PresentationSpace()s verwenden - einen, in den ich zeichne (wie jetzt auch) und einen, den ich nur für die Berechnung nutze (mit GraSegDrawMode() GRA_DM_DRAW). So, wie es in der Hilfe zu GraQueryTextBox() auch vorgeschlagen wird.
Da werde ich mich heute Nachmittag mal dran versuchen.

Viele Grüße,
Martin

[brandelh]

Hallo Hubert,
die Segment kann ich nicht raus schmeißen, da ich ja mit Vorschau arbeiten will

Es wäre schon viel Arbeit bei dir den Druck von der preview zu trennen und wenn du die vergrößern kannst,
sind die Unterschiede ja auch wirklich übel.

Aber ich werde einfach zwei PresentationSpace()s verwenden - einen, in den ich zeichne (wie jetzt auch) und einen, den ich nur für die Berechnung nutze (mit GraSegDrawMode() GRA_DM_DRAW).

oder so ... wenn die PresSpace und die Fonts identisch sind, muss das gehen.

So, wie es in der Hilfe zu GraQueryTextBox() auch vorgeschlagen wird.

was du alles findest ... ich habe das wohl überlesen beim Überfliegen der Änderungen zur 355 ...
aber ich habe ja meine Druckerklasse und deshalb keinen Bedarf

[Martin Altmann]

Hmmm,
leider liest sich das einfacher, als es zu sein scheint.
Ich habe in dem XbpPreview (von Alaska) versucht, einen zweiten PresSpace zu definieren und dafür den GraSegDrawMode auf GRA_DM_DRAW zu ändern.
Dann habe ich versucht, wechselweise mit den beiden PresSpaces zu arbeiten (auf einem zu zeichnen und auf dem anderen mittels GraQueryTextBox() die Größe zu berechnen.
Hat nicht geklappt.
Also habe ich versucht, bei den Wechseln zwischen den Presentationspaces immer das gerade genutzte Segment zu schließen und das andere wider zu öffnen (und umgekehrt).
Damit habe ich erreicht, dass die Druckausgabe in der Vorschau gut 20 Mal länger dauert, als vorher. Aber funktionieren (optisch) tut es trotzdem nicht!
Hat jemand eine Idee anhand des Alaska-XbpPreview()-Beispiels?
Vielleicht denke ich ja auch nur zu kompliziert - aber ich bin mit meinem Latein im Moment am Ende...

Viele Grüße,
Martin

[AUGE_OHR]

hi,

ich sprach gerade mit einem Kollegen und der meinte das er mit Word Vorlagen, welche unter XP erstellt wurde, schon unter VISTA die selben Probleme hatte.

Wie auch bei Martins Snapshot wurden die Buchstaben nach Links verschoben wenn ein Font Wechsel war.

Er hat dann die Druckertreiber gewechselt ... solange bis es "passte" wobei er dann bei den "original" M$ Treibern gelandet ist.

Diese haben zwar oft nicht den vollen Funktions-Umfang, aber er druckt "richtig"

Mein Einwand, "aber wie ist das mit PDF" wischte er beseite und sagte :
irgendwie sitzen die Treiber ab VISTA "ganz tief" im System und nur ein faule Ei und die ganze Sache "stinkt".