Inoffizielles deutsches Xbase-Forum

Hallo Ramses,

Deiner Auflistung der dll stimme ich (größtenteils) zu. Edgar nutzt libharu zur Erstellung der pdf. Allerdings kenne ich die XppPdf3.dll nicht. Bist Du sicher, das die von Edgar mitgeliefert wird?

Es mag ja sein, das Edgar mit der hier im Thread schon angesprochenen neuen Version irgendwas geändert hat. Allerdings würde es mich wundern, wenn er sowohl QuickPdf als auch libharu verwenden würde. Warum zwei verschiedene Grundlagen?

Jan

Hallo Jan,

das könnte daran liegen, dass die LibHaru meines Wissens nicht weiterentwickelt wird / wurde

Weiterhin könnte er vielleicht Elemente aus der freien Version von QuickPDF nutzen - zur Umstellung oder als Ersatz

Hallo Jan

ja da bin ich sicher, in der Zip xpppdf41.zip ist diese quickpdf0721 alias xpppdf3 enthalten. In der vorgehenden Version xpppdf32.zip noch nicht. Wobei es sich eindeutig um die Vollversion der Quickpdf DLL handelt......

Das bringt mich auf eine Idee, mal die Vorversion(32) zu testen ....

Bin am Testen mit HbPrintPDF

