in anderes Programm einhacken

**SvB**

Moin, ich verwende eine Warenwirtschaft, die in Delphi geschrieben ist. Der Hersteller bekommt es nicht hin, Fastreport 4 gegen Fastreport 5 auszutauschen, obwohl das kein großes Problem ist. Das Problem ist der altbekannte PDF-Export mit Bildern usw. der z.B. auf iOS nicht lesbar ist.
Jetzt habe ich mir überlegt, ob es möglich ist, mich in das Programm reinzuhacken und den Aufruf abzufangen und in meinem eigenen Programm mit FR5 den PDF-Export zu machen.
Geht so was grundsätzlich (reinhacken) und wie nennt man das? Würde mich da gerne etwas weiter informieren.

**himitsu**

Zitat:

Geht so was grundsätzlich

Joar... ginge schon.

Du müsstest FR5 in eine DLL packen, dir eventuell ein paar Wrapper bauen, für die Stellen, wo sich die API vom FR geändert hat.
Die DLL dann in das Programm einschleißen, "alle" zigtausenden Aufrufe finden und auf dei DLL umleiten, den Speichermanager und vorallem die RTTI haken, denn es ist Klassen eigentlich "unmöglich" über DLL-Grenzen hinweg benutzt zu werden und ...

Wenn du den Quellcode hättest, dann wäre es ganz einfach.
Und wenn das Programm gegen die FR-BPLs gelinkt wurde, dann ginge es auch ... du brauchst dann nur die gleiche Delphi-Version, schleußt die neuen BPLs ein und mußt nur die Verlinkungen zu den alten FR-BPLs auf die Neuen umleiten (geht aber nur, wenn sich beide Versionen gleichzeitig in einem Programm nutzen lassen), ansonsten müsste man wohl die FR4-BPLs nachbauen, mit genau den selben Schnittstellen und intern FR5 verstecken.

Fazit: nö

Bei Google suchen

Hook

Hook

**recall**

Vielleicht kannst du einen anderen Weg gehen, die PDF nach dem Erstellen wieder lesbar zu machen?
Vielleicht kann das ImageMagick (einfach mal durch das convert jagen)?

Ich weiß nur, das ImageMagick PDFs lesen und konvertieren kann, nicht ob es auch welche erstellt.
Wenn dabei am Ende KEIN PDF rauskommt, oder keines dass unter iOS lesbar ist, dann gäbe es noch einen hässlichen Hack:

Benutze ImageMagick um ein png je Seite zu erzeugen.
Dann nimmst du z.B. LaTeX und compilierst dir aus den einzelnen pngs ein PDF.
Das fertige PDF ist natürlich größer als das Original und der Text ist nicht mehr markierbar usw., aber immerhin wäre es dann lesbar unter iOS

.

Ansonsten: Woher stammen denn die Daten in dem Programm?
Kommen die vielleicht aus einer Datenbank, die du selber auslesen könntest?

**Bernhard Geyer**

Vergiss den Hacking-Ansatz. Ist zu Aufwändig.

Ich vermute mal das euer Problem beim Hersteller nur nicht die Priorität hat um das zu Fixen.
Wenn ihr wollt das das gefixt wird werded ihr vermutlich Wohl oder übel über die kommerzielle Schiene gehen müssen wenn es sonst nicht geht:

Also offizielle schriftliche Mängelrüge mit Setzen einer Frist bis zur Behebung. Einstellung von Wartungs/Lizenzzahlungen etc und Aufmachen einer Gegenrechnung das durch die Fehler der SW Kosten entstanden sind. Aber bedenkt. Das kann auch nach hinten los gehen indem der Hersteller sagt: Ok. Dann wollen wir euch nicht mehr als Kunden und ihre dann (wenn es ganz schlecht läuft) einen neuen Hersteller suchen müsst.

**Neutral General**

Zitat von Bernhard Geyer:

Vergiss den Hacking-Ansatz. Ist zu Aufwändig.

Ich vermute mal das euer Problem beim Hersteller nur nicht die Priorität hat um das zu Fixen.
Wenn ihr wollt das das gefixt wird werded ihr vermutlich Wohl oder übel über die kommerzielle Schiene gehen müssen wenn es sonst nicht geht:

Also offizielle schriftliche Mängelrüge mit Setzen einer Frist bis zur Behebung. Einstellung von Wartungs/Lizenzzahlungen etc und Aufmachen einer Gegenrechnung das durch die Fehler der SW Kosten entstanden sind. Aber bedenkt. Das kann auch nach hinten los gehen indem der Hersteller sagt: Ok. Dann wollen wir euch nicht mehr als Kunden und ihre dann (wenn es ganz schlecht läuft) einen neuen Hersteller suchen müsst.

Also das finde ich etwas heftig. Es ist ja kein Fehler Fastreport 4 statt Fastreport 5 implementiert zu haben.
Es ist ein Feature was der Kunde gerne hätte aber in der Software nicht enthalten ist. Das berechtigt den Kunden nicht seine Zahlungen einzustellen oder sogar eine Gegenrechnung aufzumachen.

**Bernhard Geyer**

Zitat von Neutral General:

Also das finde ich etwas heftig. Es ist ja kein Fehler Fastreport 4 statt Fastreport 5 implementiert zu haben.

