FoxProMatt wrote:As I was looking through the list of Functions in the X#.VFP Runtime documentation, I saw that plenty of the basic VFP Functions were not in the list. I thought that strange, because I know X# does many of these Functions I was looking for.
Well, then I clicked through X#.Core Function list, and I saw the "missing" functions listed there.
So, I get it it... Some are unique to VFP and those are in X#.VFP, and some are common to all dialects, and they are in X#.Core docs. I assume that what I was seeing. Okay...
You definately nailed the basic mechanism, but did not mention the functions in Runtime (as in "RT") where parameter checking on USUAL and other basic cleaning can be done.
And yes, already less then 200 functions to do - which means about 2/3 of the functions not only availble (as in "does not throw error when compiling") but doing most probably what you expected when typing it in. Buuuut as we know the problems lie in edge cases
Code: Select all
.
var lcNumStr = "123456789"
? substr(lcNumStr, 2, 2)
*-- even asking for data past the end
? substr(lcNumStr, 2, 12)
*-- but wait! vfp will return nothing from here!
? substr(lcNumStr, 2, -12)
*-- and definately in this case not the same as xSharp
? substr(lcNumStr, -5, 3)
*-- which is the same as
? Left(Right(lcNumStr, 5), 3)
Actually, the last one is rather likable, as it is easier to read. But any vfp app, certain that on negative parameters no output is generated, will be in trouble. In xSharp, whenever I am certain of my types, I will use __SubStr(c, start, len) with negative value on 2. Parameter counting from right and negative 3. Parameter meaning "rest of" - but in compatibility mode those negatve values have to be checked and returned as empty..
But even worse: vfp will return .null. when fed .null. as any parameter. If I try hard to contrive an example, SQL datamining of genomes mapped into varchar(binary) encountering .null. might be better served than returning strings from start or end or stopping alltogether in 1. Parameter
)
Pretty certain that more .null.problems will be found on most string functions - just drudge work done with no big mental effort, but needing function signature and (harder...) handling of optional parameters if needs to be done only at lowest vfp runtime level.Left() for instance will not throw compile error if given USUAL parameter set to .NULL: (which is correct!) but not return .Null.
The only thing is, I think it would be more awesome if the X#.VFP Runtime Documentation included *every* native VFP Function that is known to exist in original VFP. That way the available X#.VFP Runtime Functions does not appear incomplete.... You see??
Is there a way you could merge the X#.Core list with the X#.VFP list so that one could at least see the ENTIRE collective list of available Functions that are available??
Perhaps you could add a special character or icon or color to the ones in the list that come from X#.Core.
For instance, I was looking through X#.VFP Runtime Function list, looking for the basic AllTrim() function and I could not find it in the list. It is in the X#.Core Function list...
What the functions do
at each call level would be nice to be mirrored - and from what I see is planned via mapping strings - but probably some functionality will be added or moved. Read the code (NOT intended as a snide remark, it teaches me more and faster than reading docs)
We need more testing code, best with an option to run identical test under vfp and xSharp, then compare results from each systems via file or table. Did something along that line in Lianja and vfp, but Lianja was less static and easier to feed tests... must think a bit...
regards
thomas
