Automation kann nicht aufgerufen werden

Hallo liebes Forum,

bezüglich Automations habe ich bereits einiges gefunden, leider konnte mir nichts konkret helfen.

Es geht um folgendes:

Wir haben eine Codeunit vom Kunden erhalten, die eine Automation-Variable enthält, welche aber nicht aufgerufen werden kann bzw. welche im Subtype Unknown Automation Server.Unknown Class stehen hat. Lt. Kunde sollte eigentlich die Broadgun PDFMachine über die Variable angesprochen werden. Also habe ich entsprechend die neueste Version installiert und über das Admin-Dos Fenster die NSAppHandler registriert.

Leider zeigt nach einem Neustart die Variable immer noch den Wert Unknown Automation Server.Unknown Class an und in der Liste der Automation Server konnte die PDF-Machine auch nicht gefunden werden.

Muss man eventuell erst einmal die dll´s der BG-Software signieren etc. Irgendwie scheint mir ein Schritt zu fehlen? Kennt sich damit jemand aus?


-> Als Anmerkung: Es ist wichtig genau dieses Programm einzubinden, da entsprechend Quellcode daraus hervorgeht. D.h. Sollte wir einen andern PDF-Creator einbinden, wie z.B. PDFCreator, müsste die ganze Programmierung neu gemacht werden. (übrigens haben wir die Objekte nur übernommen)

Besten Dank.

MFG
FrankyGast


PS.: Classic Client ;)

Hi,

das kann daran liegen das die Version von Braodgun die beim kompilieren des Objektes verwendet wurde älter ist.
Also eine ältere Automation-Version hinterlegt ist.

Du solltest mal die selbe Version installieren die beim Kunden vor Ort verwendet wird, und dann die "Unknown Automation" eventuell mal über den LookUp mit der Broadgun Automation belegen.

Hallo,

für die Broadgun benötigt man normalerweise keine DLL, es sei denn es ist eine alte BOG- Installation, dann musst du die Objekte wohl oder übel anpassen .

Wie heißt denn die nicht definierte Variable?

Gruß, Fiddi

für die Broadgun benötigt man normalerweise keine DLL...

Richtig, eigentlich läßt sich Broadgun über Steuerzeichen im Report bedienen. Man braucht eigentlich keine DLL. Keine Ahnung, was da versucht wurde. Aber prinzipiell hat Daniel schon die richtige Antwort gegeben. Wenn es erstmal nur darum geht das Objekt wieder kompilieren zu können, muß du exakt die gleiche Version der DLL verwenden, die der Kunde einsetzt, bei dem es ja zu funktionieren scheint. Oder ist das auch nicht mehr der Fall?

Das Stichwort "BOG" bringt mich auf die Idee, dass es sich bei der Automation-Variable um ein kleines Tool handeln könnte, mit welchem bestimmte Einstellungen für die Broadgun pdfMachine in die Windows Registry geschrieben wurden.
Somit wäre die Automation nicht weiter notwendig, sondern könnte durch eine WindowsScriptingHost (WSH) Automation-Variable ausgetauscht werden.
Dann müssten nur die Stellen, wo in die Registry geschrieben bzw. aus ihr gelesen wird, auf WSH.RegWrite bzw. WSH.RegRead umgestellt werden.

Das Stichwort "BOG" bringt mich auf die Idee, dass es sich bei der Automation-Variable um ein kleines Tool handeln könnte, mit welchem bestimmte Einstellungen für die Broadgun pdfMachine in die Windows Registry geschrieben wurden.
Somit wäre die Automation nicht weiter notwendig, sondern könnte durch eine WindowsScriptingHost (WSH) Automation-Variable ausgetauscht werden.
Dann müssten nur die Stellen, wo in die Registry geschrieben bzw. aus ihr gelesen wird, auf WSH.RegWrite bzw. WSH.RegRead umgestellt werden.

Damit ist es leider nicht ganz getan

Gruß, Fiddi

Hallo nochmal,

vielen Dank für die schnellen und konstruktiven Antworten. Leider ist das mit der identischen Version des Kunden nicht möglich, da der Kunde dieses Tool nie zum laufen gebracht hat. D.h. es wurde irgendwann mal, von irgendjemand , entwickelt und wir sollen nun testen, ob es entsprechend funktioniert. Die benötigen Automation waren soweit nur beim Entwickler dieses Tools vorhanden

So wie es ausschaut, müssen wir dann den Quellcode umschreiben. Schade eigentlich, das ganze sah eigentlich sehr vernünftig aus.

Sollte dennoch jemand einen Tipp haben, wäre ich sehr dankbar.

Gruß
Franky

Hi,

dir bleibt immer noch folgender Versuch:

Tausche die "Unknown" Automation durch die Automation der neuesten Version aus (falls es hier eine gibt).
Dann müsstest du beim kompilieren bereits feststellen ob zumindestens die Parameter und Funktionen identisch geblieben sind.
Ist dies der Fall, kannst du testen was Braodgun anstellt sobald der Code ausgeführt wird.

Ansonsten schliesse ich mich fiddi an, für Braodgun genügen Steuerzeichen im Report.
Diese einfach in einer Header-Section andrucken, Schriftgrösse und Überlagerungen sind grösstenteils egal.

Leider ist das mit der identischen Version des Kunden nicht möglich, da der Kunde dieses Tool nie zum laufen gebracht hat. D.h. es wurde irgendwann mal, von irgendjemand , entwickelt und wir sollen nun testen, ob es entsprechend funktioniert.

Ganz ehrlich, macht eine neue Anforderungsaufnahme und entwickelt eine eigene Lösung. Die Ergebnisse der letzten Spezifikation können ja als Basis genommen werden, sofern so etwas vorhanden gewesen ist. Und es gibt bestimmt auch seitdem neue Erkenntnisse, neue Technologien, verbesserte Arbeitsabläufe und andere Anforderungen an eine solche Lösung. Das kann man dann alles berücksichtigen. Unter den von dir genannten Umständen würde ich keine Minute in die alte Lösung stecken. Das macht doch keinen Sinn.