Inconsistent behaviour of RTRIM() between .exe and debug modes.

[AndrewMozley]

I have an application where I wish to remove trailing zeroes from a fairly long (61 char) character string, and find that the code performs differently when it is being run in debug mode from how it runs as a .exe program

My code (simplified - sorry about the variable names) is :

* ltrimirn = RTRIM(sbom.irn,"0"," ")
lTrimirn = sbom.irn
DO WHILE RIGHT(lTrimirn,1) = "0" .AND. LEN(lTrimirn) > 1
lTrimirn = LEFT(lTrimirn,LEN(lTrimirn) - 1)
ENDDO
lLenIrn = LEN(lTrimIrn)

I wish to establish the length of field sbom.irn after I have removed trailing zeroes. (In fact it does not have any trailing spaces - they are all zeroes).

Running under VFP control, with breakpoints it works fine, so :
“1002005003000000 . . . .” is reduced to “1002005003” by the RTRIM command

As an exe, the string remains as “1002005003000000 . . . .”

So eventually I have replaced the code by the rather more cumbersome DO WHILE loop (above), and that works.

Has anyone else observed this sort of behaviour?

Andrew

 

[Olaf Doschke]

Which version of VFP are you using and what is your runtime dll? Display Version() both in the IDE and at runtime.

I don't see any difference in IDE and Runtime with Visual FoxPro 09.00.0000.7423

I just did test this code in a main.prg compiled:

MessageBox( Rtrim(Padr("1002005003",61,"0"),"0"," ")+ " : " +Version())

Bye, Olaf.

 

[AndrewMozley]

Thanks Olaf

You may be pointing me in the right direction !

In the development environment (debugging, SET STEP and all that), Version()
returns :
Visual FoxPro 09.00.0000.5815 for Windows

The .exe version of the program (a commercial accounting package) returns :
Visual FoxPro 06.00.8961.00 .exe Support Library for Windows.


Thanks again. Andrew

 

[Olaf Doschke]

OK,

this shows an exe also can use an older runtime. I would have sworn it has to be a VFP9 runtime, if an exe is compiled with VFP9.
One thing is clear, VFP6 hasn't had an advanced RTRIM() function with cParsechar1,2,3 parameters.

It's always the easiest thign to put the vfp9r.dll to your exe and it will use that before looking anywhere else for a VFP runtime.

Bye, Olaf.

 

[Olaf Doschke]

That was too early. Now I see the exe was really done with VFP6 and you were just testing an expression in VFP9.

So if your commercial package is done in VFP6 and the vendor doesn't offer a VFP9 version, you can't enforce the vfp9 runtime, even not if copying it to the exe. And if you can extend this commercial product with code or define expressions it uses, you can only make use of VFP6 syntax. Then you have to live with your replacement code.

Bye, Olaf.