GDI+

[Jan]

Michael,

jetzt bin ich irgendwie irritiert. Was war denn die Knackpunktfrage? Zu einer Erweiterung auf GDI+ hatte ich jedenfalls Ja gesagt.

Jimmy,

wir hatten Michael ohne jede Themenvorgabe als Sprecher eingeladen. Ansich vergeben wir keine Themen bei Anfragen (wobei wir meist eher selten Anfragen, hier kam das, weil das Treffen direkt in seiner Nähe stattfindet). Ich persönlich bin der Meinung, wenn wir Themen vorgeben, dann schränken wir die Vielfalt ein. Vorgaben an alle Sprecher gibt es aber. Wie Praxisbezug, keine Werbeveranstaltung, Scripte und Code für die Teilnehmer.

Jan

[Tom]

Hallo, Michael.

Ich habe Deine Knackpunktfragen (noch) nicht beantwortet, weil ich mir der Konsequenzen nicht ganz bewusst bin. Wie ich eingangs schrieb - mir geht es ja in erster Linie um das extrem schwache Rendering der Standard-GRA-Funktionen. Es ist im Prinzip nicht möglich, beispielsweise einen Kreis zu malen, der tatsächlich rund aussieht. Das liegt in erster Linie am fehlenden Antialiasing. Mein Traum wäre also ein Satz von Funktionen, die die GRA-Funktionen ersetzen - verbunden mit der Möglichkeit, im Ownerdrawing-Kontext ersatzweise auf diese zuzugreifen, im Idealfall sogar durch eine einfache Ersetzung, also derlei:

Ist:

GraArc(oPS,{aStart},nRadius,,,,GRA_OUTLINEFILL)

Soll:

GraPlusArc(oPS,{aStart},nRadius,,,,GRA_OUTLINEFILL)

Das wäre mir auch etwas wert, weil ich von einfachen Zeichenfunktionen (Analoguhr u.ä.) bis zu komplexen selbstgebauten Controls (Kalender u.ä.) sehr intensiv mit solchen Funktionen arbeite. Die Ergebnisse sind anspruchsvoll, aber im Detail eben ein bisschen scheiße. Die WebUI dürfte hier auch kein sinnvoller Ersatz sein, da sie wesentliche Eigenschaften nicht enthält - und auf die Perspektive, dass sich das möglicherweise irgendwann ändert, kann ich mich nicht verlassen.

Hast Du Dir eigentlich mal das FoxPro-Projekt (VFPX) angeschaut?

[Koverhage]

und diese 2 Punkte sind ja auch nicht wirklich ein Problem.

- Traut Ihr Euch, etwas (=viel) Neues zu lernen?
- Traut Ihr Euch, etwas zu tun, was im ersten Moment gefährlich aussieht, weil Ihr es noch nicht versteht?

Wenn dazu eine Grundschulung angeboten wird.

[AUGE_OHR]

... im Idealfall sogar durch eine einfache Ersetzung, also derlei:

Ist:

GraArc(oPS,{aStart},nRadius,,,,GRA_OUTLINEFILL)

Soll:

GraPlusArc(oPS,{aStart},nRadius,,,,GRA_OUTLINEFILL)

JA JA JA ... genau so müsste es sein, aber ...

> Question : how to build "xbp_gdiplus" Wrapper for GDIplus.H FUNCTION Macro
> to use with Xbase++ Presspace ?
Pablo :
Build a gdi+ wrapper to paint into an hdc, paint into the pressspace in
the same way as with GDI ( LockHDC.... )

wenn ich verstehen würde wie das funktioniert ...

Die WebUI dürfte hier auch kein sinnvoller Ersatz sein, da sie wesentliche Eigenschaften nicht enthält - und auf die Perspektive, dass sich das möglicherweise irgendwann ändert, kann ich mich nicht verlassen.

OK ... es gibt zwar http://www.terrainformatica.com/htmlayo ... index.html

Code: Alles auswählen

EXTERN_C HPRESULT HLAPI HTMLiteRender 	( 	HTMLITE  	hLite,
		HDC  	hdc,
		INT  	x,
		INT  	y,
		INT  	sx,
		INT  	sy	 
	) 	

aber gerade die GDI+ Function zum "malen" sind in der HTMLayout SDK wohl (noch) nicht vorhanden.

[mikehoffmann]

Um es abzurunden:

Zwei Wünsche müssen wir unterscheiden.

