Probleme mit ReportPro2 Integration in eigene Applikation

Heinrich · Post by **Heinrich** » Thu Jul 18, 2019 7:49 pm

Hallo zusammen
Wenn ich die RP2 DLL's in meine Applikation integriere und dann einen bestehenden Report aufrufen und drucken will, bekomme ich immer die gleichen beiden Fehler. Wenn ich die erstellten Beispiele (im gleichen Verzeichnis wie meine App) verwende funktioniert der selbe Report einwandfrei.

Es sieht so aus, als ob die benötigten RDD's nicht geladen würden.
Zudem wird in meiner App die Sprach.DLL ebenfalls nicht geladen. Dies habe ich mit explzitem Laden der DLL hinbekommen. Bei den DBF DLL's weiss ich nicht wie ich das anstellen soll.

Was ich bisher versucht habe:
[*]
[*]eine eigene kleine App mit dem Aufruf vom Report, funktioniert einwandfrei.
[*]die genau gleiche Funktion vom Beispiel in die Applikation eingefügt und ebenfalls in der Startroutine aufgerufen. Führt zu oben beschriebenem Fehler.

Erstellte Funktion:

Code: Select all

FUNCTION OpenRpReport( oOwner AS OBJECT, cReport AS STRING ) AS VOID
	LOCAL oRep AS RpReportRDD
	LOCAL oWin AS ShellWindow	

	oWin :=  ShellWindow{}

 	RDDSetDefault("DBFCDX")
	RDDInfo(_SET_FOXLOCK,.T.)
	SetRpLangDLL("ReportPro2.English.dll")

	oRep := RpReportRDD{ oWin, AllTrim(cReport), "", {} }

	IF oRep:IsValid
		// direkt auf den Drucker
		oRep:Print( "Standblatt" ,;	// cJobName
				  "REPORT.PRN"	,;	// cPrint2Filename
				  "Standblatt"		,;	// cCaption
				  "wird gedruckt.."	 ;	// cMessage
				 )
	ENDIF       
RETURN

Verwendete Vulcan Version: Vulcan.NET 303k
DLL's sind im GAC und zusätzlich auch im entsprechenden ReportProVerzeichnis: VnRuntime

Meine Applikation verwendet verschiedene selbst erstellte DLL's welche je nach Zweck reine C#, X# Core, oder X# VO / Vulcan Einstellungen haben.

Kann mir jemand weiterhelfen?
Gruss Heinrich

FFF · Post by **FFF** » Thu Jul 18, 2019 9:43 pm

Welche Fehler?
Wenn in der eigenen kleinen App diese nicht auftreten, muß im Setting ein Unterschied bestehen
Also, was ist die eigene kleine App? Einfach ein Sample modifiziert? Welches, welche Sprache?

Karl

Heinrich · Post by **Heinrich** » Fri Jul 19, 2019 6:27 am

Hallo Karl
Die Fehlermeldungen habe ich doch glatt vergessen

Hier sind sie:
[*]
[*]The following error was encountered while validating Field Object Expressions:Invalid Field Object expression: Stdblt.Schuetze
[*]The following error was encountered while moving to the first logical record: Invalid argument type

Programmbeispiel:

Code: Select all

USING Vulcan.VO
USING ReportPro2

FUNCTION Start( ) AS VOID
	LOCAL oRep AS rpreportrdd
	LOCAL oWin AS ShellWindow
	
	oWin := ShellWindow{}
	
	oRep := RpReportRDD{ oWin, "c:TempxSharpTestBinReportsKlausSchiessen2018.RPT", "", {} } 
	IF oRep:IsValid
				oRep:Print( "Standblatt",;	// cJobName
						"REPORT.PRN"	,;	// cPrint2Filename
						"Standblatt"		,;	// cCaption
						"wird gedruckt.."	 ;	// cMessage
							 )
	ENDIF

	System.Console.WriteLine("Ende Report mit x#!")          
RETURN

Und hier die verwendeten Referenzen. Sind in den Beispielen und in der Applikation die selben.
RpTestReferenzen.png (19.29 KiB) Viewed 637 times

Erstellt mit xSharp und dem Schalter VO
Gruss Heinrich

wriedmann · Post by **wriedmann** » Fri Jul 19, 2019 7:00 am

Hallo Heinrich,
IMHO darfst Du die XSharp Runtime und die Vulcan Runtime nicht im selben Speicherbereich haben.
D.h. Du darfst in einer Applikation, die die Vulcan Runtime verwendet, keine DLL verwenden, die die X# Runtime verwendet.
Wolfgang

Heinrich · Post by **Heinrich** » Fri Jul 19, 2019 7:37 am

