Inoffizielles deutsches Xbase-Forum

Hallo,
Ich verwende Huberts Druckerklasse und drucke entsprechende Formulare mit Memotexten. Innerhalb der Texte währe es schön, wenn man die Schriftarten wechseln könnte. Wie könnte man das, wenn überhaupt möglich, eventuell realisieren?

Eine Möglichkeit wäre rtf Texte zu speichern und dann zu drucken. Müsste dazu aber einen rtf Editor benutzen (siehe Xbase++\source\samples\activex\editor) und Huberts Klasse müsste rtf Texte drucken können.
Oder man nimmt TXControl, das kostet aber.

den Ordner "source" habe ich gar nicht ... Ist auch nicht auf der Orginal CD von Alaska, noch kann ich es von Alaska runterladen ...

Hallo Wolfgang !

den Ordner "source" habe ich gar nicht ...

Solltest du aber haben:
C:\Users\DEINLOGINNAME\Documents\Xbase++\source\samples\activex\editor
Habe ich bei meiner alten Installation von Xbase++ (1037) auch.

Ich liebe das Tool EveryThing; das findet wirklich alles blitzschnell

Hier gibt es den (Prof. Version)
C:\ALASKA\XPPW32\SOURCE\samples\activex\editor

Naja, das Problem ist ja nicht, die Texte im Editor zu formatieren. Sondern die auch so auszudrucken das die Schrift-Formatierungen ausgeführt werden. Da muß man dann ja die Ausgabe exakt positionieren, ab wo welcher Text wie formatiert ausgegeben werden soll. Wenn die gesamte Zeile eine Formatierung haben soll dann geht das ja noch recht einfach. Aber mitten in der Zeile von Normal auf Fett oder sonstwie zu wechseln, das ist schon tricky.

Jan

Wolfgang,

Wolfgang_B hat geschrieben: ↑Di, 26. Apr 2022 14:22den Ordner "source" habe ich gar nicht ... Ist auch nicht auf der Orginal CD von Alaska, noch kann ich es von Alaska runterladen ...

Klar hast Du den Ordner. Der gehört ja zur Installation dazu. Da stehen die Samples drin, fertige Musterprojekte, und die Systemcodes wie errorsys, appsys, etc. Schau mal in Deinen Domumente-Ordner unter Xbase++.

Der Pfad zum RTF-Editor ist C:\Users\[Benutzername]\Documents\Xbase++\source\samples\activex\editor

Jan

@Jan -> hab ich nicht! Der Ordner c:\user\username\dokuments ist leer. Wie gesagt, das Verzeichnis ...\source ist auch nicht auf der CD ..


Auf der CD 1.9 ist der Ordner noch drauf .. Ich hab den jetzt mal unter Xpp20 reinkopiert. Wird sich nicht allzuviel geändert haben ..

@HaPe -> Das Tool EveryThing ist genial

Die Berechnung der Schriftbreite hängt sowohl von der Schriftart, als auch der Ausprägung ab, FETT macht eine Schrift breiter,
das kann man nicht einfach so in dieser einfachen Funktion nachrüsten.
Ich habe da was im Kopf von wegen BB-Code [ B ] und [ /B ] für Fett ein und aus, aber das war wohl in einer Anzeige mit HTML Code Umsetzung.

Aus meiner Sicht müsste man die eine PrintMemo() Zeile aufteilen nach Einzelzeilen (dafür gibt es ja eine Methode in meiner Druckerklasse),
für jedes Schrift-Text-Stückchen müsste die Breite berechnet werden, die Leerstellen berechnet und dann ausgegeben werden.
Die grundsätzliche Breitenberechnung kann man aus der PrintMemo() Methode heraussuchen, aber die zusätzlich nötigen Infos im Text sowie die Breite der Schriften macht es viel komplexer.

Hallo Hubert,
dann laß ich das lieber
Danke für die Anwort.

Vielleicht wäre es doch mal an der Zeit, einen professionellen Formulargenerator anzuschaffen, Wolfgang?

hi Tom,

