Wiki Home

VFP Function Transform


Namespace: VFP
Neat things about Transform()
Usage: cRetVal = TRANSFORM( uExpression [, cFormat ] )

Ever need some debug information and you don't know (at development time) what data type the variable you're dealing with might be? You could use a CASE statement:
DO CASE CASE VarType(whatever)='X' Out = '.NULL.' CASE VarType(whatever)='C' Out = whatever CASE VarType(whatever)='N' Out = alltrim(str(whatever)) . . . etc.

Or, now in VFP 6, you can use TRANSFORM( whatever ) (without the format code) and VFP will do its default transformation for the type of "whatever" into a String! Even nulls are usefully converted to ".null."!

Just be careful when giving a memo field directly to Transform()... according to Hack Fox, it has a bug of returning "memo" (literally, the string "memo") if you don't translate the memo field into a character expression (with something like All Trim()) first. Yet, since the default transformation for a string is to All Trim() it, Transform(AllTrim(MyMemoField)) is kind of redundant if you already know MyMemoField is a memo field.

I added Bold to the phrase above, that is wrong. As far as I can tell, Transform() without any parameters other than the string you're transforming does nothing.
wait window tran(space(5) + 'mike' + space(5))
--MikeHelland

Also, Transform() doesn't handle objects at all: It returns "Function argument, type, or count is invalid", but it does handle .NULL. objects (ie. Set variable "m.x" to an object, then set "m.x" to .NULL.; Now TYPE("m.X")='O' but Var Type(m.X)='X' and TRANSFORM(m.X)='.NULL.'

In speed tests, the case statement is typically much slower than TRANSFORM() for any data type except for Numeric with alltrim(str(NUMBER)) compared to transform(NUMBER).

Recently I made some tests for speed of calling DCOM object through LAN. I tried to display following expression:
? transform((seconds()-m.StartSeconds)/m.NumberOfTries,'999 999.99999')
It always shows '0.00000'.
? str((seconds()-m.StartSeconds)/m.NumberOfTries,12,5)
displays correct result: '0.00240'.
-- Vlad Grynchyshyn

Issuing a Transform() on a number with a decimal value, between 64.1 and 99.9999..., returns 14 decimal places.
?Transform(64.1)

64.09999999999999


I'm not sure if this is a bug or I'm overlooking something. Any one else know about this? I tested it on 3 PCs.
-BarryDempsey

Probably related to SET DECIMALS. This came from a reported "Bug" in VFP:
Recently I made some tests for speed. I tried to display following expression:
? transform((seconds()-m.StartSeconds)/m.NumberOfTries,'999 999.99999')
It always shows '0.00000'.
? str((seconds()-m.StartSeconds)/m.NumberOfTries,12,5)
displays correct result: '0.00240'.

-- Vlad Grynchyshyn

This is a SET DECIMALS issue. If you SET DECIMALS TO 12 before this, it works as you think it should. The reason the str() function works is because the decimals parameter overrides the current SET DECIMALS setting. If you are going to do any fractional math, make sure to check your SET DECIMALS setting -- BradKarsjens


Tried to use Transform() to strip post decimal place trailing zeros, but it does not seem to work, e.g. transform(0.5000) should return 0.5 but it returns 0.5000. The help specifically states that transform without a parameter will remove trailing zeros from numerics. Any comments?

Actually, the help says: "Removes trailing zeros from the decimal portion of a numeric value when all the numbers following the decimal point are zeros."

Category VFP Functions
( Topic last updated: 2007.06.28 11:51:57 PM )