Breite einer Zeichenkette

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Breite einer Zeichenkette

Beitrag von Statler » Mo, 14. Mai 2018 12:42

Hallo zusammen,

folgendes Problem:

Bei der Ausgabe fuer due Druckvorschau muessen Zeichenketten abgeschnitten werden, damit sie noch in die Tabelle passen. Eigentlich kein Problem. Mit

aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)

kann die Breite der Zeichenkette ermittelt werden, den String kann man dann iterativ auf die zulaessige Breite verkuerzen. "GraQueryTextBox" rechnet bei mir aber falsch. Z.B. ist die Zeichenkette 741 Pts. breit, zulaessig waeren 750, bei der anschliesenden Ausgabe ist diese aber mindestestens 50 Pts. laenger und schreibt in die naechste Spalte. Das ganze variiert noch in Abhaengigkeit der Fonts und Fontgroessen.

Ist dieses Problem bekannt ? Mache ich einen Denkfehler ?

So definiere ich den Font:

::oFont := XbpFont ():new (::oPresSpace)
::oFont:familyName:= "Arial"
::oFont:nominalPointSize:= 9
::oFont:generic := .T.
::oFont:create()

das hier fuehrt zum selben Ergebnis:

::oFont := XbpFont():new():create( "10.Arial.normal" )

Gruss

Achim

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Mo, 14. Mai 2018 14:37

Hallo,

beim Durchforsten der Hilfe bin ich auf "GraPathClip" gestossen. Das ist genau das, was ich gesucht habe. Von daher hat sich das Problem erledigt. Das "GraQueryTextBox" falsch rechnet, ist aber trotz allem erstaunlich.

Gruss

Achim

DelUser01

Re: Breite einer Zeichenkette

Beitrag von DelUser01 » Mo, 14. Mai 2018 17:12

Statler hat geschrieben:
Mo, 14. Mai 2018 14:37
Das "GraQueryTextBox" falsch rechnet, ist aber trotz allem erstaunlich.
Hallo Achim
das wäre ja sehr übel wenn GraQueryTextBox falsch rechnen würde!

Da stimmt irgend etwas mit Deiner Vorgehensweise nicht.
Keine oder falsche Manifest-Datei mit Desktop-Darstellung <> 100%
oder was auch immer.

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Mo, 14. Mai 2018 22:00

Hallo Roland,

es gibt so manches, was in Xbase nicht sauber laeuft. Meine Spoolerumgebung basiert auf dem "Preview" Beispiel von Xbase, das ich mir im Laufe der Jahre angepasst habe.

>Keine oder falsche Manifest-Datei mit Desktop-Darstellung <> 100%
was meinst Du damit ?

Aktuell mache ich das nun so:

GraPathBegin (::oViewPort:oPresSpace)
GraBox (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
GraPathEnd (::oViewPort:oPresSpace)
GraPathClip (::oViewPort:oPresSpace, .T.)

Das funktioniert pixelgenau. Wenn ich zwei Zeilen vorher "GraQueryTextBox ()" laufen lasse, liefert diese falsche Koordinaten.


Hier mal eine Quick+Dirty Loesung, die zwar nicht schoen ist, aber funktionieren sollte:

DO WHILE .T.
aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
*
IF aPoints [4, 1] - aPoints [1, 1] < nLimit
EXIT
ENDIF
*
cValue:= LEFT (cValue, LEN (cValue) - 1)
ENDDO

der String ist nach Durchlauf der Schleife auf eine Laenge < nLimit gekuerzt, bei der anschliessenden Ausgabe ist er aber groesser, als von GraQueryTextBox () vorhergesagt. Da alles andere pixelgenau funktioniert, kann meine Umgebung nicht voellig falsch sein.

Gruss

Achim

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Di, 15. Mai 2018 1:25

Statler hat geschrieben:
Mo, 14. Mai 2018 22:00
es gibt so manches, was in Xbase nicht sauber laeuft. Meine Spoolerumgebung basiert auf dem "Preview" Beispiel von Xbase, das ich mir im Laufe der Jahre angepasst habe.
Ironie ON
vor oder nach deinen Anpassungen ;)
Ironie OFF
Statler hat geschrieben: Aktuell mache ich das nun so:

Code: Alles auswählen

