fbpx
Welcome, Guest
Username: Password: Remember me
Welcome to the XSharp forum!

Tell us and our members who you are, what you like and why you became a member of this site.
We welcome all new members and hope to see you around a lot!
  • Page:
  • 1
  • 2

TOPIC: Visual FoxPro, how close is X# to compiling it already?

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7496

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi all (including VFP lurkers),
I am following all the XBase languages, to just have an idea of what is happening in the XBase world. Although there are certain syntax differences between lets call it the Clipper and Foxbase forks, we still have the DBase programming language as basis.

Obviously the VFP language pack is still not available and DBF drivers not complete, which will greatly enhance a "Transport".

I saw an example on the ProFox forum ( leafe.com/dls/vfp ) to validate if a TextFile is UTF8 compliant and thought it might be a good example to try and convert with the least amount of changes to be X# compiled.

I decided after reviewing the code it should not be too difficult and set myself the following mandate:
  • Touch the original ValidateUTF() code as little as possible, except syntax differences that can be done with a Replace all e.g. "&&" to "//&&" etc.
  • Write any VFP functions called in the example from scratch that is not found by the XSharp compiler even if found with a different name in the XSharp Runtime functions, e.g. SUBSTRC is available as SUBSTR, SUBSTR2, SUBSTR3. Wrap around .NET available features, there are millions!
Here are the timed steps and resulting VFP to XSharp code that runs on the .NET Framework:
  1. Add FUNCTION Start() around test code.
  2. Replace "&&" with "//&&", "m." with "", "=" with ":=", " OR " with " .OR. ", " AND " with " .AND. "
  3. Replace ENDFUNC with RETURN where necessary
  4. Scan through code and change ":=" in conditional statements back to "=" // WHILE, IF, CASE statements. Assignment in X# is done with ":=", "+=", "++" etc, while "=", "==" are comparison operators.
  5. Compile, respond to errors "No BITAND, BITOR, BITLSHIFT, FILETOSTR, ASC, SUBSTRC, LENC functions", create functions
  6. Strict type variables, add "AS <Type>" to LOCAL declarations, FUNCTION parameters. Not necessary, but speed improvement is HUGE if done instead of using variable type declarations, e.g. LOCAL x translates to LOCAL x AS USUAL, compared to LOCAL x AS INT or VAR x := 0 will be strict typed by XSharp to an INT.
  7. Compile successfully
  8. Test successful. 100% XSharp compiled and executed with correct results!
Here is the resulting code, original code can be found at the link provided above if somebody is interested:
/*
************************************************************************
***  UTF-8 string check validity function
*** Version 1.0 - 12-20-2016
************************************************************************
***    José Enrique Llopis
***    jellopis@rocketmail.com www.multilinkcrm.com
***    My online résumé https://es.linkedin.com/in/pepellopis
***    Alicante – Spain
************************************************************************/

FUNCTION Start( ) AS VOID // The entry point to all X# applications
    LOCAL lcString AS STRING
    lcString := FILETOSTR( "Spanish_Text.txt")
    ? ValidateUtf8( lcString )
    lcString = FILETOSTR( "good.txt")     // *** Russian cyrillic utf8 text
    ? ValidateUtf8( lcString )
    lcString = FILETOSTR( "bad.txt")
    ? ValidateUtf8( lcString )
RETURN

