xsharp.eu

Hi,
This is my first attempt at trying to compile some VFP code and I will list some initial errors that the compiler produces.
I have tried to find documentation that would indicate if these are supported or unsupported VFP syntax, but I either see no mention of it or perhaps a mention related to VO instead - if there is a definitive and recent list of unsupported syntax or an FAQ on unsupported coding patterns then please let me know where to look.
[*]
[*] - error XS9003: Pre-processor: String literal expected 1,10 tlcvfptools.prg
I changed this to and that error goes away, but I still get this error :
- error XS1025: Single-line comment or end-of-line expected 1,17 tlcvfptools.prg
It appears that the compiler understands .h files (#defines), because it produced some errors about those files that I cleared up; but I'm not sure how to include them into .prg files

[*] - error XS1003: Syntax error, 'END[DO]' expected 54,2 AddIndexTags.prg AddIndexTags
Error on the last line - the VFP syntax is correct, it is just an if/endif block; but the compiler is expecting something else?

[*] - error XS9002: Parser: unexpected input 'memowidth' 25,5 AddIndexTags.prg AddIndexTags
I thought I read somewhere that set memowidth is supported?

[*] - error XS9002: Parser: unexpected input 'DBF' 35,6 CreateIndex.prg CreateIndex
Perhaps dbf() is not yet supported?

[*] - error XS1003: Syntax error, 'END[IF]' expected 50,89 CreateIndex.prg CreateIndex
This error occurs on the line.
Perhaps the compiler doesn't like the macro on the line preceding it?

[*] - error XS1003: Syntax error, 'END[IF]' expected 606,2 tlctools.prg UpdateReptID
Perhaps is not yet supported?

[*] - error XS9002: Parser: unexpected input 'From' 77,30 tlcvfptools.prg DBFToCursor
Perhaps SQL Select with a macro substitution is not supported? (But if I remove the macro, the compiler complains about the word "into" instead...)

[*] - error XS9002: Parser: unexpected input 'NewCursorAdapterObject' 59,12 UseViewNoRequery.prg UseViewNoRequery
This error relates to the final line, where a variable is being released.

[*] - error XS9003: Pre-processor: Identifier expected 6,9 tlctools.prg
There are several other #defines before this one, but the compiler does not like this one.



Thanks.
Paul

RajNZ wrote:

Code: Select all

If NumberOfObjects > 0
		For Each CurrentMember In MemberArray
			TheCurrentObject = "TheDataEnvironment." + CurrentMember
			If pemstatus(&TheCurrentObject, "cursorsource", 5) And pemstatus(&TheCurrentObject, "exclusive", 5) And &TheCurrentObject..exclusive
				Do AddIndexTags With &TheCurrentObject..alias, &TheCurrentObject..alias, "IndexList"
			EndIf
		EndFor
	EndIf

Operations with objects is much better operations with object names.

9.
#DEFINE NULL chr(0)

Null is reserved word with own very spescific semantic.

Hello Paul.

I see a lot of X1003 errors. I had one saying Syntax error, 'NEXT' expected

In this case it was simply caused because a comment after the closing ENDIF was without //.
I can recommend that you watch the session of Chris (https://www.youtube.com/watch?v=A-zhcsYuas8) where he explains the cause of all kind of conversion errors. Also this XS1003. In Chris' session it was:
Syntax error END[CASE] Expected

which should be either END or ENDCASE, without a space.

So many of these errors occur because a line ends with something unexpected, because an incorrect keyword is used, e.g. with a space in it, or comment is not preceded by //

Dick

Hi Paul,

Thanks for your reports! Those issues are due to either some VFP functionality still missing, or because the functionality is implemented as functions but not as commands yet, or that some functionality is not supported in the form of your code - for example indeed the problem with "set filter To &OldFilter" is that the macro operator is not supported in it right now.

Some of that is because VFP support in X# is still heavy work in progress, so many things are still not implemented/supported, but some other cases it's because we simply were not aware of those cases and syntax variations. I will log them all, so that they will all be working in a future X# release. In the meantime, can you please send the PROGRAM.h file? I suspect some of the definitions of commands you are using are included in it.

Regarding NULL specifically, it is indeed a keyword in X#, so it is not a good idea redefining it like that.

Thanks Chris,
Without knowing exactly what is and what is not supported will make a conversion difficult at the moment. What I am trying to determine is whether it is feasible to convert parts of our large VFP project to X# and while I can possibly simplify the code to make it compile, at that point it may be simpler to rewrite in C#.

Does X# maintain state like VFP does?
For example, keeping a cursor open for the lifetime of a datasession and remembering the filter, order, relation, record pointer etc between function calls?
If the answer is no then many VFP coding patterns could be removed, e.g. resetting the filter at the end of a function to maintain the original state.
If the answer is yes and the VFP code is compiled into a class library (.dll), does that mean the class constructer has to open cursors and initialise other objects etc that should be stateful?

Please find attached program.h (zipped).

Paul

Hi Paul,

Support for VFP in X# is still very heavy WIP, a lot of progress has already been made, but it certainly is not ready for porting large VFP apps _yet_. It will get there, just needs much more time and effort. We've already managed to bring X# in a very good shape for porting Visual Objects projects, I am sure it will reach this state for VFP, too.

For now, you can try creating new apps and see how you can make use of what's already there related to VFP support, together with the vast amount of new features that X# and .Net offers. Or you can try porting some smaller VFP apps, being prepared that at the moment you will need to be making several changes, and see how the end result looks like.

And of course you can help by keeping reporting things that are not working as expected! Having not been VFP developers ourselves in the past means we do not know every way VFP can be used and everything that is supported and how. We are learning every day, but we are still heavily relying on you guys, the VFP developers to help out.

Regarding your question, Robert is working on everything database related, will let him answer this himself. (Tomorrow, because today is a public holiday in The Netherlands).

PS. thanks for the file!

Paul, my company uses a fairly large VFP program (250K plus lines of code) as the main software to run our company. We've been looking for years for an upgrade path, since VFP not being supported anymore makes everyone a bit nervous. There have been attempts, or at least announcements, of possible successors to VFP but nothing has looked very promising. X# is the first system I have seen which holds out the real possibility of an almost completely compatible upgrade path. While I don't think it will ever be possible to simply take an existing VFP project and compile in X# (or anything else) with no modifications whatsoever, I think X# can achieve a level of compatibility which makes it a good choice as an upgrade path. There's still a long way to go, but they've come very far already. While there are still many FoxPro function which are not available in X#, those functions are being added over time; and even for functions not added, the functionality is already often easily available in .NET. My company has been sufficiently impressed with X# that we are a corporate sponsor. So, if you're looking at a system which right now is suitable to compile existing VFP projects, then X# clearly isn't there yet. But if you're looking for a potential upgrade path within the next couple of years, I'd say that X# is the best option.

Yes, certainly X# is very promising and a year from now it will be exciting to see how much more of VFP is supported.
Unfortunately my timeframe for using it in our business situation is "now or never"

A lot of VFP data flow, at least in our project, involves having cursors (usually from remote views) persisting over an extended lifetime and functions receiving a parameter telling them the alias of a cursor to perform some operation on.
I would guess that a .NET class instance would need to have persistent properties of datasets, collections or lists (observable?) to manage this.
For me, this along with the management of remote views seems the most important conceptual thing to have in place for a migration of an enterprise system to be feasible. While individual commands and functions could be replaced/tweaked in .NET, the general state model would need to exist in order for the shape of the VFP code to even make sense (with the exception of stand-alone helper code).

I will continue to refactor my test code a bit and see far I can take it.

Raj,
my .2ct: if you earnestly consider "rewriting in C#" to be an option, then you can't argue X# to be not fast enough moving, as this will certainly need more time...

But why not engage in bringing the "VFP part" fast forward? This is an open source project, everyone can and should assist where he can. And if you can't/don't want to do so, why not enter FOX - every Euro more in the programm allows Dev to invest more hours for the project.