- Details
- Written by Robert van der Hulst
This week I was approached by a (valued) customer that was convinced that he had found a problem in the DBFCDX driver in X# and the customer had a reproducible example of a seek in a DBF that failed in X# but worked in Visual Objects(VO). And to be honest, I also had the feeling that this could indeed be a bug
In this (long) article I would like to explain the problem and also give a little bit of background info about CDX indexes and sorting.
So I loaded the code from the customer and indeed the seek failed in X# and succeeded in VO.
Then I ran an internal command that dumps the contents of a tag inside a CDX to a text file, so I could inspect the various index pages.
After that I recreated the index in X# and dumped that index too and I found that there was difference in the sort order.
I thought: Bingo there is indeed a problem in our sorting routine and I confirmed the bug to the customer. But I was wrong....
Read more: Indexes, Sorting and how a bug was not a bug
Comments (4 Comments)- Details
- Written by Chris Pyrgas
In the last days, we have been trying to (among other things) complete the VO compatibility aspect of X#, by implementing one final missing piece, behavior of numeric arithmetic that is completely compatible to Visual Objects.
The area where this becomes visible is when dealing with integral numbers (either variables or constants) with a size < 32 bits, so of the type BYTE, SHORT and WORD.
For example, consider this code:
LOCAL b1,b2 AS BYTE LOCAL n AS INT b1 := 250 b2 := 10 n := b1 + b2 ? n
Currently this prints 260 in X#, as you may (or not!) expect. But in VO, the same code returns 4; the operation is performed between 2 BYTE vars and so is the result, which first overflows from the max value of 255 that can be stored in a byte and results to that value of 4 (260 mod 256), which is then in turn assigned to the INT var.
Read more: VO Compatible Arithmetic in X#
Comments (4 Comments)- Details
- Written by Robert van der Hulst
Those of you that watch our commits on Github may have already noticed it:
we are working on the SQL functions for FoxPro support.
What have have so far:
SQLConnect()
SQLStringConnect()
SQLDisconnect()
These three create a SqlStatement object with an embedded SqlConnection object. When the statement is marked as "Shared" then the Connection can be shared between multiple statements.
To get and set properties for these SQLStatements you can call
SQLSetProp()
SQLGetProp()
Read more: Progress on VFP runtime, SQL functions
Comments (3 Comments)- Details
- Written by Robert van der Hulst
With this article I want to start a series of articles with tips that can help improve the performance of your apps when they are moved from Visual Objects and/or Vulcan to X#.
The first tip is to use the IS comparison in stead of IsInstanceOf()
Try the following code in a VO Console application:
FUNCTION start AS VOID
LOCAL oErr AS OBJECT
LOCAL nI AS LONG
LOCAL f AS FLOAT
oErr := Error{}
f := Seconds()
nI := 0
FOR VAR nX := 1 TO 10_000_000
IF IsInstanceOf(oErr, #Error)
nI++
ENDIF
NEXT
? Seconds() - f, nI
f := Seconds()
FOR VAR nX := 1 TO 10_000_000
IF oErr IS Error
nI++
ENDIF
NEXT
? Seconds() - f, nI
WAIT
Read more: Performance Tips - 1
Comments (2 Comments)- Details
- Written by Fabrice Foray
The XSharp language ILSpy5 plugin was not working with the latest stable version of ILSpy : V5.02
This has been addresses and you can get that version in the Downloads/General/Tools section.
Unzip the DLL in the same folder as the ILSpy Binaries and you're done.
If you are looking to the ILSpy V5.02 binary, go to ILSpy binaries.
Now, when running ISpy, you can set the language as XSharp.
Don't forget that the full source code of the Plugin is available in the public XSharp Repository on Github; you can also view there the current state of developement of the tool ( What is working currently, Changelog, ... )
ILSpy is the open-source .NET assembly browser and decompiler, and as shown during the xBase Future 2018, you can now use ILSpy to view and decompile .NET assembly as XSharp Language.
Comments (10 Comments)- Details
- Written by Robert van der Hulst
We sometimes get a question about the differences between the VO and Vulcan dialect.
In the table below we have tried to list these differences
| Description | VO | Vulcan |
| Keyword abbreviations | Supported for all 'old' keywords for 4 letters or more. See table on https://www.xsharp.info/help/x-keywords.html. All the keywords in the VO column may be abbreviated. | Only supported for PROCEDURE (PROC) FUNCTION (FUNC) LONGINT (LONG) SHORTINT (SHORT) |
| String literals | String literals can be defined with single quotes and double quotes: "This is a string" 'This is a string with an embedded double quote "' | String literals can only be defined with double quotes |
| Char literals | Must use single quotes prefixed with 'c', e.g. c'A' | Single quotes, the 'c' prefix is optional, e.g. 'A' and also c'A' |
| PSZ indexer | PSZ indexing is 1 based | PSZ indexing is 0 based (this is actually a bug in Vulcan that we are emulating) |
| MemVars (PUBLIC, PRIVATE) | Yes (in a future release) | No |
| Single line comments | Uses both // and && | Only // is supported. && is a synonym for .AND. |
| Compiler macros | defines __DIALECT_VO__ and __VO__ | defines __DIALECT_VULCAN__ and __VULCAN__ |
Something else that needs to be mentioned: if you switch from the Vulcan runtime to the X# runtime, please remember to remove the #include statements for the Vulcan header files, such as VOWIn32ApiLibrary.vh)
The values in these header files are now stored as defines (constants) in the VO SDK assemblies, such as VOWin32APILibrary.dll and also in the runtime assemblies (for values from VOSystemLibrary.vh).
Removing the header files will most likely improve the compilation speed.
- Details
- Written by Robert van der Hulst
We have received some questions about missing features in the Debugger.
In VO you had the ability to open windows in the debugger to see the list of open workareas, settings or privates. In X# we don't have these options yet. However the Visual Studio debugger is very powerfull and with the help of some clever watch settings you can see almost everything (until we have written a dedicated window for this).
Open workareas
To see the open workareas of an application, add a watch with the following contents(note that this is CaSe SenSiTiVe):
XSharp.RuntimeState.Workareas
I did this in the transported Explorer example just after opening the files and then the result is this:
You can see that there are 2 aliases opened. If you expand that then you'll see their names and workarea numbers.
The Current workarea is of type DBFNTX and has an alias Orders
Comments (1 Comment)- Details
- Written by Robert van der Hulst
In our attempt to make X# as compatible as possible we are supporting almost all the constructs of the VO language. One of the language constructs that gives some problems is the _CAST operation.
Take the following code:
FUNCTION start
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := 100
siValue := SHORT(_CAST, uValue)
? uValue
? siValue
WAIT
RETURN NIL
Which result is printer for siValue and uValue ?
Most of you will answer 100, and that is correct.
What if we change the example to:
FUNCTION start
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := MyFunction()
siValue := SHORT(_CAST, uValue)
? uValue
? siValue
WAIT
RETURN NIL
FUNCTION MyFunction
RETURN 1 - PI
What will the answer be ? (And yes, PI is a predefined constant in VO and X# with the value of 3.14159265358979323846). And please, don't cheat, don't run the example in VO. Just solve this in your head.
Read more: To cast or not to cast
Comments (1 Comment)