1. "Es soll schnell gehen und ich möchte runde Kreise sehen."

Dafür müßte man die XbaseParts subclassen und WM_PAINT behandeln. Außerdem müsste man GDI+, Direct3D und Direct2D wrappen, um es direkt zu nutzen. Das Ergebnis wäre objektorientiert und würde Pseudo-Objekte (mit Handles) und COM-Objekte umfassen. Auch Strukturen wären dabei. Menschenmachbar in endlicher Zeit. Mögliches Problem: Wenn viele grafische Elemente zu pinseln wären, dann bremsen die Wrapper-Umsetzungen. Gegenmaßnahme: Pinseln in Bitmap und diese dann beim WM_PAINT anzeigen. Dieser Umweg wird aber bei Direct3D und Direct2D wahrscheinlich nicht möglich sein, weil die wohl direkt auf die Hardware rauswollen, wann das Fensterlein gepinselt werden muss. Das ist alles natives API mit COM, das heißt OCX, .Net, C# sind hier mehr als flüssig.

2. "Ich will eine schnieke GUI und mich nicht um's API kümmern. Kann auch ein bißchen langsamer sein."
Sciter scheint das zu bieten. Das neue XbpHtml... Part scheint das zu wrappen. Blöde beim nativen Xbase-GUI ist natürlich wieder, dass das alles in einem separaten Thread läuft. Keine Ahnung, wie gut dann die Integration mit DOM ist, um an die eigentlichen Daten ranzukommen. Ich stelle es mir schwer vor, mit den ganzen Events klarzukommen, die im GUI-Thread rumschwirren. Aber, so genau habe ich es mir nicht angesehen, könnte auch funktionieren. Ich würde mir an Eurer Stelle nur überlegen, wenn Ihr die Xbase-Part-Welt damit eigentlich schon verlasst, ob man nicht die Xbase GUI komplett auf Seite lässt und es so macht, wie es eigentlich üblich ist: GUI im Primary Thread abwicklen. Sciter erscheint mir hochinteressant. Wenn ich mal Zeit habe, werde ich damit experimentieren, dies allerdings im Cockpit GUI. Im Moment genieße ich hardwarenahes C++. Schreckliches Zeug. Aber schnell wie die wilde Luzie.

Noch zu den Schulungen, weil Klaus danach gefragt hat. Schulungen sind sehr zeitaufwändig in der Vorbereitung, wenn man was Gescheites abliefern will. Das geht also nur, wenn genügend Leute bereit sind, da auch rein zu investieren. Aus der Anzahl der Antworten würde ich schließen, dass hier kein Bedarf besteht. Hier ist auch das Problem mit meinem Vortrag. Einen Vortrag nur um seiner selbst willen zu halten, kann ich mir aus Zeitgründen nicht erlauben. In meinem zweiten Betätigungsfeld haben sich gerade jede Menge Leute gemeldet, die meine Dienste für eine Ausbildung gerne in Anspruch nehmen würden.

Viele Grüße
Michael

[Jan]

Michael,

ich kann verstehen, wenn Du zeitliche Bedenken hast. Als Selbständiger muß man immer darauf achten, daß das Geld rein kommt. Das man sich auf die Aktivitäten konzentrieren muß, die die Unkosten decken.

Ich kann Dir aber versichern, das ein *guter* Vortrag auf dem Forentreffen sehr oft mehr gebracht hat als man vorab denken konnte. Ich erinnere da nur an den Vortrag von Joachim auf dem Forentrefffen in Stuttgart. Vorher gab es mäßiges Interesse an ADS, aber danach ging eine stürmische Diskussion mit begeisterten Fragen los. Und mehrere Teilnehmer haben nur wegen dieser hervorragenden Session mit vielen praktischen Ausführungen den ADS gekauft (der um einiges teurer sein dürfte als Dein Cockpit, schätze ich).

Abgesehen davon: Wir reden hier in diesem Thread natürlich über GDI+, was ein sehr interessantes Thema für eine Session sein kann. Aber man kann ja auch über andere, ebenfalls durchaus praktische Dinge, sprechen.

Und letztendlich gibt kein Sprecher eine Session nur deswegen, weil er damit Geld rein bekommen möchte. Sondern wegen der Gemeinschaft. Der Freude an dem Thema. Um sich zu vernetzen. Weil er seine Kenntnisse vermitteln möchte. Mancher sicher auch um sich einen Namen zu machen oder seine Kompetenz zu zeigen. Und teilweise kommen da sicher auch Aufträge bei zustande, wegen des Produktes oder der Kompetenz. Aber es ist ein Forentreffen und keine Verkaufsveranstaltung. Das sollte immer im Vordergrund stehen.