GraPathBegin (::oViewPort:oPresSpace)
GraBox       (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
GraPathEnd   (::oViewPort:oPresSpace) 
GraPathClip  (::oViewPort:oPresSpace, .T.)
Das funktioniert pixelgenau.
so wie es jetzt aussieht nimmst du deinen eigenen Grafischen Pfad, Ok.
Statler hat geschrieben:Wenn ich zwei Zeilen vorher "GraQueryTextBox ()" laufen lasse, liefert diese falsche Koordinaten.
hm ...
zeigt doch bitte mal die 3 Zeile davor auch

ist dabei schon ein Segment geöffent mit

Code: Alles auswählen

   nSegment := GraSegOpen( oPS )
geöffnet wenn du deine Berechnung mit GraQueryTextBox() (welchen Font wo gesetzt) machst ?

ich würde schon gerne sehen wie/wo du jeweils den ::oFont setzt (wirst ja nicht nur mit Arial.9 arbeiten)

---

es gibt von Günter Beyes ein Demo / Thread "GraQueryTextBox vs. GetTextExtentPoint32"***
wenn du also "ausprobierst" ob noch etwas passt wäre die API Methode wesentlich schneller ... und genauer.

Xbpfont ist wie üblich "beschränkt" und ein Object ... und man bekommt kein Handle so einfach


*** viewtopic.php?f=12&t=5948&p=66896
in dem Demo kann man die Font Beschränkungen erkennen welche Möglichkeiten es gäbe
gruss by OHR
Jimmy

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Di, 15. Mai 2018 10:57

Hallo,

Hier die Ausgaberoutine. Ich habe mir eine Umgebung fuer Tabellendruck gebaut, in der Ich Zeilenweise adressesieren kann. Die Spalten werden ueber die ueblichen X-Koordinaten adressiert. Spalten werden durch sekrechte Linien getrennt. Mein Ziel war es, das Strings, die zwischen die Linien gedruckt werden, diese nicht ueberschreiben. Die Variable nLimit enthaelt den Abstand zwischen zwei Linien.

Code: Alles auswählen

METHOD Spooler:printFeld (nSpalte, nZeile, xFeld, nAlignment, nOffset, nLimit)
*
*******************************************************************
*                                                Lokale Variablen *
*******************************************************************
*
LOCAL nX, nY, cValue, nFontmitte, aPoints,;
;
      aPageSize:= ::oViewPort:aPageSize,;
      aAttr:=     ARRAY (GRA_AS_COUNT)
*
*******************************************************************
*                                                Feld aufbereiten *
*******************************************************************
*
cValue:= xFeld
*
IF VALTYPE (xFeld) == "N"
   cValue:= ALLTRIM (::getFeld (xFeld))
ENDIF
*
*IF ! EMPTY (nLimit)
*   DO WHILE .T.
*      aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
*      *
*      IF aPoints [4, 1] - aPoints [1, 1] < nLimit
*         EXIT
*      ENDIF
*      *
*      cValue:= LEFT (cValue, LEN (cValue) - 1)
*     debugout (STR (nLimit, 4)+" " + STR (aPoints [4, 1] - aPoints [1, 1], 4))
*   ENDDO
*ENDIF
*
*******************************************************************
*                               X-Koordinate (Spalte) aufbereiten *
*******************************************************************
*
nX:= ::nBorderLeft + nSpalte
*
IF nAlignment == kPrintAlignL
   aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_LEFT
ENDIF
*
IF nAlignment == kPrintAlignC
   aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_CENTER
ENDIF
*
IF nAlignment == kPrintAlignR
   aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_RIGHT
ENDIF
*
*******************************************************************
*                                Y-Koordinate (Zeile) aufbereiten *
*******************************************************************
*
nY:= 0
*
IF nOffset == kPrintUnten
   nY:= ::nBorderFooter + (nZeile - 1) * ::nFontHoehe + INT (::nFontHoehe / 2)
ENDIF
*
IF nOffset == kPrintOben
   nY:= aPageSize [2] - (::nBorderHeader + nZeile * ::nFontHoehe - INT (::nFontHoehe / 2))
ENDIF
*
IF nOffset == kPrintObenOffset
   nY:= aPageSize [2] - (::nBorderHeader + ::nOffsetData + nZeile * ::nFontHoehe - INT (::nFontHoehe / 2))
ENDIF
*
*******************************************************************
*                                                   Text ausgeben *
*******************************************************************
*
aAttr [GRA_AS_VERTALIGN]:= GRA_VALIGN_TOP
nFontmitte:=               INT (::oViewPort:oFont:height / 2)
*
* // Eventuell Begrenzung einrichten //
*
IF ! EMPTY (nLimit) .AND. nAlignment == kPrintAlignL
   GraPathBegin (::oViewPort:oPresSpace)
   GraBox       (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
   GraPathEnd   (::oViewPort:oPresSpace) 
   GraPathClip  (::oViewPort:oPresSpace, .T.)
ENDIF
*
* // Zeichenkette ausgeben //
*
GraSetAttrString (::oViewPort:oPresSpace, aAttr )
GraStringAt      (::oViewPort:oPresSpace, {nX, nY + nFontmitte}, cValue)
*
* // Eventuell Begrenzung wieder aufheben //
*
IF ! EMPTY (nLimit) .AND. nAlignment == kPrintAlignL
   GraPathClip  (::oViewPort:oPresSpace, .F.)    
ENDIF
*
*******************************************************************
*                                                       Das war`s *
*******************************************************************
*
RETURN cValue
>ich würde schon gerne sehen wie/wo du jeweils den ::oFont setzt (wirst ja nicht nur mit Arial.9 arbeiten)

ich arbeite nur mit Areal.9. Das sind einfache Buchhaltungslisten, Optik interssiert da niemanden. Der Fond wir einmal zu Anfang gesetzt.

>ist dabei schon ein Segment geöffent mit

Ja, an einer anderen Stelle:

GraSegDrawMode (oPS, GRA_DM_RETAIN)
nSegment:= GraSegOpen (oPS)

Gruss

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14530
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: Breite einer Zeichenkette

Beitrag von Martin Altmann » Di, 15. Mai 2018 11:11

Von oPS sehe ich aber nichts in Deiner Methode!
Wenn Du mit GraQueryTextBox() arbeitest, geht das so (und zwar ganz wunderbar):

Code: Alles auswählen

GraStringAt( oPS, { 200, nY }, text )
nY -= 4
aTextBox	:= GraQueryTextBox( oPS, text )
GraLine( oPS, {200, nY}, { 200 + ( aTextBox[ 3, 1 ] - aTextBox[ 2, 1 ] ), nY} )
Damit wird der Text in der Variable text an der Position 200,nY ausgegeben und dann vier Pixel tiefer mit einer Linie unterstrichen, die genauso lange ist, wie der Text.
Der :mode des PresentationSpace ist in meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Di, 15. Mai 2018 12:36

Hallo,

>Von oPS sehe ich aber nichts in Deiner Methode!
heist bei mir: ::oViewPort:oPresSpace

>meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC
verwende ich auch.

Gruss

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Breite einer Zeichenkette

Beitrag von brandelh » Di, 15. Mai 2018 18:22

In meiner Druckerklasse (HBPrinter) nutze ich in der Methode PrintMemo() diese Funktion für den Blocksatz, funktioniert einwandfrei,
wenn man alles richtig macht. In der Hilfe wird oft oPS weg gelassen und das geht natürlich nicht, die oPS muss gleich sein und von dem Drucker.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Di, 15. Mai 2018 21:45

moin,
Statler hat geschrieben:
Di, 15. Mai 2018 12:36
>Von oPS sehe ich aber nichts in Deiner Methode!
heist bei mir: ::oViewPort:oPresSpace
es geht doch alles über die Method drawPage()
die malt zwar eine GraBox() "vorher" aber dann geht es an ein Segment welche mit

Code: Alles auswählen

   GraSegDraw( ::presSpace(), ::segments[nPageNo] )
gemalt wird. in einem Segment "wirken" dadurch die GRA nun innerhalb eines "GRA-Path".
ein Segment ist aber nur temporär d.h. wenn müsste man den oPS von GraSegOpen(oPS)/GraSegClose(oPS) nehmen um GraSetFont(oPS) zu verwenden.

was Alaska da mit

Code: Alles auswählen

   ::oPresSpace:setFont( ::oFont )
macht ist IHMO nur verwirrend da man gewöhnlich nicht nur einen Font benutzt und es für GRA eben eigene Befehle gibt :!:
gruss by OHR
Jimmy

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Di, 15. Mai 2018 23:05

Hallo zusammen,

ich habe noch ein paar Versuche gemacht. Das Problem haengt an der Schrift "X.Arial.normal" < 11 Punkte. Bei 11 bis ueber 20 Punkte rechtnet die Funktion einwandfrei, bei 9 und kleiner kommt nur noch Muell raus. Zum Vergleich habe ich noch die Api Funktion laufen lassen. Die Ergebnisse weichen um ein paar Pixel ab, sind aber tendenziell genaus so falsch.

Code: Alles auswählen

FUNCTION GetTextExtents (oPs, cText)

LOCAL sSize := space(8)
LOCAL lOK   := .F.
LOCAL hDC, nWidth, nHeight

STATIC tpl
IF tpl = NIL
   tpl := DllPrepareCall("gdi32.dll", DLL_STDCALL, "GetTextExtentPoint32A" )
ENDIF



oPS:lockHDC ( 4, @hDC ) // param value 4: select font into device context

IF DllExecuteCall( tpl, hDC, cText, len( cText ), @sSize ) <> 0
   lOK     := .t.
   nWidth  := Bin2L( substr( sSize, 1, 4 ) )
   nHeight := Bin2L( substr( sSize, 5, 4 ) )

debugout ({nWidth, nHeight})

ENDIF

RETURN lOK
Mit der Schrift "X.Euphemia.normal" sieht die Sache voellig anders aus, genaue Berechnungen bis unter 6 Punkte. Arial besteht aus mehreren Schriften, Euphemia gibt es nur einmal. Sonst ist mir kein Unterschuíed aufgefallen. Vectorschriften sind es beide.

Ich habe ein Win7 Umgebung.

Gruss

Achim

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1542
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Breite einer Zeichenkette

Beitrag von Werner_Bayern » Di, 15. Mai 2018 23:44

Servus Achim,

die Erfahrung hab ich leider auch schon machen müssen, dass GraQueryTextBox() bei manchen Schriftarten in bestimmten Größen (!) falsche Ergebnisse bei der pixelgenauen Breitenberechnung liefert. Hab aktuell gerade nochmal mein Testprogramm von 2016 laufen lassen: Es werden aktuell alle Fonts korrekt berechnet. Aktuelles Windows 10, aktuelles Xbase++ (918).

Fonts werden fast mit jedem größerem Windows-Update geändert. Teste doch mal auf einem aktuellem Win10-System.
es grüßt euch

Werner

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Mi, 16. Mai 2018 2:12

hi Achim ,
Statler hat geschrieben:
Di, 15. Mai 2018 23:05
Bei 11 bis ueber 20 Punkte rechtnet die Funktion einwandfrei, bei 9 und kleiner kommt nur noch Muell raus.
bislang gehst du davon aus das die Berechnung falsch seien aber was wenn die API "falsche/fehlende" Informationen vom Font bekommt ?
---
in meiner Demo gehe ich nun den anderen Weg.
Cre3Font.jpg
Cre3Font.jpg (71.51 KiB) 887 mal betrachtet
Cre3Font.zip
v1.9.355
need ot4xb
(10.43 KiB) 17-mal heruntergeladen

ich wähle aus einem (vorgegebenen) XbpFontDialog() einen Font.

auf einer XbpStatic lasse ich nun eine String anzeigen, Xbase++ like mit o:SetCaption()
das 2nd XbpStatic verwendet nun das Font-Handle welches neu erzeugt wurde und den selben String
das 3th XbpStatic arbeitet mit @ot4xb:_create_font_() wo ich mich an einer Font Grössen Umrechnung versucht habe

zu 2 & 3 muss ich noch sagen das ich @user32:DrawTextA() verwendet hab also per API

wie schon gesagt es ergeben sich Unterschiede aber eben schon beim Font der zur Berechnung genommen wird.
im Demo sehe ich den Unterschied und das wäre auch das Ergebnis einer Berechnung (für den Bildschirm in Pixel)

p.s. noch sprechen wir von "A"nsi aber mit Unicode "W" wird das mit den Fonts nicht einfacher ...
gruss by OHR
Jimmy

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Mi, 16. Mai 2018 16:52

Hallo,

>bislang gehst du davon aus das die Berechnung falsch seien aber was wenn die API "falsche/fehlende" Informationen vom Font bekommt ?

Ob jetzt die Api falsch rechnet oder der Font falsche Daten liefert ist erstmal uninteressant, das gelieferte Ergeniss ist unbrauchbar, warum auch immmer.

Zur genauen Analyse koennte man einen Text in eine berechnete Box drucken, und schauen, ob das passt; mit verschiedenen Fonts und verschiedenen Groessen.

Gruss

Achim

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Mi, 16. Mai 2018 18:20

Statler hat geschrieben:
Mi, 16. Mai 2018 16:52
Ob jetzt die Api falsch rechnet oder der Font falsche Daten liefert ist erstmal uninteressant, das gelieferte Ergeniss ist unbrauchbar, warum auch immer.
NEIN denn anscheint nimmst du ja einen XbpFont / Grösse wo es NICHT passt.

wenn ich einen Font per API aufbaue mit ot4xb passt es IMMER mit den API Functionen :!:
da kann ich jede beliebige Grösse wählen und es wird nicht "auf-/ab-gerundet" auf die nächste Point Grösse

Demo 2.) nimmt ja den XbpFont und wandelt es um. je nach gewählten Font bleibt 1.) und 2.) im mittleren Bereich gleich. unter 10 Point ist der XbpFont "zu gross" während er > 20 Point meistens "zu klein" ist.

die API rechnen richtig und wenn Xbase++ uns einen richtigen Font, mit allen Optionen, liefern würde hätten wir auch < 10 und > 20 Point keine Problem mit TTF Font.

p.s. bist du sicher das es der richtige Presspace ist ?

Code: Alles auswählen

METHOD XbpPreview:drawPage( nPageNo )
   // das ist auf dem XbpPressspace()
   GraBox( ::oPresSpace, {0,0}, ::aPageSize, GRA_FILL ) 

   // und das ist ein Micro-Presspace
   GraSegDraw( ::presSpace(), ::segments[nPageNo] )
überhaupt nutzt man üblicherweise GraSetFont(oPS, oFont) und nicht ::oPresSpace:setFont( ::oFont ) was Alaska hier tut ... warum auch immer
gruss by OHR
Jimmy

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Mi, 16. Mai 2018 18:57

Hallo,

erstmal gehe ich davon aus, das ich die von Xbase verwendeten Funktionen auch verwenden kann. In der Hilfe steht nichts bezueglich der Problematik mit den Fonts. Das man hier mit "dirty Hacks" hantieren muss, um eine laeppische Zeichenkette sauber auszudrucken, finde ich schon erstaunlich.

Meiner Meinung nach liegt ein Fehler in Xbase vor. Ich verwende Xbase Fonts in einer Xbase Umgebung mit Xbase Funktionen. Manchmal klappt es, manchmal nicht und man kann nicht mal sagen, woran es so genau liegt.

Mein Spooler basiert auf dem Xbase Preview Beispiel, Vorschau und Druck funktionieren seit Jahren einwandfrei, dort liegt kein Problem vor. User Werner hat das Problem ja ebenfalls bestaetigt.

Mit der Lib ot4xb ist das so eine Sache. Ich verwende die bereits fuer die Mail Umgebung (mapi). Kritische Teile einer Applikation, und der Druck gehoert dazu, nach otxb auzulagern ist ein gewisses Risiko. Was ist, wen Pablo irgenwann keinen Bock mehr hat und die Sache unter Xbase 3.0 nicht mehr laeuft ? Meine Philosphie ist, moeglichst nahe am Standard zu bleiben und Probleme mit z.B. neuen Betriebssysthemen durch Kauf eines aktuellen Compilers zu loesen.
Wegen Win10 bin ich auf Xbase 2.0 umgestiegen. Halber Tag Arbeit und meine Hauptapplikation lief wieder. Wenn dann noch irgendwelche externen Libs Aerger machen, kann das in Arbeit ausarten.

Bei der Sache mit den Fonts hat man aber anscheinend keine Wahl. Wenn Wortumbrueche oder pixelgenaues Unterstreichen gefragt ist, muss man den Font wohl via Api bzw. ot4xb erzeugen.

Nochmal besten Dank fuer die Hinweise auf die externen Loesungen.

Gruss

Achim

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Mi, 16. Mai 2018 22:41

Achim,

du bist ja nicht der einzigste der solche Function benutzt ... :roll:
auch wir anderen hätten es ja über die Jahr bemerken müssen und es gibt keine PDR dazu :!:
Statler hat geschrieben:
Mi, 16. Mai 2018 18:57
Mein Spooler basiert auf dem Xbase Preview Beispiel, Vorschau und Druck funktionieren seit Jahren einwandfrei, dort liegt kein Problem vor. User Werner hat das Problem ja ebenfalls bestaetigt.
zunächst mal sagtest du doch das du es angepasst hättest, also kann das KEINER von uns sagen was deine Version macht.

---

wenn man etwas in einen vorhandenen Code einbaut und es nicht so funktioniert wie erwartet dann schreibe ich ein Demo. wenn bei einem 3-Zeiler auch wieder "falsche" Ergebnisse raus kommen dann hat man was für Alaska gefunden.

---

Das im Help File vieles nicht steht ist doch klar wenn Xbase++ die Fähigkeiten nicht bereit stellt.
das war ja auch einer der Gründe warum ich eigene native Controls mache da ich dort alle Fähigkeiten ausnutzen kann.
wenn jemand nur den XbpFont kennt und im Bereich von 10 - 20 Points arbeitet wird also gar nichts bemerken ob es 1 Pixel/Twips daneben liegt.

da du nicht von paar Pixel/Twips spricht sondern 2stellige Unterschiede feststellst vermute ich das es etwas anderes sein muss ...

---

ich gehe noch mal ein Schritt weiter ... nicht alles was Xbase++ uns anbietet existiert in Windows [-X

ein Presspace kennt Windows NICHT. Windows kennt Device (Gerät) und Device Contexts (DC) in den ich "male"
unter Xbase++ kann ich ein XbpPresspace() mit einem Device verknüpfen was mit einem Micro-Presspace NICHT geht :!:

deshalb auch meine mehrfach gestellte Frage ob jemand durchschaut warum Alaska beide im Preview Sample verwendet werden :shock:

Statler hat geschrieben:Was ist, wen Pablo irgenwann keinen Bock mehr hat und die Sache unter Xbase 3.0 nicht mehr laeuft ?
ot4xb ist Open Source d.h. du kannst Änderungen selbst vornehmen.

wie Xbase++ basiert alles auf Windows API und ot4xb stellt in der Richtung offensichtlich mehr bereit als Xbase++

p.s.
bis die v3.x raus kommt könnte das uns bekannte Windows verschwunden sein. ob dann 32bit Apps noch voll unterstützt werden wird sich dann zeigen. schon heute bekommt man kaum mehr ein Mainboard mit 32bit UEFI um ein 32bit OS zu installieren und M$ ist ja am "ausmisten" der CORE Version die dann auch auf ARM CPU (mit 32bit Emulation)
läuft.
gruss by OHR
Jimmy

Statler
UDF-Programmierer
UDF-Programmierer
Beiträge: 87
Registriert: Di, 22. Jan 2008 9:49
Wohnort: Aachen

Re: Breite einer Zeichenkette

Beitrag von Statler » Do, 17. Mai 2018 9:46

Hallo zusammen,

das Problem ist gefunden.

2009: www.xbaseforum.de/viewtopic.php?f=23&t=3805&start=50

Das Preview Beispiel hat wohl einen kleinen Bug. Am Ende der Create Methode sollte folgendes stehen, danach wird richtig gerechnet. Die Reihenfolge spielt anscheinend eine Rolle.

// Presentation Space mit Window Device Context verknuepfen
::oPresSpace:configure (::oView:drawingArea:winDevice ())
::oPresSpace:setFont( ::oFont )
::oPresSpace:setAttrArea( ::aAreaAttr )
::oPresSpace:setAttrString( ::aCharAttr )

Es funktioniert nun mit native Xbase ohne irgendwelche API-Zugriffe. Dieser Bug betrifft anscheinend nur die Groessenberechnung, die eigentliche Ausgabe ist unveraendert.

Gruss

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14530
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: Breite einer Zeichenkette

Beitrag von Martin Altmann » Do, 17. Mai 2018 9:59

:lol: Dann ist klar, dass ich Dein Problem nicht nachvollziehen konnte. Ist schon zu lange her.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11451
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Breite einer Zeichenkette

Beitrag von AUGE_OHR » Do, 17. Mai 2018 14:29

Statler hat geschrieben:
Do, 17. Mai 2018 9:46
2009: www.xbaseforum.de/viewtopic.php?f=23&t=3805&start=50
klar das dass Demo dann bei mir läuft da ich es vor 9 Jahren geändert hatte
Statler hat geschrieben:Es funktioniert nun mit native Xbase ohne irgendwelche API-Zugriffe.
API heisst nicht nur irgendwelche DLL Calls sondern das Verständniss von Windows was Grundlage von Xbase++ ist.
gruss by OHR
Jimmy

Antworten