FUNCTION  ValidateUtf8( tcBuffer AS STRING ) AS LOGIC
    LOCAL lcCharPoint AS STRING
    LOCAL lnBufferLen, lnCounter, lnCodepointValue AS INT
    // m.lcByteInicial    := SUBSTRC( tcBuffer, 1) // Assigned, never used, only 2 parameters typo? X# compiler warning
    // m.lcByteFinal    := SUBSTRC( tcBuffer, LENC(tcBuffer), 1 ) // Assigned, never used. X# compiler warning
    lnBufferLen := LENC( tcBuffer )
    lnCounter := 1
    DO WHILE lnCounter <= lnBufferLen
        lcCharPoint := SUBSTRC( tcBuffer, lnCounter, 1 )
        IF Asc( lcCharPoint) < 128    //&& Single BYTE codepoint
            lnCounter := lnCounter + 1 // lnCounter++ in XSharp
            LOOP
        ENDIF
        DO CASE
            CASE BITAND( Asc( lcCharPoint ), 0xE0 ) = 0xC0 //&& Two bytes codepoint
                IF lnCounter + 1 > lnBufferLen
                    RETURN .F.
                ENDIF
                //&& Check FOR overlong form (8th or above data bit must be set)
                IF BITAND( Asc( lcCharPoint ), 0x1E ) = 0
                    RETURN .F.
                ENDIF
                //&& Check continuation BYTE
                IF BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+1, 1 )), 0xC0 ) <> 0x80
                    RETURN .F.
                ENDIF
                //&& Don't have to check code point validity. Can't have a large
                //&& enough value TO be one of the invalid ones.
                lnCounter := lnCounter + 2 // X# syntax lnCounter += 2
                LOOP
            CASE BITAND( Asc( lcCharPoint ), 0xF0 ) = 0xE0 //&& Three bytes codepoint
                IF lnCounter + 2 > lnBufferLen
                    RETURN .F.
                ENDIF
                //&& Check continuation BYTE
                IF     ( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+1, 1 )), 0xC0 ) <> 0x80 ) .OR. ; //X# "||" for "OR", alternative ".OR."
                    ( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+2, 1 )), 0xC0 ) <> 0x80 )
                    RETURN .F.
                ENDIF
                //&& Convert TO code point
                lnCodepointValue := BITOR( ;
                        BITLSHIFT( BITAND( Asc( lcCharPoint), 0x0F), 12 ), ;
                        BITLSHIFT( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+1, 1 )), 0x3F ), 6 ), ;
                        BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+2, 1 )), 0x3F ) ;
                    )
                //&& Check FOR overlong form (11th or above data bit must be set)
                //&& FOR example, U+0020 IS represented IN UTF-8 by the single BYTE 0x20. IF you decode the
                //&& two bytes 0xc0 0xa0 IN the normal fashion, you'll still end up back at U+0020, but that's an invalid representation.
                IF lnCodepointValue < BITLSHIFT( 1,11)
                    RETURN .F.
                ENDIF
                //&&  Check code point legality.
              IF isValidCodePoint( lnCodepointValue ) = .F.
                    RETURN .F.
                ENDIF
                lnCounter := lnCounter + 3 // X# syntax lnCounter += 3
                LOOP
            CASE BITAND( Asc( lcCharPoint ), 0xF8 ) = 0xF0 //&& four bytes codepoint
                IF lnCounter + 3 > lnBufferLen
                    RETURN .F.
                ENDIF
                //&& Check continuation BYTE
                IF     ( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+1, 1 )), 0xC0 ) <> 0x80 ) .OR. ;
                        ( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+2, 1 )), 0xC0 ) <> 0x80 ) .OR. ;
                        ( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+3, 1 )), 0xC0 ) <> 0x80 )
                    RETURN .F.
                ENDIF
                //&& Convert TO code point
                lnCodepointValue := BITOR( ;
                        BITLSHIFT( BITAND( Asc( lcCharPoint), 0x07), 18 ), ;
                        BITLSHIFT( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+1, 1 )), 0x3F ), 12 ), ;
                        BITLSHIFT( BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+2, 1 )), 0x3F ), 12 ), ;
                        BITAND( Asc(SUBSTRC( tcBuffer, lnCounter+3, 1 )), 0x3F ) ;
                    )
                //&& Check FOR overlong form (11th or above data bit must be set)
                IF lnCodepointValue < BITLSHIFT( 1,11)
                    RETURN .F.
                ENDIF
                //&&  Check code point legality.
              IF isValidCodePoint( lnCodepointValue ) = .F.
                     RETURN .F.
                 ENDIF
                lnCounter := lnCounter + 4 // X# syntax lnCOunter += 4
                LOOP
            OTHERWISE        //&& Invalid length, or not start BYTE
                RETURN .F.
        ENDCASE
    ENDDO