Jan

[AUGE_OHR]

1. "Es soll schnell gehen und ich möchte runde Kreise sehen."

Mögliches Problem: Wenn viele grafische Elemente zu pinseln wären, dann bremsen die Wrapper-Umsetzungen.

... als Beispiel die Xbase++ ActiveX Umsetzung.
Lösung ( wenn man keine Events benötigt z.b. füllen eines Excel Sheed ) : DispHPR.DLL (in ot4xb enthalten )

es kommt auch auf den Wrapper an

2. "Ich will eine schnieke GUI und mich nicht um's API kümmern. Kann auch ein bißchen langsamer sein."

Xbase++ hat ja nun nicht gerade viele Controls als XbPart.
mein native Listview Control ist so schnell wie der Windows Explorer ... ist das schnell ?

da Xbase++ dieses Control gar nicht hat ist ein reeller Vergleich nicht möglich.
wenn man es als "Browse" mit 100000 Records einer DBF oder einen so grossem SQL Resultset benutzen will wird er genau so langsam wie der Windows Explorer.
Der Windows Explorer hat jedoch einen Vorteil : er arbeitet mit echten Threads

Aus der Anzahl der Antworten würde ich schließen, dass hier kein Bedarf besteht.

Die meisten User lesen nur ... oder verstehen nur "chinesisch"

ich denke das viele User, die vielleicht von Cl*pper kommen, nicht viel mit Windows API anfangen können ... deshalb hat man Xbase++ gewählt und nicht harbour

Hier ist auch das Problem mit meinem Vortrag. Einen Vortrag nur um seiner selbst willen zu halten, kann ich mir aus Zeitgründen nicht erlauben. In meinem zweiten Betätigungsfeld haben sich gerade jede Menge Leute gemeldet, die meine Dienste für eine Ausbildung gerne in Anspruch nehmen würden.

Der Vortrag wäre ja zum User Treffen und das werden doch mehr werden.

Es geht bei den Treffen ja um Erfahrungsaustausch also ein geben und nehmen.
klar profitieren die User mehr vom Wissen des Referenten aber oft ergibt sich durch den User eine neue Perspektive für das eigene Produkt.

ein User geht zu solch einen Treffen oft weil er sich Antworten auf seinen Fragen erhofft ... der Level reicht von Anfänger bis zum Hersteller.

am liebsten sind dem User Antworten "schwarz auf weiss" in Form von Demo Source Code mit dem er rumspielen kann.
wie Tom sagte wäre es optimal wenn man nur

Code: Alles auswählen

#xtranslate GraArc => GraPlusArc

in seinen Source Code einfügen müsste und eine LIB/DLL den Kram erledigt.

p.s. das was wir hier besprechen ist eigentlich unser Wunsch an Alaska dem Hersteller von Xbase++

[Jan]

p.s. das was wir hier besprechen ist eigentlich unser Wunsch an Alaska dem Hersteller von Xbase++

... und deswegen steht dieser Punkt auch auf meiner langen Frageliste für Alaska. Ich werde die drei kommenden Monat treffen.

Jan

[brandelh]

Was ich bräuchte wären bessere Grafunktionen (mit Schrift) um PNG, BMP oder JPEG Bilddateien zu erstellen.
Was ich nicht brauche ist eine neue IDE, ich knabbere schon an der von Xbase++ 2.0

[mikehoffmann]

Kinners, Ihr macht mich wirklich fertig.

Hier nochmal meine Knackpunktfragen:
- Traut Ihr Euch, etwas (=viel) Neues zu lernen?
- Traut Ihr Euch, etwas zu tun, was im ersten Moment gefährlich aussieht, weil Ihr es noch nicht versteht?
- Könnt Ihr damit leben, dass Eure Tabellenfelder aus dem GUI-Thread nicht direkt zugänglich sind?
- Seid Ihr noch dabei, wenn es das nicht umsonst gibt?

