CRLF

[Otto]

Just pasted some code from Vulcan.NET to XSharp.
Now I don't get the CRLF to compile.

I tried XSharp dialects Visual Objects, Vulcan.NET and Core , but to no avail.

Must be something simple like missing a reference, but I don't see it...

Regards,
Otto

[robert]

Otto,

CRLF is a define, defined in "VulcanStdDefs.vh" :

Code: Select all

#define CRLF chr(13)+chr(10)

We are not picking up this StdDefs.vh (yet ?)

For the next build we plan to include our own stddefs, and gues what: this file contains:

Code: Select all

#define CRLF e"rn"

Robert

[Chris]

Hi Otto,

In addition to what Robert said, as a temp workaround for now I'd suggest just adding a

GLOBAL CRLF := e"rn" AS STRING

in your base dll, so you will not need to make any other change in your code. That's what I've been using for testing purposes for some time now. Later you can simply remove that one line.

Chris

[Otto]

Thanks!

maybe a question for another thread, but what to do with code like:

uValue := IVarInfo.GetFieldValue(SELF, oField)
dwVarType := UsualType(uValue)
DO CASE
CASE dwVarType == LONGINT
// ... bla
CASE dwVarType == DATE
// ... bla
CASE dwVarType == FLOAT
// ... bla
CASE dwVarType == STRING
// ... bla
CASE dwVarType == LOGIC
// ... bla
ENDCASE

(... other than redesigning it...)
the compiler complains:
'int' is a type, which is not valid in the given context
'__VODate' is a type, which is not valid in the given context
etc

Is this something I can fix by adding some define etc?

Regards,
Otto

[lumberjack]

Otto,

In .net I would suggest you make use of the typeof() function

LOCAL typ AS Type
typ := <var>:GetType()
CASE typ == typeof(INT)
etc...

HTH,

Lumberjack

[robert]

Otto,

I agree with 'Lumberjack' here: using Typeof() is better.

The usage of keywords as both a type and a number (which is what VO and Vulcan do) is really a nightmare. It should have been something like UsualType.LONG and UsualType.STRING.
Now if you want to keep using the old code, then I suggest you add a enum and compare with that.
In fact: inside the VulcanRTFuncs there is already an enum, but unfortunately is is internal.
With Reflector and the XSharp Plugin from Fabrice I could extract the following code for the Enum.
Please note that there are some holes in the list. This is on purpose. These types exist but are not supported as values inside a USUAL, such as for example DWORD (which is number 14).

Code: Select all

INTERNAL ENUM UsualType AS Long
    MEMBER @@NIL:=0
    MEMBER INT:=1
    MEMBER @@DATE:=2
    MEMBER FLOAT:=3
    MEMBER @@ARRAY:=5
    MEMBER @@OBJECT:=6
    MEMBER STRING:=7
    MEMBER LOGIC:=8
    MEMBER CODEBLOCK:=9
    MEMBER SYMBOL:=10
    MEMBER PSZ:=17
    MEMBER @@PTR:=18
    MEMBER INT64:=22
END ENUM

The numbers match the type numbers from VO that you can find in basetype.vh in the CdskInclude folder of your VO installation:

Code: Select all

#define BT_VOID         0       // == NIL
#define BT_LONG         1       // signed long
#define BT_DATE         2       //
#define BT_FLOAT        3       // internal real format
#define BT_FIXED        4       // internal fixed format
#define BT_ARRAY        5       // array (ptr)
#define BT_OP           6       // object pointer
#define BT_STR          7       // string
#define BT_LOGIC        8
#define BT_CODE         9       // code block
#define BT_SYMBOL       10      // atom nr in symbol atom table

#define BT_BYTE         11      // byte
#define BT_INT          12      // signed int
#define BT_WORD         13      // word
#define BT_DWORD        14      // dword
#define BT_REAL4        15      // C float
#define BT_REAL8        16      // C double
#define BT_PSZ          17      // PSZ
#define BT_PTR          18      // raw ptr
#define BT_POLY         19      // polymorphic


#define BT_MAX          BT_POLY
#define BT_LIMIT        20
 

[robert]

Otto,

I looked at this again, and it was not that difficult to add this to the compiler, so I did.

Robert

[Otto]

Again thanks!

I would gladly rewrite the existing code to what .NET would want us to do. And we will in time.

For now the enum like solution, or a native solution in the XSharp compiler or an automated transport tool would be (in my opinion) make life easier for VO to XSharp converting developers.

Looking forward to the result of the current (and next) iteration(s) of the compiler.