Seite 1 von 1
suche ...
Verfasst: Di, 21. Feb 2012 4:32
von AUGE_OHR
wie suche ich nach
Re: suche ...
Verfasst: Di, 21. Feb 2012 11:50
von azzo
Hallo Jimmy,
versuche es mit Google und der Beschränkung auf die Seite
www.xbaseforum.de.
GetTextDimensions site:
http://www.xbaseforum.de
Wahrscheinlich gibt es keinen Treffer.
lg
Otto
Re: suche ...
Verfasst: Di, 21. Feb 2012 13:05
von brandelh
Schaue mal neben in den Erläuterungstext:
Suche nach Wörtern:
Setze ein + vor ein Wort, das gefunden werden muss und ein - vor ein Wort, das nicht gefunden werden darf. Verwende mehrere Wörter getrennt durch | innerhalb einer Klammer, wenn nur eines der Wörter gefunden werden muss. Benutze ein * als Platzhalter für teilweise Übereinstimmungen.
'sle' findet z.B. kein XbpSle(), denn Xbp
Sle es ist nur ein Teilbegriff.
'*sle' findet XbpSle(), denn () und - sind genauso wie Blanks Worttrenner
Re: suche ...
Verfasst: Di, 21. Feb 2012 15:32
von Herbert
Wie kommst du auf dieses Wort? Im API ist das nicht bekannt.
Re: suche ...
Verfasst: Do, 23. Feb 2012 1:26
von AUGE_OHR
Herbert hat geschrieben:Wie kommst du auf dieses Wort? Im API ist das nicht bekannt.
GetTextDimensions ist ein Artikel von Günter Beyes und es ging um GetTextExtentPoint32() vs. GraQueryTextBox().
genau zu sein habe ich die
gesucht und in der Alaska Newsgroup gefunden.
Re: Graphic printing
public.xbase++.generic
29. Juli 2005
ich hänge es hier mal als Attachment an
Re: suche ...
Verfasst: Do, 23. Feb 2012 7:40
von Herbert
Aha, danke.
Womit programmiert eigentlich Alaska? Doch auch mit C und entsprechenden API-Calls?
Falls diese Funktion intern beim Aufbau von Dialogen verwendet wird, wäre eine Optimierung der Gra-Funktionen zur Performance-Steigerung mehr als angebracht. Nicht erst mit Version 3.0, wenn dort dann überhaupt.
Re: suche ...
Verfasst: Do, 23. Feb 2012 8:17
von UliTs
Herbert hat geschrieben:Aha, danke.
Womit programmiert eigentlich Alaska? Doch auch mit C und entsprechenden API-Calls?
Falls diese Funktion intern beim Aufbau von Dialogen verwendet wird, wäre eine Optimierung der Gra-Funktionen zur Performance-Steigerung mehr als angebracht. Nicht erst mit Version 3.0, wenn dort dann überhaupt.
Soweit ich weiß, programmiert Alaska hauptsächlich in xBase (auch den Compiler!). Lediglich Schnittstellen, die in xBase nicht zu realisieren sind, der P-Code-Kernel und vereinzelte Optimierungen sind in C++ programmiert.
Uli
Re: suche ...
Verfasst: Do, 23. Feb 2012 11:03
von brandelh
Womit ein Compiler entwickelt wird, sagt nichts darüber aus, wie schnell die Anwendungen sind, die er erzeugt.
Xbase++ hat einige Eigenschaften, die der Geschwindigkeit entgegen stehen.
Die größte Bremse dürfte sein, dass Xbase++ Variablen benutzt, die alle hier möglichen Typen enthalten können.
Eine gewisse Optimierung liegt darin, dass sie versuchen Integer Werte zu erkennen und dann die Variable auch auf LONG zu setzen.
Aber dieser Komfort für den Programmierer bremst ungemein durch nötige interne Umwandlungen.
Einige APIs können so gar nicht direkt mit Xbase++ bedient werden (DOUBLE oder DWORD Rückgabewerte etc.).
Ebenso die Möglichkeit zur Laufzeit mal so eben aus einem Quellcode einen codeblock zu erstellen, das setzt
neben den flexiblen Variablen eben auch vorraus, dass der compiler selbst zumindest teilweise im runtimesystem hinterlegt ist.
Alles hat Vor- und Nachteile
Re: suche ...
Verfasst: Do, 23. Feb 2012 13:10
von UliTs
brandelh hat geschrieben:...Ebenso die Möglichkeit zur Laufzeit mal so eben aus einem Quellcode einen codeblock zu erstellen, das setzt
neben den flexiblen Variablen eben auch vorraus, dass der compiler selbst zumindest teilweise im runtimesystem hinterlegt ist.
Alles hat Vor- und Nachteile
Stimmt
Wobei ich vermute, dass der Compiler in jedem xBase-Programm indirekt durch die benötigten DLLs enthalten ist.
Ist es nicht so, dass die Codeblöcke zur Laufzeit übersetzt werden, bevor sie ausgeführt werden?
Hat jemand mal getestet, ob z.B.
Code: Alles auswählen
bBlock := {||12*12+10-123+12929}
FOR I = 1 TO 1000000
Eval( bBlock }
NEXT I
schneller ist, als
Code: Alles auswählen
FOR I = 1 TO 1000000
Eval( {||12*12+10-123+12929} }
NEXT I
Stimmt es, was ich schreibe, dann würde im zweiten Beispiel der Codeblock 1000000x übersetzt, während dies beim ersten Beispiel nur 1x geschehen müsste.
Natürlich würde in beiden Beispielen insgesamt 1000000x ein Codeblock ausgeführt
Uli
Re: suche ...
Verfasst: Do, 23. Feb 2012 13:24
von brandelh
Hi Uli,
deine beiden Codeblöcke oben werden zur Compilierzeit einmal übersetzt, denn der Compiler kann diesen direkt erkennen und compilieren.
Das kannst du schön prüfen, wenn du einen Fehler einbaust. Zur Laufzeit wird alles übersetzt, was mit Macros zu tun hat.
bBlock := {|| 'A'++ } gibt der Compiler direkt als Fehler aus
bBlock := &("{|| 'A'++ }") gibt erst zur Laufzeit einen Fehler
PS: es soll einen kleinen Geschwindigkeitsunterschied zwischen beiden Codeblock-Typen bestehen, warum habe ich aber vergessen.
Re: suche ...
Verfasst: Do, 23. Feb 2012 17:19
von UliTs
Hallo Hubert,
ja, Du hast Recht! Die Codeblöcke können und werden bereits zur Compilierzeit übersetzt!
So sind die beiden Beispiele besser und es wär interessant zu sehen, ob die Berechnung "gleich schnell" geschieht (das vermute ich):
Code: Alles auswählen
bBlock := {||12*12+10-123+12929}
FOR I = 1 TO 1000000
Eval( bBlock }
NEXT I
Code: Alles auswählen
bBlock :=&("{||12*12+10-123+12929}")
FOR I = 1 TO 1000000
Eval( bBlock }
NEXT I
Uli
Re: suche ...
Verfasst: Do, 23. Feb 2012 17:40
von brandelh
warum vermuten, wenn man testen kann
hier der code ...
Code: Alles auswählen
#include "XBP.CH"
proc main
local bBlock, nDauer1, nDauer2
set alternate to test.txt
set alternate on
?
? "Nicht vermuten, sondern testen ;-) "
?
? "direkt compilierter codeblock, start ",time()
nDauer1 := seconds()
bBlock := {||12*12+10-123+12929}
FOR I = 1 TO 1000000
Eval( bBlock )
NEXT I
nDauer1 := seconds() - nDauer1
? "Ende Test 1 ", time(), " Dauer: ", nDauer1, "Sekunden"
bBlock := NIL // sicher ist sicher
? "über string compilierter codeblock, start ",time()
nDauer2 := seconds()
bBlock :=&("{||12*12+10-123+12929}")
FOR I = 1 TO 1000000
Eval( bBlock )
NEXT I
nDauer2 := seconds() - nDauer2
? "Ende Test 2 ", time(), " Dauer: ", nDauer2, "Sekunden"
set alternate to
wait
return
und hier das Ergebnis ...
Code: Alles auswählen
Nicht vermuten, sondern testen ;-)
direkt compilierter codeblock, start 17:38:04
Ende Test 1 17:38:05 Dauer: 0,80 Sekunden
über string compilierter codeblock, start 17:38:05
Ende Test 2 17:38:06 Dauer: 1,50 Sekunden
Re: suche ...
Verfasst: Fr, 24. Feb 2012 1:25
von AUGE_OHR
danke euch für die Codeblock Performance Beispiele.
der Artikel von Günter Beyes bezog sich damals (2005) ja noch auf "drucken" wo die Performance nicht ganz so die Rolle spielt.
wenn man aber GraQueryTextBox() bei Ownerdraw verwendet um ein "wordbreak" zu simulieren "merkt" man schon einen Unterschied zur API GetTextExtentPoint32()
ganz schlimm wird es unter Xbase++ dann wenn man das ganze noch "moved" ... oder so was macht
Code: Alles auswählen
FOR i := 1 TO ::titleHeight
aColors[1] += ::gradientStep
aColors[2] += ::gradientStep
aColors[3] += ::gradientStep
GraSetColor( oPS, GraMakeRGBColor(aColors), XBPSYSCLR_TRANSPARENT )
GraBox( oPS, aStartPos, aEndPos, GRA_OUTLINEFILL, ::radius, ::radius )
aStartPos[2]++
aEndPos[2]--
NEXT
das geht wohl 1 mal aber nicht 100000 mal hintereinander ohne das es "flickert".
an dieser Stelle setzt übrigens Xoanon an in dessen Stil ich nun die Ownerdraw Sample orientiert habe welche ja nur "pure" Xbase++ und BAP enthalten "dürfen".
p.s. wann ist Einsendeschluss für den Devcon Teilnehmer Wettbewerb ?