Dazu Eure Antworten in gekürzter Form:
„Ich habe Deine Knackpunktfragen (noch) nicht beantwortet, weil ich mir der Konsequenzen nicht ganz bewusst bin...“
„und diese 2 Punkte sind ja auch nicht wirklich ein Problem. ... Wenn dazu eine Grundschulung angeboten wird.
„Und letztendlich gibt kein Sprecher eine Session nur deswegen, weil er damit Geld rein bekommen möchte. Sondern wegen der Gemeinschaft. Der Freude an dem Thema. Um sich zu vernetzen. Weil er seine Kenntnisse vermitteln möchte.“
„p.s. das was wir hier besprechen ist eigentlich unser Wunsch an Alaska dem Hersteller von Xbase++“
„... und deswegen steht dieser Punkt auch auf meiner langen Frageliste für Alaska. Ich werde die drei kommenden Monat treffen.“
„Was ich bräuchte wären bessere Grafunktionen (mit Schrift) um PNG, BMP oder JPEG Bilddateien zu erstellen.
Was ich nicht brauche ist eine neue IDE, ich knabbere schon an der von Xbase++ 2.0.“

So wird das nie was werden, denn irgendwie wollt ihr nicht wirklich oder nicht stark genug. Dass das geht, wenn man diese ganzen Bedenken auf Seite läßt und jede Frage mit "Ja, ich will, und zwar unbedingt!" beantwortet, zeige ich Euch mit einem Beispiel zu Huberts Wunsch nach "besseren Grafikfunktionen (mit Schrift) um PNG, BMP oder JPEG Bilddateien zu erstellen."
Die Aufgabe war, aus Produktfotos, Grafiken, Autocad-Zeichnungen, bmps, jpgs, ... alles was Ihr Euch vorstellen könnt, automatisiert s/w-Bitmap-Files zu erzeugen, die mit einem Thermotransferdrucker auf Produktetiketten gebannt werden. Außerdem sollten die Produktbeschreibungen in vier Sprachen darauf untergebracht werden und noch dazu die ganze CE-Deklarationsschose mit drauf. Um das einfach hinzukriegen, habe ich mir eine kleine Klasse namens BWImage (Black-White-Image) gebastelt, die alle Methoden exportiert, um Texte zu schreiben, Ellipsen zu malen, EAN-Codes zu pinseln, ... und eben die Bildgrafiken nach s/w umzuwandeln und in einer brauchbaren Qualität zu Papier zu bringen. Der letzte Teil war der schwierigste. Das fertige Bild wird dann in ein Bitmapfile rausgeschrieben. Fertig. Die Klasse hat mich etwa drei Tage meines Lebens gekostet. Ich habe den Source aus UEStudio mit Syntax-Highlighting gedruckt, dass er auch ansprechend daherkommt. Was da drin braun aussieht, ist zumeist Windows-API-Zeugs, was Ihr in der guten alten MSDN oder online bei Onkel Bill nachgoogeln könnt. Zum geringsten Teil sind es auch Cockpit-Helferlein, die sich wohl selber erklären.
Der Code war nie zur Veröffentlichung gedacht, also bitte nicht über Unschönheiten nörgeln.
Ich verwende hier ausschließlich die GDI-Funktionen von Windows. GDI-Plus könnte man nach Adpation genauso locker flockig verwenden. Zuerst wären da aber vier Fragen zu klären, die uns wieder zum Beginn dieses Postings bringen...

Ein schönes Wochenende
Michael

[georg]

Hallo, Michael -


für mich ist Xbase++ aktuell eher Hobby und schneller Notnagel, wenn die IT mal wieder alleine zu Aufwandschätzen ein Jahr braucht.

Ich bin grundsätzlich daran interessiert, Neues zu lernen, denn sonst vergisst man zuviel.
Vor gefährlichen Dingen auf dem PC habe ich keine Angst, da gibt es einen Notaus-Schalter (ja, beim PC).
Was die Tabellenfelder angeht, vermute ich mal, dass Du auf XbpBrowse und Konsorten anspielst? Jein, das käme drauf an. Aber Umwege führen manchmal durch interessante Landschaften.
Gute Arbeit verdient guten Lohn, das ist (und war) kein Thema.

Wenn mich auch die Geschwindigkeit und "Schönheit" nicht so drückt wie meine Kollegen hier, bin ich doch gerne dabei, was Neues zu lernen. Also bekommst Du mal ein erstes Statement in dieser Richtung.

[Koverhage]

von mir 4 JA

[AUGE_OHR]

Kinners, Ihr macht mich wirklich fertig.

dabei war die Frage von Tom doch ganz simple ...