RETURN .T.

FUNCTION  isValidCodePoint( tnCodePoint AS INT) AS LOGIC
    LOCAL lValid AS LOGIC
    IF ( tnCodePoint >= 0xD800 ) .AND. ( tnCodePoint <= 0xDFFF )  // Surrogates
        lValid := FALSE
    ELSE
        lValid := tnCodePoint  <= 0x10FFFF //   Maximum value
    ENDIF
RETURN lValid

// VFP functions not in X# Runtime Funcs or with alternative name
FUNCTION FILETOSTR(name AS STRING) AS STRING
    VAR oFS := System.IO.FileStream{name, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read}
    VAR oRdr := System.IO.StreamReader{oFS} // X# also recognize StreamReader(oFS) for creating objects
    VAR content := oRdr:ReadToEnd() // X# also recognize oRdr.ReadToEnd()
    oFS:Close()
    oRdr:Close()
RETURN content

FUNCTION SUBSTRC(s AS STRING, iOffSet AS INT, iCount AS INT) AS STRING
    // Note .NET Strings are Zero indexed
RETURN s:Substring(iOffSet - 1, iCount)

FUNCTION SUBSTRC(s AS STRING, iOffSet AS INT) AS STRING
    // Note .NET Strings are Zero indexed
RETURN s:Substring(iOffSet - 1)

FUNCTION LENC(s AS STRING) AS INT
RETURN s:Length

FUNCTION ASC(s AS STRING) AS INT
RETURN (INT)(BYTE)s[0] // Strings are array of Char.  We can cast Char to Byte and Byte to Int

FUNCTION BITAND(iV1 AS INT, iV2 AS INT) AS INT
RETURN _And(iV1, iV2)

//FUNCTION BITAND(iV1 AS INT, iV2 AS INT, iV3 AS INT) AS INT
//RETURN iV1 & iV2 & iV3 // The short for unary AND operations.

FUNCTION BITOR(iV1 AS INT, iV2 AS INT) AS INT
RETURN _Or(iV1, iV2)

FUNCTION BITOR(iV1 AS INT, iV2 AS INT, iV3 AS INT) AS INT
RETURN iV1 | iV2 | iV3 // Three parameter overloaded function for BITOR using XSharp/.NET syntax

FUNCTION BITOR(iV1 AS INT, iV2 AS INT, iV3 AS INT, iV4 AS INT) AS INT
RETURN iV1 | iV2 | iV3 | iV4 // Four parameter overload of BITOR

FUNCTION BITLSHIFT(iValue AS INT, iShift AS INT) AS INT
RETURN iValue << iShift

//FUNCTION BITRSHIFT(iValue AS INT, iShift AS INT) AS INT
//RETURN iValue >> iShift // We probably going to need this function in the future?

// End of conversion 

The whole process took me about 45 minutes.

Please bear with me and don't ask Why you did this or not that rather. This was just an example as a CRUDE, No RTFuncs included.

If there is interest, I will do a follow up posting with it in a more X# style, e.g. BITOR/BITAND replaced by "|" and "&".

Hope this interest some,
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7502

  Karl-Heinz's Avatar Karl-Heinz Offline Posts: 321
Hi Johan,

VFP is a weakly typed language. VFP knows LOCALs, but they are untyped.


LOCAL x

// now use the local just like in the good old clipper days :-)

? VALTYPE(x) // "U"

x:= 12

? VALTYPE(x) // "N"

x := "Johan"

? VALTYPE(x) // "C"


Here´s a overview how the VFP parameter declaration works:

[...]

First there is the implicit declaration
FUNCTION Name( parameter_name1, parameter_name2 )
Parameters created this way are scoped as LOCAL and so are usable only in the method, procedure or function that defines them.