Der Fehler ist das fehlerhafte PDFs erstellt werden. Ob das nun mit FR4/5 erstellt wurden ist egal.
Das Beworbene Feature "Wir können PDFs erstellen" ist Fehlerhaft. Man müsste sicherlich über PDF-Validatoren nachweisen das diese PDF fehlerhaft sind. Nur das sie im Adobe Acrobat gehen heißt ja noch langen nicht das sie korrekt sind.

**Blup**

Zitat:

Der Hersteller bekommt es nicht hin, Fastreport 4 gegen Fastreport 5 auszutauschen, obwohl das kein großes Problem ist.

Wie kannst du das beurteilen?
Gerade Reportgeneratoren, Drucker und Druckertreiber im Zusammenspiel mit der GDI und den Treibern der Grafikkarte sind ein ganz sensibles Thema.
Kommen dann noch verschiedene Plattformen hinzu, wirds richtig spannend.
So ein Warenwirtschaftssystem hat sicher hunderte von verschiedenen Druckformularen, auch wenn du nur ein Bruchteil tatsächlich verwendest.

Ob die Dateien fehlerhaft sind, ist nicht bewiesen.
Das ein bestimmtes Betriebssystem nicht von Haus aus alle PDF-Formate unterstützt ist kein Mangel, den man dem Programm anlasten kann.
Es sei den, der Hersteller hat genau für diese Umgebung zugesichert, dass dieses Feature nutzbar ist.

Benötigst wird doch eigentlich nur ein Programm, dass nach jedem PDF-Export das Format der Datei korrigiert.
Dazu könnte man mit dem Hersteller eine Schnittstelle vereinbaren.
Das Warenwirtschaftsprogramm soll nach jedem PDF-Export eine Batch-Datei aufrufen und den Namen der PDF-Datei als Parameter übergeben.
Darin wird dann das Konvertierungsprogramm aufgerufen und gut.

**SvB**

@himitsu: ich glaube das hacking in dieser Form wäre dann doch zu aufwändig.

Hab ich vergessen zu erwähnen!

Die Reports liegen alle in einer MS-SQL, auf die man auch zugreifen könnte. Ich müsste nur abgreifen, welcher Report aufgerufen wird (Name in DB) und z.B. die Angebotsnummer / Auftragsnummer usw., muss mir das noch mal genauer ansehen, wie das genau in der DB abgelegt ist.

Zitat von Bernhard Geyer:

Ich vermute mal das euer Problem beim Hersteller nur nicht die Priorität hat um das zu Fixen.

--> Alles schon probiert, der Hersteller ist schon seit längerem dabei, die Software auf .Net neu zu programmieren. Letztes Jahr so um diese Zeit hab ich eine Beta gesehen und gegenüber dem, was ich gestern auf der CeBit gesehen habe, hat sich immer noch nicht viel mehr getan, also immer noch Beta. Das kann also noch ein bis zwei Jahre dauern, bis die neue Software richtig zu benutzen ist.
Die bisherige Software ist grundsätzlich in Ordnung, wenn da nicht immer diese "Kleinigkeiten" wären, die einem in der täglichen Arbeit, das leben schwer machen.

Zitat von Bernhard Geyer:

Nur das sie im Adobe Acrobat gehen heißt ja noch langen nicht das sie korrekt sind.

Es ist ja bekannt, dass FR4 nicht PDF/A konform exportiert, im FR5 ist das ja behoben. Das Problem ist, das im Zeitalter der Mobilität immer mehr Kunden z.B. Angebot auf dem Smartphone lesen und da wird es nicht richtig angezeigt und das macht einfach einen schlechten Eindruck. Der Kunde denkt, wir sind zu doof lesbare PDFs zu erstellen.

**SvB**

Zitat von Blup:

Wie kannst du das beurteilen?

Wie ich vorhin noch mal korrigiert habe, liegen die Reports alle in der DB. Es müsste dann nur die FR4 durch die FR5 ausgetauscht werden, dann sollte trotzdem die Reports funktionieren.
Ich habe das selbst schon in einer eigenen Anwendung gemacht und musste an den Reports nichts ändern.

**Bernhard Geyer**

Zitat von SvB:

Zitat von Bernhard Geyer:

Ich vermute mal das euer Problem beim Hersteller nur nicht die Priorität hat um das zu Fixen.

--> Alles schon probiert, der Hersteller ist schon seit längerem dabei, die Software auf .Net neu zu programmieren. Letztes Jahr so um diese Zeit hab ich eine Beta gesehen und gegenüber dem, was ich gestern auf der CeBit gesehen habe, hat sich immer noch nicht viel mehr getan, also immer noch Beta. Das kann also noch ein bis zwei Jahre dauern, bis die neue Software richtig zu benutzen ist.

Wir hatten auch mal eine (primär CRM) SW die der Hersteller in .NET neu Entwickelt hat. Wir haben ihn aber rausgeschmissen denn die Wahrscheinlichkeit war sehr groß das der gleiche Programmiermüll in .NET nochmal gemacht wird den sie in Access-VBA gemacht hatten.

Zitat von SvB:

Es ist ja bekannt, dass FR4 nicht PDF/A konform exportiert, im FR5 ist das ja behoben.

Das ist nicht dein Problem. Du hast ein SW gekauft die PDFs erstellen kann, du hast kein FR-Implementierung zur PDF-Erstellung gekauft. Und wenn (die tausend verfügbaren) PDF-Validatoren sagen das die PDFs Müll sind, dann hat der Hersteller ein Problem damit das fixen zu müssen.