Hier nochmal meine Knackpunktfragen:
- Traut Ihr Euch, etwas (=viel) Neues zu lernen?
- Traut Ihr Euch, etwas zu tun, was im ersten Moment gefährlich aussieht, weil Ihr es noch nicht versteht?
- Könnt Ihr damit leben, dass Eure Tabellenfelder aus dem GUI-Thread nicht direkt zugänglich sind?
- Seid Ihr noch dabei, wenn es das nicht umsonst gibt?

es ergibt sich immer eine Diskrepanz zwischen den Programmierer und dem Kunden (Xbase++ User) ...

Die Frage ist aus Xbase++ User Sicht :

"was" soll ich neu lernen ... Cockpit Syntax Style ? ( siehe Cockpit Demos )
was ist an eine GDI+ Function gefährlich ?
zum "malen" mit GDI+ benötige ich keine DBF
die Frage nach dem Preis verhält sich zur Qualität des Produkt.

Frage : gibt es eine aktuelle Demo von Cockpit ? ( Files sind von 2006 )

ich habe mir von http://www.xcockpit.com/download.html die Demos / Runtime / LIB geholt und bekomme die nicht zum laufen ?
btw. die enthaltenen Xbase++ Runtime DLL sind v1.9.331

---

es ging bei Tom um die Frage : "wie" kann man GDI+ mit Xbase++ Ownerdraw ( Customdraw) einsetzten.

wir wissen nun das die GDI+ FUNCTION MACROs in der GDIplus.H stecken und wir einen Xbase++ Wrapper benötigen der sich auch um die Parameter kümmert.
die GDI+ Function senden auch keinen Notify Event und die Rückgabe ist meistens .T. / .F. ( <> 0 )

da Tom nach Ownerdraw fragt spielt dann nicht die WM_PAINT Message eine Rolle sondern WM_DRAWITEM was ein Xbase++ User gerne in seinem o:DrawItem Codeblock Slot "selbst" machen möchte.

auch ist der hDC nicht "einfach" @USER32:GetDC(0) sondern von der DRAWITEMSTRUCT des Control.
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Problem : DRAWITEMSTRUCT Member hDC ist zwar im GUI Thread "im Zugriff" aber wenn ich es in aINFO als Parameter an Custromdraw übergebe kann ich es nicht im Xbase++ Thread "nutzen" ?!

[mikehoffmann]

Hallo Klaus, Georg und Jimmy,
vielen Dank für Eure Rückmeldungen. Aus der insgesamt niedrigen Resonanz schließe ich, dass nicht wirklich ein Bedarf besteht, die Möglichkeiten des Xbase GUIs mit einem 3P-Tool zu erweitern. Eigentlich schade, denn hier hätte es ein kleines Gebiet gegeben, indem man schnell die Grundlage zur Selbsthilfe hätte schaffen können. Mich wundert es sowieso, dass Ihr das noch nicht hinbekommen habt. ot4xb sollte eigentlich alle erforderlichen Werkzeuge anbieten, um das Thema mit DllCall abzuhandeln. Vielleicht setzt das aber auch zuviel API Wissen voraus, würde ich aus Jimmys Äußerungen schließen.
Wir sehen uns in Holland. Bis denne.
Michael

[AUGE_OHR]

vielen Dank für Eure Rückmeldungen. Aus der insgesamt niedrigen Resonanz schließe ich, dass nicht wirklich ein Bedarf besteht, die Möglichkeiten des Xbase GUIs mit einem 3P-Tool zu erweitern.

irgendwie sieht das aus deiner Sicht ... klar wollen wir aber wir wollen ja nicht unseren Source Code ändern und Cockpit Syntax verwenden.

Vielleicht setzt das aber auch zuviel API Wissen voraus, würde ich aus Jimmys Äußerungen schließen.

nun ich habe eine ganze Reihe von funktionsfähigen native Controls gemacht die ich "free" in Form der DXE LIB zu Verfügung stelle ... so falsch können meine Äusserungen wohl nicht sein.

btw. wenn ich da richtig sehe hat sich in der Cockpit LIB seit 2006 nichts getan ...

IMHO Pablos und du schreiben eine Art von Code wie es ein "normaler" Xbase++ User nicht tut/kann.
Ihr beide "denkt" dabei an C , was im Grunde richtig ist, aber dann könnte ich auch gleich auf pure C umsteigen ...

[AUGE_OHR]

ein Xbase++ GDIplus Demo ...

TIF_test.zip

need ot4xb

(1.02 KiB) 276-mal heruntergeladen