Second is the Explicit Declaration, using the LPARAMETERS keyword, like this:
FUNCTION Name
LPARAMETERS parameter_name1, parameter_name2
Parameters created this way are also scoped as LOCAL and so are usable only in the method, procedure or function that defines them.

Third is the Explicit Declaration, using the PARAMETERS keyword, like this:
FUNCTION Name
PARAMETERS parameter_name1, parameter_name2
Parameters created this way are also scoped as PRIVATE and so are usable in the method, procedure or function that defines them and in any subordinate (i.e. called from) method, procedure or function

[...]

regards
Karl-Heinz

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7503

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Karl-Heinz,
I am with you, but I remember the days of moving from Clipper to VO. I think VFP->X# is closer than Clipper->VO
I just posted this seeing that there was some interest in the VFP forums. With VFP to be the next focus on language syntax, I just tried to show it is already to some extend possible. And with the support that we got used to in our community I am sure there would be more than enough support for VFP guys to make the transition.
Regards,
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7504

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Karl-Heinz,
Sorry things like the PARAMETER/LPARAMETER can quickly be fixed with a #command created in a VFP.xh file and included or added to the standard .xh files...

I will in a follow up post how this can be used to further ease a transition.

Regards,
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7506

  Karl-Heinz's Avatar Karl-Heinz Offline Posts: 321
Hi Johan,

i think the VFP user base is larger than the Xbase++ community. Over the years some attempts have been made to move VFP to .net, but all silently died. Also, Alaska (Xbase++) announced years ago a PolarFox version, but nothing happened till now.

Here are some VFP -> .net links:

social.msdn.microsoft.com/Forums/en-US/9...=visualfoxprogeneral

archive.codeplex.com/?p=visualfoxpronet

guineu.foxpert.com/

a interesting side from the Guineu maker with some VFP inside views.

www.foxpert.com/foxpro/

-> Whitepapers
-> Downloads

Would be interesting if some of the daily VFP users would jump in, and explain the current situation..


regards
Karl-Heinz

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7507

  wriedmann's Avatar wriedmann Offline Posts: 1678
Hi Johan, hi Karl-Heinz,
FoxPro is not only the compiler, but has also a lot of functionality in the runtime, and an advanced DBFCDX RDD.

IMHO it is a challenge to make the X# compiler compile Foxpro code, but a much greater challenge to rebuild all the functionality of the runtime.
Without a strong interest of the VFP community (and the respective manpower) it will be hard to build something compatible.
Maybe the Foxpert guy or other developers are interested to contribute....

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7508

  NEE4NEE's Avatar NEE4NEE Offline Posts: 4
useful discussion
How To Help Clipper & Foxpro Users Catch Harbour
Discussion is here...

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7509

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Wolfgang,
I do agree, but a lot of VFP code I see does not use DBF anymore, hence it will make the move easier. The functionality I believe can quickly be added if we as a supportive community stand up and assist.
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7512

  wriedmann's Avatar wriedmann Offline Posts: 1678
Hi Johan,

after looking at Xbase++ code I have realized how far the VO language has been gone from Clipper, and what strong typing has added as both speed enhancement and safer code - I would never miss it.

But nevertheless also the other Xbase languages have evolved, but IMHO more on support and runtime libraries. At least FoxPro has a powerful GUI library, and I have my doubts, that the sources are available.
And I'm pretty sure most applications are using the DBFCDX database access.

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7515

  alanbourke's Avatar alanbourke Offline Posts: 3
You can specify a type:

Local loBool as Boolean

However that is just a hint for Intellisense and is not enforced, for example you could still say:

loBool = "Hello"

The Visual FoxPro syntax is not really that much like the Clipper-like languages and never has been.

In terms of replicating the Visual FoxPro runtime, yes you would absolutely need native support for DBF and CDX, database containers and the rest. You could also probably drop 50% of the functions listed in the VFP help file as they were only there for FoxPro 2.x and DBase compatibility. Nobody in this day and age is using @ .. SAY for example.