Erfahrungen:
1.kein eigentliches Problem:
otx4b.ch hat dieselben def wie xclass bei DRIVE_REMOVABLE usw. Einfach in einer der .ch wegkommentieren
(ist kein Problem mit hbprint, ich habe aber otx4b vorher nicht gebraucht

2. Dies ist ein Problem:
QuickPDF: This trial license key will provide support until Juli 1, 2010
Wie komme ich zu einem zum Testen aktuellen License key? Dieses File habe ich aus dem soeben heruntergeleadenen quick_pdf_library.exe erhalten.

3. Was brauche ich zum späteren Produktivsetzen? Muss ich QuickPdf einfach kaufen?

Herbert,

zu Punkt 2.

Einfach QuickPdf kaufen, dann bekommst Du die Seriennummer.
Die trägst Du in Deinem Programm ein, die DLL bleibt gleich.

Wegen dem Trial key, könntest Du denen eine Mail schreiben.

Danke
Dachte, ich hätte was falsch gemacht.
Habe den QuickPDF-Leuten geschrieben.

Hi,

ich denke wenn du die QuickPDF deinstallierst (eventuell mit REGEDIT nach Resten suchen)
neu herunterlädst und installierst, wirst du bei der Installation einen neuen Test-Key erhalten.
In meiner Klasse muss dieser dann also Parameter übergeben werden.

Sobald du die Lizenz gekauft hast erhälst du einen unbegrenzten für die 7.xx Reihe.
Dieser wird dann statt dem Test-Key übergeben und alles ist gut.
Ich denke dass beim Test-Key einige Beschränkungen vorhanden sind (Banner, max. Seiten),
bin mir aber nicht sicher.

Danke
habe unter Computer/HKEY_CURRENT_USER/Software/Debenu den Baum unter Quick PDF löschen müssen.
Ich hasse Programme, die nicht sauber aufräumen, resp. Zeitbeschränkungen so plump kontrollieren.

Hat das Problem gelöst! Die ersten Test laufen bereits ganz gut.

@Herbert

darfst du für deine Programme ot4xb verwenden?

ramses hat geschrieben:@Herbert
darfst du für deine Programme ot4xb verwenden?

Hallo Ramses,

ich weiß nicht, ob ich den Kern deiner Frage treffe, aber die ot4xb ist eine freie Bibliothek von Pablo Botella ( www.xbwin.com )
Programme die auf andere DLL zugreifen müssen benötigen ob deren API Aufruffunktionen. So auch XppPDF und HBPrintPDF (für QuickPDF DLL).

Hallo Brandelh

entschuldigung, habe mich unklar ausgedrückt.
In meinen Auflagen steht: Werden Fremd/Zusatz-Dll's verwendet dürfen diese erst beim Ausführen der betreffenden Funktion(en) geladen werden.
ot4xb wie auch die xppPDF Class erfüllen diese Forderung nicht, diese müssen bereits beim Start der EXE-Datei vorhanden sein.
Deshalb muss ich auf diese verzichten und aus den Programmen entfernen.
Bringt zwar Riesenprobleme mit sich.
Bin jetzt am Testen mit der QuickPDF.
Geht soweit mit den DllCall() Funktionen recht gut, solange die DLL keinen Double-Wert zurückgibt.
Bis jetzt habe ich noch keinen Weg gefunden um Rückgabewerte der DLL im Double Format zurückbekommen,
z.B. von PageHeight
Hat dies schon jemand geschaft?

Hallo Ramses,

aktuell ist es direkt mit Xbase++ nicht möglich etwas anderes als ein LONG als Rückgabewert zu erhalten.

Ich schreibe mal an Pablo ob es möglich ist, die ot4xb erst nach Programmstart (also dynamisch) zu laden.
Meine Klasse lädt die QuickPDF.DLL erst zur Laufzeit beim ersten Aufruf der Funktion.

ramses hat geschrieben: In meinen Auflagen steht: Werden Fremd/Zusatz-Dll's verwendet dürfen diese erst beim Ausführen der betreffenden Funktion(en) geladen werden.
ot4xb wie auch die xppPDF Class erfüllen diese Forderung nicht, diese müssen bereits beim Start der EXE-Datei vorhanden sein.
Deshalb muss ich auf diese verzichten und aus den Programmen entfernen.

Für mich sind systemnahe Libs eindeutig dem Core des Xbase++ zuzuordnen (aus Kundensicht erst recht) und werden an dieselbe Stelle installiert. So weiss niemand ausser mir, dass diese dort eigentlich eine "fremde" Lib ist. Meine eigene Funktions-Lib ist aus Sicht des Xbase++ auch fremd und wird mitinstalliert.
Falls eine Lib wie Quickpdf hauptsächlich einer Sache dient, ok, dann passt deine Regel schon. Aber bei otx4xb doch eindeutig nicht.

Hallo zusammen

Ich habe zum Teil auch Mühe mit den Auflagen und deshalb mehrmal schon lange Gespräche mit der GL gehabt, jedoch muss ich der Auflage "unter uns" jedoch zum Teil recht geben. Wenn ich das ganze jetzt aus der Sicht unseres aktuellen WAA-Projekts betrachte bringen die Zusatz-Libs die nicht der Reglen entsprechen z.T. doch massive Probleme mit sich.
z.B. in einer Package DLL's unter WAA: wird die XPPPDF-Lib verwendet crasht der WAA-SRV beim entladen der Package-Dll, beim verwenden der ot4xb kann wohl die Package DLL entladen und neu geladen werden, nach dem neu laden der Package DLL führt der Aufruf von Funktionen der Lib z.B. der aufruf von fpQcall nur noch zu Fehlermeldungen "Daten-Struktur zerstört....", . Bei Funktionen / DLL's welche die erwähnten Regeln einhalten sind die erwähnten Probleme nicht vorhanden.

Für die ot4xb würde ich zwar die Bewilligung bekommen da der Source-Code für die in das System eingreifende resp. "Systemnahe" Lib vorhanden ist und damit bei einem evtl. kommenden Upgrade von xBase keine zwingende Abhängigkeit zum Author der DLL besteht. Das Problem beim ent- und neu laden der Package DLL im WAA-Server in welcher die ot4xb eingesetzt wird, wird jedoch nicht toleriert, damit ist sie auch "gestorben". (Da der WAA-SRV eine Ent- und Lade Funktion für Package-Dll's hat muss diese zwingend auch funktionieren.)

@brandelh
Danke.

@herbert
jede verwendet Datei muss mit Herkunft, Version, Speicherort, Funktion usw. genau bezeichnet werden, da geht "weiss niemand ausser mir" nicht mehr, ISO 9000 lässt grüssen

hi,

Die ot4xb von Pablo ist ja "FREE", aber Pablo macht auch "Fremdaufträge".

Wenn du nur "eine" Function aus der ot4xb benötigst, die für deine Zwecke "optimiert" wird,
kann du die bei Pablo erwerben (inclusive Source).

Anmerkung :
leider "benötigen" wir ja z.T. die "extra" Hilfe um die activeX / DLL mit Xbase++ anzusprechen

Ich "denke" wir sollten mal eine activeX Liste machen welche mit Xbase++ XbpActiveXControl() funktionieren und wo man noch einen "Zusatz" benötigt.
Wenn wir nun auch noch "fertige" kleine Demo´s hätten und die "gesammelt" an Alaska schicken ...

Hi,

ich habe bei Pablo nachgefragt. Es ist möglich die OT4XB.DLL dynamisch zu laden,
solange man dann aber auch die Aufrufe mit den #translate Anweisungen so umsetzt, dass
die ot4xb Funktionen in dynamischen Codeblocks liegen, sonst würde der Xbase++ Linker
"missing functions" melden:

Code: Alles auswählen

before the #include "ot4xb.ch" at the begining of your prg, combined with DllLoad("ot4xb.dll") will do the trick at least
to act as a delay load dll, may have sense if the component using ot4xb is optional and not always exist  

#xtranslate POKEDWORD([<params,...>])      =>   &("POKEDWORD")([<params>])
#xtranslate PEEKDWORD([<params,...>])      =>   &("PEEKDWORD")([<params>])
#xtranslate _XFREE([<params,...>])         =>   &("_XFREE")([<params>])
#xtranslate OT4XB([<params,...>])          =>   &("OT4XB")([<params>])
#xtranslate TLSSTACKPUSH([<params,...>])   =>   &("TLSSTACKPUSH")([<params>])
#xtranslate TLSSTACKTOP([<params,...>])    =>   &("TLSSTACKTOP")([<params>])
#xtranslate CPRINTF([<params,...>])        =>   &("CPRINTF")([<params>])
#xtranslate TLSSTACKPOP([<params,...>])    =>   &("TLSSTACKPOP")([<params>])
#xtranslate NLOADLIBRARY([<params,...>])   =>   &("NLOADLIBRARY")([<params>])
#xtranslate NFPCALL([<params,...>])        =>   &("NFPCALL")([<params>])
#xtranslate PEEKSTR([<params,...>])        =>   &("PEEKSTR")([<params>])
#xtranslate FPQCALL([<params,...>])        =>   &("FPQCALL")([<params>])
#xtranslate _XGRAB([<params,...>])         =>   &("_XGRAB")([<params>])
#xtranslate POKESTR([<params,...>])        =>   &("POKESTR")([<params>])

Also diese Befehle müssten vor dem Aufruf von #include "ot4xb.ch" stehen.
Dann müsste danach DllLoad("ot4xb.dll") die DLL dynamisch laden, aber ...

However unload ot4xb.dll will be BAD , so BAD

hier liegt wohl auch euer Problem mit der DLL ... die ot4xb darf aktuell nicht entladen werden !
Übrigens auch nicht die QuickPDF, solange die EXE läuft, sonst würde ein Speicherleck entstehen.
Wenn ich Pablo richtig verstanden habe will er in der DLL das unload verhindern und somit
das Problem entschärfen, wann das aber sein wird ... ?

Ein anderer Weg wäre eine Prof. Sub. bei Alaska mit technischem Support und
der Aufgabe dies für euch zu lösen. Ich erhielt damals eine Nachricht, aus der
man schließen kann, dass Alaska die Rückgabewerte und Parameter von DLLCALL()
verbessern will, sodass man eventuell auf die ot4xb verzichten könnte, aber
da ich ja mit der schon fertig bin und es für mich auch wunderbar funktioniert,
hatte ich kein Interesse an einer Verzögerung von Arktica

Hallo Herbert

danke für die Infos. Ich habe ein damit mit einer Package-DLL getestet. Das dynamische Laden funktioniert schon, nur kann danach keine Package DLL entladen und neu geladen werden. Nach dem neu laden der Package-DLL im Waa-SRV funktioneren die Calls der ot4xb Dll nicht mehr. --> Fehlermeldung: Internal Data Structure corrupted, Func. fpQcall, Errorcode 41.

Das Problem liegt vermutlich wie du geschrieben hast, daran dass die ot4xb nicht entladen werden darf.

Ich stecke komplett in der Sackgasse.

Könnte man im WaaSRV einfach nur die Ent.- und Ladefunktion sperren wäre das Problem beseitigt.....

Meine Prof. Sub. bei Alaska ist momentan abgelaufen, ich finde momentan sind zuwenige Neuerungen verfügbar/bekannt welche knapp 2000 Euro für eine Erneuerung rechtfertigen würden. Die Idee den Tech. Support mit dem Problem der Rückgabewerte der DllCall() zu beschäftigen ist aber gut. Ob die dann aber wirklich eine Lösung finden?? Resp. die Funktion so fertigstellen dass auch alle (Rückgabe)Möglichkeiten eines DLL-Call's unterstützt werden? Die 2000 Euro Frage ........

Grüsse Carlo

Hubert, nicht Herbert, will mich doch nicht mit Lorbeeren schmücken, die in den Süden Seutschlands gehören! =D>

Hallo Ramses,

es gäbe noch 2 Möglichkeiten:

1. Pablo direkt anmailen und fragen was es kostet genau die Funktionen nachzubauen, die du brauchst.
2. Einen Wrapper in einer hardwarenahen Sprache schreiben (lassen) (Delphi, C/C++, PowerBasic, etc.)
An diese Klasse Strukturen mit Daten übergeben wie sie Xbase++ bereitstellen kann und die Rückgabewerte als Parameter per Referenz übergeben.
F2BIN(), BIN2F(), @Stringparameter etc. nicht einfach, aber möglich.

Hi,

eine andere Möglichkeit wäre ein SERVER Programm zu erstellen, dem PDF Druckaufträge über Pipes, DBF-Datensätzen oder Dateien im Verzeichnis oder sonst wie übermittelt werden.
Ich meine ich hätte schon sowas gesehen, indem ein Task auf Postscript Dateien in einem Verzeichnis wartet. Wenn was kommt wird eine PDF-Datei erzeugt und die PS gelöscht.
Egal wie du die Daten bereitstellst, das Serverprogramm muss
1. schnell sein, d.h. im 1/10 Sekundentakt nach Aufträgen suchen und diese schnell erledigen.
2. Die Daten musst du so zur Verfügung stellen, dass das Serverprogramm ohne viel Arbeit die PDF unter dem vorgegebenen Namen und Verzeichnis erstellt.
3. Dieses Programm läuft solange der Server läuft ... ein echtes Problem wenn ihr bei einem ISP arbeitet, dann müsste es ein SERVICE sein.
4. Die OT4XB wird nicht entladen solange das Programm läuft.
5. Deine WEB-DLL muss warten bis die PDF fertig ist und diese weitergeben. Das könnte ein Zeitproblem erzeugen.

Hi Hubert

das wäre ein Lösungsweg, ich überlege mir zur Zeit einen anderen Weg der ohne Dir Abfragen auskommen würde:

Ein Serverprogramm das mit ASInet an einen Port gebunden ist, aus dem WAA-Task sende ich alle Angaben per TCP an diesen Port, das Server-Programm erstell dann das PDF-File und meldet dessen Fertigstellung per TCP zurück. Kommt diese z.B nicht innert 1-2 Sekunden kann der WAA-Task dem User eine Fehlermeldung anzeigen und nicht länger warten.

Bringt folgende Vorteile:
- Die ASinet10 DLL wird vom WAASRV auch verwendet, die benutzung sollte also problemlos sein.
- Die Taskverwaltung von WAA wird durch Zusatz DLL's nicht beeinflusst
- Die Package DLL werden kleiner
- In einem Sep. EXE Programm könnte ich ot4xb verwenden
- Die Druckausgabe/PDF wäre einach in ein eigenständiges Programm zu transferieren da meine Druckfunktion/Klasse ausschliesslich über Controlcodes gesteuert wird, und nur durch ASCII Strings angesprochen/gesteuert wird. ( z.b. chr(27)+"E010TEST" Druckt an der aktuellen Druckpos "TEST in Courier 10Cpi )
- Keine Belastung des Filesystems durch Dir Abfragen
- Keine Zugriffsprobleme auf unfertige PDF usw. da "Druckprogramm" die Fertigstellung zurückmeldet vor ein anderer Zugriff (Senden) erfolgt

Unklarheiten:
- Wie verhält sich die ASinet10 bei der Verwendung in einer Package-Dll unter WAA

Der WWW Server ist im Haus, allerdings ein Novell Server für den es kein WAAGate gibt, die Webanwendung läuft an einem anderen Port auf einem XP Rechner unter Apache usw.

Wie findest du diesen Lösungsansatz?

Hallo Ramses,

das kann ich so nicht beurteilen, allerdings hatte ich mit der ASINET und TCPIP Sockets
nicht die besten Erfahrungen gemacht, als ich einen massiven gleichzeitigen Zugriff provoziert habe.
Das kann natürlich auch an meinem Programm gelegen haben

Pablo hat übrigens geantwortet, ich stelle den englischen Text teilweise mit ein,
dann kann jeder meine Übersetzung prüfen

> > The do NOT have EXE programs, but WAA DLLs.
Not a problem to use ot4xb with WAA, I've a customer running it all the time
the trick was load a dummy package with only the _Register() function that
depens also on ot4xb and any other DLLs this will not be unloaded.
but the others can be loaded/unloaded without a trouble even linked with ot4xb.lib
also the QuickPfd.dll must be loaded here as it will produce a memory leak
when load/unload multiple times.

Pablo hat Kunden, die die ot4xb auch problemlos auf dem WAA benutzen.
Der Trick ist, eine kleines WAA-Package zu bilden, welches seinerseits
die ot4xb öffnet und nicht mehr schließt. Diese DLL darf nicht geschlossen werden,
braucht aber nichts zu tun außer die DLL zu initieren.
Hier sollte auch die QuickPDF geladen werden, um auch diese zu schützen.

But if required, I can provide several solutions to reduce the overheap of
the WAA aplication and avoid troubles.
Make a small unloadable ot4xb version can be a posibility, the trouble is
that the quickpdf.dll itself will consume memory if load/unload multiple
times, so maybe the best solution will be to isolate the qpdf stuff in a
separate process, can be a small c++ exe, and the C++ code inside the WAA app
can be a true C++ static lib with no DLL dependencies, so the WAA package
will spend minimal resources in the WAA process

Fall nötig könnte Pablo eine abgewandelte Version erstellen um die Abhängikeiten
zu minimieren, eventuell auch als eigene C++ DLL die im Waa läuft.

The only issue is that I will need to charge the working time, but will not be expensive.
Regards,
Pablo

>
dafür müsste er aber etwas verlangen, es wäre aber nicht teuer.
Wenn das eine Option für euch ist, wäre es sinnvoll direkt mit Pablo zu kommunizieren.

Hallo Hubert

danke für deine Bemühungen, das stimmt wenn eine Dll z.b. "Never_unload_me.dll" als erstes geladen wird, die in der _register() Funktion die beiden DLL's ot4xb und quickpdf läd treten die Probleme beim Ent- und Neuladen einer Package DLL nicht mehr auf.

Bis der Admin aus versehen die Dummy entlädt ..... Ich habe Freitag einen Termin mit dem Verantwortlichen, ich werde das Problem da thematisieren. Es mag ja für Alltagsanwendungen sinnvoll sein wenn keine Bedienungsmöglichkeit vorhanden ist welche das Programm aufhängt, aber bei einem Serverprogramm. Der Admin sollte ja wissen was er tut.
Der Unload Knopf im WAA müsste deaktivierbar sein, dann gäbe es meine Probleme nicht. Bei einem guten Indischen Nachtessen kam ich zur Überzeugung dass ein sep. Serverprogramm, wie ich's mir überlegt habe nicht zweckmässig ist, die ganze angelegenheit muss im WAA laufen. Ich schaue mal was die Verantwortlichen zur Dummy Lösung sagen.
Bitte danke auch Pablo für seine Ausführungen.

Hi,
habe noch eine recht simple Lösung gefunden die verhindert es zuverlässig dass DLL's, nach evtl. Package Ent- und Laden, nicht mehr korrekt funtionieren.

Die Package DLL's haben nicht nur eine _Register() Funktion die beim Start aufgerufen wird sonderen auch eine _DEregister() die beim manuellen Entladen aufgerufen wird. In letztere habe ich den Befehl Quit gesetzt. Dies Beendet den WAASRV beim Versuch eine DLL zu entladen sofort. Damit ist eine evtl. Fehlfunktion gar nicht mehr möglich.

Hallo zusammen

Der aktuelle Stand nach einigen Wochen Erfahrung des Kunden mit dem WAA Programm und den Erfahrungen sieht die Sache nun so aus:

- PDF Erstellen mit einer radikal gekürzten Fassung von HBPrinter mit QuickPDF läuft perfekt
- ot4xb darf ich für das Projekt verwenden
- die Probleme beim Unload konnten dank der _deregister Funktion beseitigt werden.

Ingesamt läuft die Anwendung eigentlich nun perfekt. Leider sind nun neue Aspekte aufgetaucht:

- Es müssen nun plözlich auch Dateien ge UPLoaded werden können (war ursprünglich nicht vorgesehen)
- WAA hat ein eklatantes Sicherheitsproblem, welches es für jedermann ermöglicht an die an die Kunden gesandten PDF Dokumente zu kommen.

Nach gründlichem Nachdenken und abwägen sind wir nun zum Schluss gekommen dass WAA für uns vorallem wegen des Sicherheitsaspekts der gedownloadeten Daten (PDF) und fehlender Upload Funktionen nicht mehr verwendet werden darf.

Ich überlege mir nun den Einsatz von XB2Net.

Was meint Ihr eine gute Entscheidung?

Hat schon jemand eine WAA App nach XB2Net portiert? Evt. mit einer Klasse um nicht alles umzuschreiben?

Gruss Carlo

Inoffizielles deutsches Xbase-Forum

XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class

Re: XPPpdf Class