Huber hat mit seiner Drucker CLASS ein Werk "geschaffen" was er kostenlos der Community zur Verfügung stellt.
mittels des Source-Code von Hubert kann ein User "lernen" wie und was man mit Xbase++ machen kann.

"Build not bought"

p.s. ich würde mir "mehr" solcher Beiträge im Forum wünschen

Hallo, Jimmy.

Huber hat mit seiner Drucker CLASS ein Werk "geschaffen" was er kostenlos der Community zur Verfügung stellt.
mittels des Source-Code von Hubert kann ein User "lernen" wie und was man mit Xbase++ machen kann.

Das ist ohne Zweifel so und ich schätze das sehr - oder die viele Arbeit, die Du in die DXE investierst, und die für viele sehr hilf- und lehrreich ist.

Aber es zeigt auch die Grenzen dessen, was man als Solokünstler nebenbei schaffen kann. Mein Rat war nicht: Klopf doch Huberts Zeug in die Tonne. Aber das ist eine Klasse, die das Drucken vereinfacht, eigentlich überhaupt erst auf halbwegs brauchbarem Niveau ermöglicht. Sie bietet den Zugang zu etwas, aber im Vergleich mit professionellen Auswertungs- und Reportingtools ist das dennoch wie eine quietschende Schubkarre neben einem Containerschiff. Wenn Kunden nach Formatierungsmöglichkeiten fragen, und wenn es um Formulargestaltung geht, ist der Gedanke, sich ein professionelles Reportingtool anzuschaffen, naheliegend. Man spart Arbeit und Zeit und bietet zugleich einen Mehrwert, den man zu Fuß niemals auch nur annähernd generieren kann. Das Geld, das das kostet, steht in keinem Verhältnis zu den Kosten der Minischritte, mit denen man zu Fuß klägliche Ergebnisse erzeugt.

"Build not bought"

Das ist Dein Weg. Geh ihn weiter, das ist schließlich auch Deine Entscheidung. Aber jede Anregung, sich mal auf einem unfassbar großen Markt umzuschauen, um auf diese Weise enorm viel Zeit und Energie zu sparen und zugleich enormen Mehrwert zu schaffen, zu torpedieren, weil es Deiner ganz persönlichen Strategieentscheidung widerspricht, ist nicht besonders hilfreich, und realistisch ist dieser Ansatz auch nicht, wenn es um Märkte und Competition geht. Wir haben alle Kunden, die auf Funktionalitäten warten, die zeitgemäß und leistungsstark sind. Wenn wir jedes Mal nicht nur das Rad neu erfinden, sondern sogar die Materialien, aus denen es gemacht werden könnte, verplempern wir Zeit, die wir alle nicht haben. Und auch der Lerneffekt ist irgendwann keine Rechtfertigung für diese Vorgehensweise mehr.

Allgemein gesprochen. Ich kenne Wolfgangs konkrete Anforderungen nicht, seine Kundenstruktur und deren Erwartungen.

Und noch eine Ergänzung:

Es gibt ja Communities da draußen, da legst Du Dir die Karten. Wenn man z.B. mit JS-Frameworks im Frontend-Bereich unterwegs ist, bleibt kein Auge trocken. Du willst es - Du kriegst es. GitHub und andere sind unerschöpfliche Quellen für alle denkbaren Lösungen und Lösungsansätze. Es gibt nichts, woran nicht schon irgendwer gearbeitet hat. Und alles Open Source und schlimmstenfalls mit MIT-Lizenzen - großartig.
Aber leider für uns überwiegend unbrauchbar. Unsere Community ist im Verhältnis dazu so groß wie ein Ameisenhaufen im Vergleich zur Größe der U.S. of A. Wir haben eine Handvoll Gurus, die auch von irgendwas leben wollen, so gut wie keine Open Source-Projekte - und die dann auch nur im Kernbereich. Aber das sind One-Man-Shows, und das wiederum geht mit dem Risiko einher, dass man die Quelle irgendwann verliert. Was ja auch schon mehrfach geschehen ist - ich denke an TopDown oder FastReport oder RMChart. Selbst für quellenoffene Projekte finden sich keine Entwickler, die Zeit und Spaß daran haben, sie weiterzuführen. Wir sind einfach zu wenige. Und komm mir jetzt nicht mit (x)Harbour oder so - da sieht das nämlich ganz genauso aus.