Also anyone wanting an existing platform that handles VFP code could have a look at Lianja.

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

Last edit: by alanbourke.

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7516

  wriedmann's Avatar wriedmann Offline Posts: 1678
Hi Alan,
as I wrote: the guys behind X# have a Clipper/Visual Objects background and have done really a great work to transport the language to .NET using the Roslyn sources. Currently they are working on an open source DBFCDX database layer in X# itself, but for sure limited to what Visual Objects needs.
To have the functionality you VFP guys need, they need your help, in knowledge, manpower and money.
For me it is unthinkable to rewrite all my applications in another language as I have about 2,5 millions of lines of code, and therefore for me (and many other people) the success of this project is very important, so I have decided to support it where I can with my limited resources.
And if the VFP community (or a part of it) realizes that this project can save a lot of time and money, and decides to contribute, this can become also a way to the future for many VFP applications.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7517

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Alan,

alanbourke wrote: In terms of replicating the Visual FoxPro runtime, yes you would absolutely need native support for DBF and CDX, database containers and the rest. You could also probably drop 50% of the functions listed in the VFP help file as they were only there for FoxPro 2.x and DBase compatibility. Nobody in this day and age is using @ .. SAY for example.
Also anyone wanting an existing platform that handles VFP code could have a look at Lianja.

Thank you, where are you currently standing with development? Using X# or just lurking?

But I believe we need more "action" from the VFP guys on this forum. I have asked Robert to consider a VFP Forum where these discussions can take place instead of cluttering the Welcome forum.

Thanks for jumping in.

XBase greetings,
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7518

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Karl-Heinz,

Karl-Heinz wrote: i think the VFP user base is larger than the Xbase++ community. Over the years some attempts have been made to move VFP to .net, but all silently died. Also, Alaska (Xbase++) announced years ago a PolarFox version, but nothing happened till now.

I agree all of them silently died, even in the links you provided. The problem was with all these attempts they tried to use VFP to write VFP.NET (Cule.NET comes to mind using VO) or they were too small and tried to write a compiler from scratch (Vulcan went the same route) it is a catch up game the whole time. Luckily Robert had a forward looking vision, and we know where we as community stand. X# is not a "catch-up" compiler, it is on par and I believe in some instances far ahead of c#.

Here are some VFP -> .net links:

<VFP Hat:On>I went to each of those links and search for exciting news.</VFP Hat:Off>
Unfortunately knowing X#, it is almost impossible, they all give me the impression that everybody is feeling pessimistic. You make a change to c#/VB.NET/Delphi or other maintained language, otherwise hopefully the VFP work will only dry up after my retirement...

From all the ranting on about VFP and .NET, here is a blog that I did found interesting, just a pity the user did not share on any VFP forums that I know of, but preferred to post it on his personal webpage:

Monday, February 12, 2018
Managed Dbf using X# Language in VS2017
I tried using X# Language within Visual Studio 2017 and it's like writing CLIPPER using Visual Studio with all the bells and whistles of the .NET framework of course ?
Check out X Sharp : www.xsharp.info/

Unfortunately he has not yet "complete" his open source project ManagedDbf which interface to VFP9.0 fox DBF and most XBase dbf styles, so it is still not available, but it seems promising. Will try and contact and ask if he would be willing to make it available as is. We can always assist in further development.

The other I found promising:

Guineu The FoxPro runtime

Guineu is an opensource alternative runtime library for Microsoft Visual FoxPro® 9.0 that runs on any Microsoft .NET compatible platform.


In conclusion, I think the XBase community in general need to make the decision:
  1. Stay in their specific XBase [dis]continued world hoping to survive
  2. Move to a totally new development language e.g. c#, Delphi, VB.NET
  3. Make a commitment to a future in XBase and leverage their XBase investment making use of all the additional features available in X#
  4. We know most of us reading this has made point 3 our decision

