fbpx

CRLF

  • Otto Christiaanse
  • Otto Christiaanse's Avatar Topic Author
  • Offline
More
2 years 4 months ago - 2 years 4 months ago #1 by Otto Christiaanse
CRLF was created by Otto Christiaanse
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
Last edit: 2 years 4 months ago by Otto Christiaanse.

Please Log in or Create an account to join the conversation.

More
2 years 4 months ago #2 by Robert van der Hulst
Replied by Robert van der Hulst on topic CRLF
Otto,

CRLF is a define, defined in "VulcanStdDefs.vh" :
#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:
#define CRLF e"\r\n"

Robert

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
2 years 4 months ago #3 by Chris Pyrgas
Replied by Chris Pyrgas on topic CRLF
Hi Otto,

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

GLOBAL CRLF := e"\r\n" 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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

  • Otto Christiaanse
  • Otto Christiaanse's Avatar Topic Author
  • Offline
More
2 years 4 months ago #4 by Otto Christiaanse
Replied by Otto Christiaanse on topic CRLF
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

Please Log in or Create an account to join the conversation.

More
2 years 4 months ago #5 by Johan Nel
Replied by Johan Nel on topic CRLF
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

______________________
Johan Nel
George, South Africa

Please Log in or Create an account to join the conversation.

More
2 years 4 months ago #6 by Robert van der Hulst
Replied by Robert van der Hulst on topic CRLF
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).
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 Cdsk\Include folder of your VO installation:
#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
 

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
2 years 4 months ago #7 by Robert van der Hulst
Replied by Robert van der Hulst on topic CRLF
Otto,

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

Robert

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

  • Otto Christiaanse
  • Otto Christiaanse's Avatar Topic Author
  • Offline
More
2 years 4 months ago #8 by Otto Christiaanse
Replied by Otto Christiaanse on topic CRLF
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.

Please Log in or Create an account to join the conversation.