Das ergänzend zum Zeit-Argument. Viele (ich nehme an: die meisten) von uns haben echte Firmen, die echtes Geld verdienen müssen, um Gehälter und Miete zu zahlen, und auch wenn es einem zumindest Ehre verschaffen würde, wenn man jede Lösung Bit für Bit selbst stricken würde, bezahlt diese Ehre keine Miete und nicht ein einziges Gehalt. Und unterm Strich sind die Ergebnisse auch kaum verwert- oder gar vergleichbar, weil man das, woran z.B. Combit seit fast 30 Jahren mit einem Team arbeitet, alleine nebenher frühestens im Jahr 2300 fertig hätte.

hi Tom,

wir reden doch hier über das Forum und was man tun könnte um "mehr" User zu bekommen.
das Forum hat keinen Kommerziellen Hintergrund sondern soll eine Community sein.

wir sind doch "zum Spass" im Forum und nicht zu einer Geschäftlichen Besprechung.

---

ob die CLASS von Hubert einem "reicht" oder man "mehr" braucht hängt von jedem User ab.
sie ist aber ein Code-Beispiel "was" man mit Xbase++ machen kann.

ich denke nicht das Hubert damit L&L Konkurrenz machen will zumal er den Source-Code dazu liefert
leider gibt es wenig Beispiele an denen sich ein Xbase++ User orientieren kann, schade

wir sind doch "zum Spass" im Forum und nicht zu einer Geschäftlichen Besprechung.

Du hast eine sehr eigenwillige Vorstellung von Spaß, Jim.

Wir sind hier, um einander zu unterstützen, um gemeinsam zu arbeiten, um uns zu helfen, um Erfahrungen auszutauschen - und natürlich auch aus sozialen Gründen. Aber Xbase++ ist mein Arbeitswerkzeug, und ich habe diese Community seinerzeit initiiert, um vor allem die ersten vier Aspekte zu verwirklichen. Dass mit der Zeit auf diesem Weg Bekanntschaften und Freundschaften entstanden sind, ist ein hochwillkommener Kollateralschaden, aber nicht die Hauptsache.

Die Fragen, die hier gestellt werden, werden nicht zum Spaß gestellt. Da geht es um Geschäftsprozesse, und hin und wieder sogar um existentielle. Und gerade wenn es offenbar hakt, sind m.E. Tipps, die über den Tellerrand hinausreichen, mehr als angebracht.

AUGE_OHR hat geschrieben: ↑Do, 05. Mai 2022 10:30 ich denke nicht das Hubert damit L&L Konkurrenz machen will zumal er den Source-Code dazu liefert
leider gibt es wenig Beispiele an denen sich ein Xbase++ User orientieren kann, schade

Die Ursprünge meiner "Druckerklasse" stammen aus Clipper Zeiten, mit einem Nadeldrucker Formulare auszufüllen das war schon lustig.
Insbesondere wenn man als Entwickler einen anderen Drucker hat, als der Endanwender.
Hinzu kam, dass bei jedem neu gedruckten Formularsatz der obere Rand so um 1 mm anders war.

So habe ich Steuercodes in DBF gepackt und eine Druckerauswahl eingebaut.
Nun kam auch etwas wie ein Formulargenerator auf den Markt, aber den fand ich fürchterlich.
Ich musste ja nur fixe Zeilen drucken, FETT und normal war genug.

Dann kam VO und die Hoffnung endlich grafisch drucken zu können, toll.
Bis die Drucker von 300 dpi auf 600 dpi umgestellt wurden und meine Druckausgaben winzig links oben standen
Dass man die Druckausgabe von Text dpi abhängig macht, damit hatte ich nicht gerechnet.

Also schrieb ich meinen HBPrinter() (ja die ohne X ist für VO), die Report Generatoren waren besser geworden, aber ich musste immer noch keine Reports drucken.