Would be interesting if some of the daily VFP users would jump in, and explain the current situation..

I agree, we not having Geoff around anymore that might go out bashing everybody. We are a supportive community. I would love to hear VFP user experiences, I do believe there might be some very useful tips/tricks that we all can learn from and hopefully include in our Tools library (X# converted though) :)

Just my 2c...
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7519

  Jamal's Avatar Jamal Offline Posts: 130
I see one of challenges is the use of the dot notation for accessing methods and properties, etc and the equal sign:

For example:

FoxPro:
txtTest.Value = "Some text..."

In X# and VO:

txtTest:Value := "Some text..."

Since I develop mainly in C# and VO, sometimes my mind forgets which language I am using and I get mixed up between the dot and the colon! Arragghh! I mentioned it before the X# team even the Vulcan team, that the dot notation should be an option; so here we go if FoxPro syntax is to be implemented.

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7520

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Jamal,

Jamal wrote: I see one of challenges is the use of the dot notation for accessing methods and properties, etc and the equal sign:
For example:
FoxPro:
txtTest.Value = "Some text..."
In X# and VO:
txtTest:Value := "Some text..."
Since I develop mainly in C# and VO, sometimes my mind forgets which language I am using and I get mixed up between the dot and the colon! Arragghh! I mentioned it before the X# team even the Vulcan team, that the dot notation should be an option; so here we go if FoxPro syntax is to be implemented.

The assignment operator = is maybe the "biggest" problem, but as I mentioned in my example can be fixed with a simple Replace in the IDE. Going then through IF/CASE/WHILE manually and replace ":=" back to "=", "==" where applicable is not that big a train smash.
The "." vs ":" is although Robert/Chris need to confirm, is already addressed if I remember correctly.
The compiler even recognize ArrayList() instead of ArrayList{}. You get a problem when you have a static class method with the same name as a class method, when the compiler cannot distinguish which method to use.
STATIC METHOD SubStr(cStr AS STRING, iOffSet AS INT, iLen AS INT) AS STRING
METHOD SubStr(cStr AS STRING, iOffSet AS INT, iLen AS INT) AS STRING
METHOD SubStr(iOffSet AS INT, iLen AS INT) AS STRING
Maybe not a good example, but don't have my hands now on the forum example where this type of behaviour caused an issue.

I do now there are more to implementing a VFP syntax, but for "business" logic what I have described, should be a 85+% match. Considering some "experts" advocate VFP users to move to c#/VB.NET and drop DBF. That is a 100% touch of code and redesigning the GUI. Yes at the moment you need to redesign your GUI and drop DBF use, still a lot less than changing to c#/VB.NET. If you already on SQL the conversion is easier. The team have and will provide a DBF RDD.

But if you not on DBF, I think conversion to X# should be high priority, even if you just start converting your business processes to be ready when the DBF RDD is fully featured. I have found some promising VFP tools that I will take up with Robert and discuss.

Regards,
______________________
Johan Nel
George, South Africa

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

Last edit: by lumberjack.

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7521

  Karl-Heinz's Avatar Karl-Heinz Offline Posts: 321
Hi Johan,

if you want to know more about the VFP commands, syntax etc., here´s the link to the VFP9 SP2 help file:

github.com/VFPX/HelpFile

or the direct download link:

github.com/VFPX/HelpFile/raw/master/setu...v1.08.exe_signed.zip

@Wolfgang
As you did already mention: The main problem is to *which* GUI-lib preprocessed commands like:

DEFINE POPUP popFruits FROM 5,5 ;
   MULTISELECT MARGIN            && Create multi-choice menu
DEFINE BAR 1 OF popFruits ;
   PROMPT '\<Apples'  MARK CHR(3)    && First item
DEFINE BAR 2 OF popFruits ;
   PROMPT '\<Bananas' MARK CHR(4)    && Second item
DEFINE BAR 3 OF popFruits ;
   PROMPT '\<Grapes'  MARK CHR(5) && Third item
DEFINE BAR 4 OF popFruits ;
   PROMPT '\<Lemons'  MARK CHR(6)    && Fourth item
ON SELECTION POPUP popFruits DO yourchoice    && Choice routine
ACTIVATE POPUP popFruits 

finally point to ...


@Alan

i´ve looked at lianja. It´s a cross-platform tool that understands the VFP syntax. But i don´t find any hint about .net ?

www.lianja.com/community/lianja-for-vfp-developers

regards
Karl-Heinz

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7523

  alanbourke's Avatar alanbourke Offline Posts: 3
Lianja just compiles to native EXE files, I just mentioned it as an example of something that is out there now which more or less supports Visual FoxPro syntax.

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7524

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Karl-Heinz,

Karl-Heinz wrote: Johan,
if you want to know more about the VFP commands, syntax etc., here´s the link to the VFP9 SP2 help file:

Yes I am constantly browsing what is available in VFP and know this site. It was one of the reasons why I did this initial post, I think X# is close to VFP compilation.

@Wolfgang
As you did already mention: The main problem is to *which* GUI-lib preprocessed commands like:

DEFINE POPUP popFruits FROM 5,5 ;
   MULTISELECT MARGIN            && Create multi-choice menu
DEFINE BAR 1 OF popFruits ;
   PROMPT '\<Apples'  MARK CHR(3)    && First item
ON SELECTION POPUP popFruits DO yourchoice    && Choice routine
ACTIVATE POPUP popFruits 

This is the type of commands that excite me extremely:
#command DEFINE POPUP <cls> [FROM <x>, <y>]   [MULTISELECT] [MARGIN] => ;
  VAR <cls> := System.Windows.Forms.ContextMenu{}

#command DEFINE BAR <n> OF <owner>   PROMPT <prompt>  [MARK <chr>] => ;
  VAR bar<n> := System.Windows.Forms.MenuItem{<prompt>};;
  <owner>:Add(bar<n>)

#command ON SELECTION POPUP <popMenu> DO <yourchoice>  => ;
  <popMenu>:Click += <yourchoice>

#command ACTIVATE POPUP <pop> => ;
  SELF:ContextMenu := <pop>
Voila, I think I have just enhanced X# to have native support for VFP style popup menus.

Obviously it need some more attention, but it just again highlight the POWER of X#!

I rest my case.
______________________
Johan Nel
George, South Africa

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7527

  Karl-Heinz's Avatar Karl-Heinz Offline Posts: 321
Hi Johan,

yes, it looks exciting !

But i think what´s needed is a lib with wrapper classes around the required parts of the .net framework. This can IMO only be done by experienced VFP people who excatly know what all these VFP Commands finally initiate. Another todo is IMO to replace e.g. the form files .scx and .sct - which are a pair of a DBF and a memo file where the Painter stores the Form settings-, with pure text files.

regards
Karl-Hinz

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

Visual FoxPro, how close is X# to compiling it already? 5 months 2 weeks ago #7528

  lumberjack's Avatar Topic Author lumberjack Offline Posts: 513
Hi Karl-Heinz,

Karl-Heinz wrote: But i think what´s needed is a lib with wrapper classes around the required parts of the .net framework.

I am getting more excited actually!

This can IMO only be done by experienced VFP people who exactly know what all these VFP Commands finally initiate.

Well, many of those commands are already in the X# (compiler resolved) or in the *.xh header files as #commands.

Another todo is IMO to replace e.g. the form files .scx and .sct - which are a pair of a DBF and a memo file where the Painter stores the Form settings-, with pure text files.

Don't spill the beans on how easy it should actually be if those files are in a sort of Relation... It means there are consistency standards. To write a simple VFPScreenTransporter -> X# code... :P

Regards,
______________________
Johan Nel
George, South Africa

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

Last edit: by lumberjack.
  • Page:
  • 1
  • 2