ReportPro Error handling problem

[cpyrgas]

The attached rpt:

GS.zip

contains an invalid sort order specification (remnant from another dbf used previously, which is now removed from the report). When trying to preview this report from the designer, RP2 crashes with an error dialog which is not informative of the problem:

The problem with the invalid sort order specification is actually detected correctly by the RP code, and it is thrown with a appropriate error message from the code in rpDataSource:CreateForeignSort(), in the file \ReportPro2, Runtime\DataSources\DS (R,S,D).prg, line 262:

	    IF Empty(cExpress)									// couldn't build the index, report an error...
		    cText:=""
		    AEval(aOrder,{|x| cText+=x:cName+", "})
		    IF SLen(cText)>2
			    cText:=Left(cText,SLen(cText)-2)
		    ENDIF

		    oError:=Error{}
		    oError:Description:=RPLangString(IDL_ERROR_INVALID_SORT)+cText
		    BREAK oError
	    ENDIF

Then this error is supposed to be intercepted by the code in PtrDevice:CallPrintStart(), in the file \ReportPro2, Runtime\Printing\PtrDev (R,S,D).prg, line 2407:

            INTERNAL METHOD CallPrintStart() AS LONGINT STRICT
                // method to allow subclasses to chain into the callback methods
                LOCAL nResult		AS LONGINT
                TRY
                    SELF:nBusy		+=1
                    nResult:=SELF:oRptOwner:PrintStart(SELF)
                CATCH oError AS __Runtime_Error
                    SELF:oPrintWin:ForceStable()
                    THROW
                    nResult:=PRINT_ERROR
                FINALLY
                    SELF:nBusy -= 1
                END TRY

                RETURN nResult

but this code, not only re-throws the exception, but also expects an exception of type XSharp.Error (this is what __Runtime_Error is defined as, it was Vulcan.Error while RP2 was being compiled in vulcan), while the exception intercepted is an XSharp.Internal.WrappedException, hence the error is never trapped at this stage, but only later in the global app try block, which causes to exit abnormally.

Searching globally for __Runtime_Error reveals a couple more places where this is used, so we probably need to adjust the error handling of RP2 in all those cases. Note that the exact same runtime problem exists also in RP3.

[RobertvanderHulst]

Needs testing

[cpyrgas]

Problem fixed in RP2, but remains in RP3. Robert, I'm not adjusting it myself, better you do it, since you've already done the changes for RP2