xsharp.eu

ArneOrtlinghaus wrote:It is strange. Until now two computers have been found, where the program does not start anymore.
- The error happens in the EXE before the first self written line of code
- It happens in Vo28run!_ConvertResult
- this calls vo28run!_StackErr and then produces the error message on the screen
- It happens exactly with a simple console application.

Arne

Hi Arne,

Did you try to overwrite __ConvertResult() ? When you add the code to your app do you see the "__ConvertResult" messagebox at startup ?

--- xxxxxxxx ---

FUNCTION __ConvertResult (u AS USUAL) AS LOGIC PASCAL

messagebox ( 0 , string2psz ( asstring ( u ) ) , string2psz ( "__ConvertResult" ) , 0 )


RETURN xx__ConvertResult ( u )


_DLL FUNCTION xx__ConvertResult (u AS USUAL) AS LOGIC PASCAL:VO28RUN.__ConvertResult

--- xxxxxxxxx ---

_StackErr seems to be a SP4 thing. At least, my SP3 doesn´t know such a runtime func. The Errorbox you currently see might be this one:

//ERRORBOX.C
_DLL FUNCTION ErrorMessageBox(pszText AS PSZ,pszCapt AS PSZ, dwB1 AS DWORD, dwB2 AS DWORD, dwB3 AS DWORD) AS DWORD PASCAL:VO28RUN.ErrorMessageBox


regards
Karl-Heinz

Hi Karl-Heinz,

the message does not appear when inserting your code. But probably overwriting functions this ways is not always possible as many VO28run functions are not called in the normal way, especially in the starting process of an exe. It must be something before executing the first line of self-written code.

Arne

Same problems here, but the major problem is that the memory seems to exceed 1,3gb of memory in 32bit mode, since the activeX of SnelStart (External software for Accounting) completely loads the software as an ActiveX in the memory (+/- 800mb of memory !!!)
No problem at all with other software like SAP, UNIT4 etc.
So, track ActiveX items in your program that really use the memory.

When there are any fixes for VO i really want them also,
Thanks,
Alwin

Alwin,
"fixes for VO" ?
Really, and who should create this?
GrafX is dead and has the latest source for VO.

Robert

As expected...

Hi Alvin,

the real showstopper is the legal issue: only GrafX has the right to release updates to VO as they are/were the copyright owner.

The only possibility to fix VO problems is the move forward to X# - and that is what I'm doing.

I would not like to be imprepared when a newer Windows version gives unifxable problems in VO applications.

Wolfgang

Hi Alwin,

for us the LARGE ADDRESS AWARE seems to work good together with VO as it is and will remain. There seem to be issues before reaching the full 4 GB, but at least the 2 GB can be exceeded. The registry entry I used for testing must not be set, but this should not be a problem, because it is a registry setting designed to test this type of program usage and should not be set on production machines.

You should try it: modify your exe and test the program verifying using Process explorer looking at the column "Virtual size" (Do not use Task manager!)

Arne

After some months of running the modified application in production for several users I can say:
There are much less errors of type "Not enough memory" and these remaining errors come normally from Crystal Reports use. The program stays stable much more time for most users. There are some more random errors of type "array Bound errors" in Dialog windows which seem to have increased and seem to be related to somewhere in the GUI without being able to identify the location until now. I am not sure if these errors are related to the "Large address aware".

We have created batch jobs that modify the EXE after compilation.

So until now no disadvantages.

Arne


Arne