Hallo Wolfgang
Danke für den Tip.
Das könnte meine Probleme verursachen. Ich habe genau eine DLL, welche die xSharp Runtime verwendet.
Ich werden diese DLL mal abändern und schauen was passiert.
Gruss Heinrich

Heinrich · Post by **Heinrich** » Fri Jul 19, 2019 8:06 am

Jetzt habe ich alle DLL's mit der Sprache XSharp und dem Dialekt VO unter Verwendung der VulcanXXXX DLL's erstellt.
Hat leider nicht funktioniert.
die von RP2 benötigten DLL's werden nicht geladen auch die Sprache nicht.

Es sollte doch keine Rolle spielen, dass die RP DLL's mit VisualObjekt 2017 erstellt worden sind. Denn auch da werden die selben VulcanXXX DLL's verwendet.

wriedmann · Post by **wriedmann** » Fri Jul 19, 2019 8:06 am

Hallo Heinrich,
das hängt damit zusammen, dass die X# Runtime und die Vulcan Runtime die Xbase-Typen auf verschiedene Arten implementiert haben, und das beisst sich dann halt.
Über den Hintergrund siehe hier: https://www.xsharp.eu/articles/blog/run ... -in-xsharp
Wolfgang

Heinrich · Post by **Heinrich** » Wed Jul 24, 2019 2:48 pm

Hallo zusammen

Das Fehlverhalten ist nun bekannt und das Problem gelöst.
Abhilfe schaffte das einfache Einbinden der ReportPro2.runtime DLL in meine Start-App.

Ursache:
Wie in VO gewohnt, habe ich die ReportPro DLL's nur in der Library eingebunden, wo auf die ReportPro Klassen zugegriffen wurde.

Nachdem ich den Quellcode bis zur Ursache des Problems mit dem Debuger untersucht habe, musste ich feststellen dass auf nicht initialisierte Objekte zugeriffen wird. Und das weil die mit _INIT3 gekennzeichneten Prozeduren beim Start der Applikation nicht aufgerufen werden. Scheinbar haben wir hier ein zu VO unterschiedliches Verhalten, das ich noch nicht wusste.

Gruss Heinrich

wriedmann · Post by **wriedmann** » Wed Jul 24, 2019 3:08 pm

Hallo Heinrich,

das klingt sehr logisch....
Einer der großen Unterschiede zwischen den Libraries in VO und denen in .NET ist der, dass VO die Libraries fix ins Exe einlinkt, während sie bei .NET als externe DLLs vorliegen.
Und dann macht .NET genau das, was ich bei VO immer schon gerne gehabt hätte: Lazy loading. Das bedeutet, dass eine Library erst geladen wird, sobald sie das erste Mal gebraucht wird. Das wirkt sich auf die Ladezeiten einer Applikation sehr positiv aus, kann allerdings zu Laufzeitfehlern führen, wenn die benötigte DLL nicht vorhanden ist.
Dummerweise habe ich in der Doku nichts gefunden, was das Verhalten der INIT-Prozeduren erklärt, und auch keine passende Mail dazu.

Wolfgang

ArneOrtlinghaus · Post by **ArneOrtlinghaus** » Wed Jul 24, 2019 3:23 pm

Ach, da kann ich auch meinen Senf dazugeben, auch wenn ich nicht das Problem lösen kann.

Dasselbe Verhalten gibt es mit den GUI-Klassen. Diese müssen in das Startprogramm eingebunden sein. Bei einem dynamischen Laden funktionieren sonst bestimmte Sachen nicht und das wahrscheinlich wegen diesen __Init-Prozeduren. Robert hat mal gesagt, dass nur wenige Menschen auf dieser Welt diese Prozesse vollständig verstanden haben...

Aber es gibt meiner Meinung nach nur wenige Ausnahmen.

In unseren Programmen (VO und X#) wird der Großteil der DLLs dynamisch geladen, wenn sie gebraucht werden. Das hatten wir eingebaut, weil eben VO und gleich alle Programme, die auf den mit den Microsoft-Rutime-Dlls für Dlls eingeführten Mechanismen aufbauen, alle DLLs sofort laden wollen, sobald es eine feste Referenz auf eine DLL gibt.

Das ist nun mit Dotnet anders, wie Wolfgang geschrieben hat. Und das ist ein toller Vorteil für etwas größere Programme, denn das programmierte dynamische Laden von DLLs kann auch die Programmierung ganz schön mühsam machen. Bei uns mit über 100 Applikations-Dlls werden im Schnitt vielleicht 30 geladen, weil nicht jeder Benutzer die gleichen Programme benötigt oder bestimmte Programme nur sehr selten benötigt werden.