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

[wriedmann]

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

[lumberjack]

Hi Alan,

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,

[lumberjack]

Hi Karl-Heinz,

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 : https://www.xsharp.eu/

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:
[*]
[*]Stay in their specific XBase [dis]continued world hoping to survive
[*]Move to a totally new development language e.g. c#, Delphi, VB.NET
[*]Make a commitment to a future in XBase and leverage their XBase investment making use of all the additional features available in X#
[*]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...

[Jamal]

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.

[lumberjack]

Hi Jamal,

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.

Code: Select all

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,

[Karl-Heinz]

Hi Johan,

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

https://github.com/VFPX/HelpFile

or the direct download link:

https://github.com/VFPX/HelpFile/raw/ma ... signed.zip

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

Code: Select all

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 ?

https://www.lianja.com/community/lianja ... developers

regards
Karl-Heinz

[alanbourke]

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.

[lumberjack]

Hi Karl-Heinz,

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:

Code: Select all

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:

Code: Select all

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

[Karl-Heinz]

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

[lumberjack]

Hi Karl-Heinz,

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

Regards,