VO2.8 sp4 strange runtime error

jjgregg · Post by **jjgregg** » Thu Sep 05, 2019 5:42 pm

Hi, as a first step towards possibly migrating to X# we upgraded our VO 2.7b applications to VO 2.8 sp4, have had all kinds of problems getting the right ReportPro libraries compiled and recuperating all our third party software, not much, we use ReportPro, Bbrowser, and perhaps one other.

Managed to compile without errors both applications, before when we tried to execute them we got a listing of xlinked VO2.7 libraries, now we managed to clean that up and the applications (both) when we execute them the following message appears at runtime:
"The ordinal 160 could not be located in the dynamic link library..." Help! I'm lost and this is one reason that althought VO2.8sp4 is supposed to be very stable, we can't get basic support anywhere and that is a no go for me.

Thanks for any help!
John

Fabrice · Post by **Fabrice** » Thu Sep 05, 2019 5:48 pm

Hi John,

this means that you have somewhere a library that defines (at least one) prototype of a function/procedure that is supposed to be in an external library (DLL) written in C/C++/.. at position 160.

So, my guess is that you have a library (DLL) that doesn't match the declaration in VO ( not the same version number or something like that)
Can you please give more info ? and at least what is the related DLL ?

HTH,
Fab

wriedmann · Post by **wriedmann** » Thu Sep 05, 2019 5:56 pm

Hi John,

probably one of your referenced runtime libraries is from VO 2.7. Often the ReportPro runtime is the culprit.

Wolfgang

Chris · Post by **Chris** » Thu Sep 05, 2019 6:16 pm

Hi John,

In addition to what the guys said, let me also explain that while moving your app to VO28 was a perquisite for porting to Vulcan, this is not necessary for X#, which can port even VO2.5 apps. But moving to VO28 first will most likely help making the port to X# smoother, mainly by finding and fixing some problems in the code already in VO, since the VO28 compiler is stricter.

jjgregg · Post by **jjgregg** » Thu Sep 05, 2019 6:17 pm

Hi Wofgang, you are right, it has to be the only reportpro library I'm linking with the applications: RP3 Runtime OLEControl.
But I don't want to dismantle all the logic of maneuvering through RPT reports that we require.
Let's see
Thanks,
John

jjgregg · Post by **jjgregg** » Thu Sep 05, 2019 6:20 pm

rp3 Runtime OLEControl is the only library I compiled and linked to our applications, it has to be the one causing the problems. Let's see, I don't want to dismantle all the detail work that has gone in moving through and managing the RPT files they way we need them.
Thanks

wriedmann · Post by **wriedmann** » Thu Sep 05, 2019 6:32 pm

Hi John,
since you are using ReportPro 3: this is a major problem since all ReportPro 3 versions share the same GUID, and you can keep registered only one of them.
If there is another possibility to make this work, maybe release a new ReportPro 3 version with another GUID, must be left to the development team.
At the moment you need to unregister the 2.7 ReportPro and register the 2.8 version.
Wolfgang
P.S. I don't use ReportPro myself, but I know from other people that this can be an ussie

Main menu