Mit Xbase++ wurde vieles einfacher, aber nicht perfekt, denn die Ränder haben die Druckausgabe noch immer verschoben und wer druckt schon von unten nach oben ...

Ich sag immer, wenn meine Druckerklasse reicht, ist sie sehr flexibel und man kann fast alles drucken, aber an ein modernes L&L kommt sie nicht ran.

Für mich stellt sich das Problem nicht mehr, ich muss immer noch keine Reports drucken und entwickle auch nur noch für mich zur Arbeitserleichterung.

Jetzt muß ich mich doch nochmal zu dem "Ursprungsthema" melden. Ich wollte hier keine Grundsatzdiskussion über Vor- und Nachteile von Huberts Druckerklasse lostreten. Ich hatte ja eigentlich nur eine Frage gestellt. Hätte ja sein können, daß es u.U. theoretisch möglich gewesen sein könnte, einen Font innerhalb eines printmemo zu wechseln. Das das aber wahrscheinlich doch nicht möglich ist, damit habe ich schon gerechnet. Natürlich können professionelle Generatoren je nach Anforderungen besser passen, aber für meinen Zweck reicht Huberts Klasse völlig aus.

Vielleicht mal eine kurze Beschreibung meiner Anwendung in diesem Fall. Ich speichere Standardtexte für Briefe in Memotexten. In diesen Texten verwendet ich Tokens z.B. #MITGLNR#, #IBAN# , um bestimmte Daten beim Drucken einzutragen, hier Mitgliedsnummer, Bankverbindung o.Ä. Manchmal hätte der Kunden dann gerne (aber nicht zwingend!), daß z.B. die in diesem Fall die Mitgliedsnummer fett gedruckt wird. Um das geht es. Ist nicht lebenserhaltend, wäre aber schön gewesen. Geht eben nicht ... auch nicht so tragisch.

Ich betrachte das Thema mal als erledigt. Aber trotzdem ein großes Danke für die Anteilnahme

Hallo, Wolfgang.

Ich weiß nicht, wie Huberts Klasse druckt, aber wenn er dafür die GRA-Engine (GraSetAttr<>, GraCaptionStr usw.) verwendet, sollte im Prinzip auch bei Memos bzw. beim Textdruck etwas ähnliches wie bei den Formatted Labels (Textstatics) möglich sein, wo sehr einfache Tags (\b für fett, \i für kursiv, \u für unterstrichen) verwendet werden können, um eine statische Textcaption in einem Xbase++-Dialog mit einfachen Attributen anzuzeigen. Dafür müsste natürlich die Klasse etwas aufgebohrt werden. Das "Formatted Label" ist im Parts Pack No. 2 enthalten.

Ich nutze die Gra-Engine.

PrintMemo() erhält einen Fließtext und druckt diesen nach Wunsch linksbündig, rechtsbündig oder im Blocksatz aus.
Hierzu muss ich natürlich die Breite der Druckzeile ermitteln, den Text zeilenweise aufspalten und - bei Blocksatz - in den Blanks die Breite auffüttern, bis es passt.
Notfalls druckt die Methode auch über Seiten hinweg, was aber eine genaue Definition der fixen Seitenbestandteile erfordert.

Das kann die Funktion, für mehr müsste man eine "Definitionssprache" z.B. [ B ] ... [ /B ] einführen und die breitere Schrift des BOLD Fonts berücksichtigen.
Natürlich auch für Farbe, unterstreichen etc. ...

Das kann man machen, aber ich mache es nicht mehr

Huhu, Hubert.

Das kann man machen, aber ich mache es nicht mehr

Das kann ich gut verstehen.

Aber in der "Formatted Label"-Klasse wurde es bereits gemacht, deshalb mein Hinweis. Ich habe das z.B. als Vorlage benutzt, um im Rahmen des Browse-Ownerdrawings solche Attribute auch innerhalb von Browserzellen zu erlauben, sogar mehrzeilig und in Verbund mit anderen grafischen Elementen (vor allem Icons). Falls Deine Klasse also im Quellcode vorliegt und sich jemand damit beschäftigen will: Das ist der Weg, um mal die Mandalorianer zu zitieren.