fbpx

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()

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.

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:

Vsworkareas

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

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.

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

In the previous article I have described how the xBase world evolved from DOS/Dbase and DOS/Clipper to Windows/Visual Objects and how that affected the character sets. OEM character sets for DOS/Clipper and Ansi Character sets for Windows/VO.

In this article I would like to discuss the relevance of all of this in relation to X#.

Introduction

To start: X# is a .Net development language as you all know and .Net is a Unicode environment. Each character in a Unicode environment is represented by one (or sometimes more) 16 bit numbers. The Unicode character set allows to encode all known characters, so your program can display any combination of West European, East European, Asian, Arabic etc. characters. At least when you choose the right font. Some fonts only support a subset of the Unicode characters, for example only Latin characters and other fonts only Chinese, Korean or Japanese.
The Unicode character set also has characters that represent the line draw characters that we know from the DOS world, and also various symbols and emoticons have a place in the Unicode character set.

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

DescriptionVOVulcan
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.

Introduction

We have been quite busy creating the X# runtime. And when we did that we stumbled on the problem of bytes, characters, codepages, Ansi and Unicode. X# has to deal with all of that and that can become quite complicated. That is why we decided to write a blob post about this. In this post we look back to explain the problems from the past and how the solutions to these problems are still relevant for us in a Unicode XBase environment such as X#.

Bytes and Characters in DOS

When IBM introduced Dos in the 80’s the computing world was much less complex than it is right now. Computers were rarely connected with a network and certainly not with computers outside the same office building or even outside the same city or country. Nowadays all our computers are connected through the internet and that brings new challenges for handling multiple languages with different character sets.

The origin of the XBase language was in CP/M (even before DOS) and the XBase runtimes and fileformats have evolved over time taking into account these changes.
Before IBM sold computers they were big in the typewriter industry. So they were well aware that there are different languages in the world with different character sets. Their IBM typewriters came in different versions with a different keyboard layout and different “ball” with characters. There were different balls with different character sets and different balls with fonts (Courier and Prestige were the most used, with 10 and 12 characters per inch).
DOS used a single byte (8 bits) to represent characters. So there was a limited number of characters available.  The number was certainly not big enough to represent all characters used by languages for which IBM was developing computers.
That is why IBM decided to group characters in so called Code Pages. The most common codepage used in the US and many other countries in the world was code page 437.

dos437

Code page 437

This codepage contains all non-accented Latin characters as well as several characters with accents, several (but not all) Greek characters, the inverted exclamation mark and question mark used in Spanish and quite some line draw characters, used to draw different boxes on the 25 x 80 DOS displays.