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? 04 Mar 2019 14:18 #7496

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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
    ***     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? 04 Mar 2019 20:05 #7502

  • Karl-Heinz's Avatar

  • Karl-Heinz


  • Posts: 550
  • 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? 04 Mar 2019 20:29 #7503

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 04 Mar 2019 20:33 #7504

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 04 Mar 2019 21:57 #7506

  • Karl-Heinz's Avatar

  • Karl-Heinz


  • Posts: 550
  • 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? 05 Mar 2019 07:41 #7507

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2232
  • 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

    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? 05 Mar 2019 07:48 #7508

  • NEE4NEE's Avatar

  • NEE4NEE


  • 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? 05 Mar 2019 07:55 #7509

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 05 Mar 2019 09:40 #7512

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2232
  • 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

    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? 05 Mar 2019 13:22 #7515

  • alanbourke's Avatar

  • alanbourke


  • Posts: 20
  • 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? 05 Mar 2019 13:38 #7516

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2232
  • 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

    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? 05 Mar 2019 14:27 #7517

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 05 Mar 2019 16:50 #7518

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 05 Mar 2019 20:27 #7519

  • Jamal's Avatar

  • Jamal


  • Posts: 197
  • 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? 05 Mar 2019 20:50 #7520

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 06 Mar 2019 09:31 #7521

  • Karl-Heinz's Avatar

  • Karl-Heinz


  • Posts: 550
  • 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? 06 Mar 2019 09:58 #7523

  • alanbourke's Avatar

  • alanbourke


  • Posts: 20
  • 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? 06 Mar 2019 11:08 #7524

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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? 06 Mar 2019 17:05 #7527

  • Karl-Heinz's Avatar

  • Karl-Heinz


  • Posts: 550
  • 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? 06 Mar 2019 17:22 #7528

  • lumberjack's Avatar

  • lumberjack

  • Topic Author


  • Posts: 680
  • 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