[VFP] Make the compiler hack about THISFORM and FindForm() optional

[cpyrgas]

Robert, when I use my own implementation for thisform etc (with regular properties), the compiler expects for a method "FindForm" to exist as well. Please make this behavior optional, as it's causing trouble creating a cleaner implementation and also leads to unnecessary late bound calls. Providing a compiler option that disables this functionality would be more than enough.

Also even by implementing this method, there's still something special about a property called "thisform" and the code fails at runtime, see below and test C976.

#pragma options("fox3", enable)
#pragma options("allowdot", enable)
#pragma options("lb", enable)
#pragma options("memvar", enable)
#pragma options("undeclared", enable)
CLASS MyForm INHERIT XSharp.VFP.Custom // problem happens even if not inheriting from any class
	PROPERTY Test AS INT AUTO
END CLASS

CLASS TestControl INHERIT XSharp.VFP.Custom // problem happens even if not inheriting from any class
	PROPERTY ThisForm AS MyForm AUTO

	// should compile also without this, but for now uncomment to run test:

/*	METHOD FindForm() AS MyForm // workaround because the compiler needs this method to exist
	RETURN SELF:ThisForm*/
		
	METHOD DoTest() AS VOID
		thisform := MyForm{}
		thisform.Test := 123
		? thisform.Test
END CLASS

FUNCTION Start() AS VOID
	TRY
		TestControl{}:DoTest()
	CATCH oException AS System.Reflection.ReflectionTypeLoadException
		FOREACH oLoaderException AS Exception IN oException:LoaderExceptions
			// System.TypeLoadException: Declaration referenced in a method implementation cannot be a final method.  Type: 'ImplementClass'.
			? oLoaderException:ToString( )
		NEXT
	END TRY		

[RobertvanderHulst]

Chris,
In FoxPro THISFORM is a keyword and cannot be assigned to.
We also recognize it as a keyword, and when the compiler detects it in code, then it generates a local variable Xs$ThisForm and replaces references to THISFORM with Xs$ThisForm. The Xs$Thisform local is initialized with FindForm().
Fabrice and I have discussed this and came up with this solution
I don't understand what the problem is with FindForm() and what you are trying to solve.
And if I implement a switch, which things should the switch disable?

[cpyrgas]

Robert, this solution was necessary in order to implement a GUI that is VS form designer friendly, which requires a lot of changes in the VFP code. And even in that case, in many cases the VS designer still doesn't like it and code such as "thisform.something.else" must be replaced with SELF:thisform.something.else

When trying to implement a GUI that doesn't require changes in the existing VFP code, this just gets in the way. Don't need the direct assignment to be supported, this was just a quick way to demonstrate the issue without too much code. I have rewritten the sample without the direct assignment to the thisform property now.

Even if thisform is a keyword, it can be (or used to) still used as a property name, so when defined a property THISFORM, it should be possible to use thisform.something.else within a class that has a property named "thisform". And this way it requires zero changes to the existing VFP code (on that matter at least). This used to work before the latest compiler changes, but now (only when /fox3 is used) reports an error that "thisform" cannot be found.

Such a compiler switch would just need to disable the special treatment of "thisform" and let it be used as an identifier and as a consequence also do not require a FindForm() method to exist. If it's complicated, can you think any other workaround to make the code below work at runtime, without touching the VFP code (the one in the Click() handler)? This did work fine before the latest changes and it still works fine but only if I disable fox3

#pragma options("fox3", enable)
#pragma options("allowdot", enable)
#pragma options("lb", enable)
#pragma options("memvar", enable)
#pragma options("undeclared", enable)
#pragma options("allowoldstyleassignments", enable)
CLASS Form INHERIT XSharp.VFP.Custom // problem happens even if not inheriting from any class
	EXPORT Button AS Button
	PROPERTY Caption AS STRING AUTO
	CONSTRUCTOR( )
		SUPER( )
		SELF:Button := Button{ SELF }
		SELF:Caption := "Main Form"
END CLASS

CLASS Button INHERIT XSharp.VFP.Custom // problem happens even if not inheriting from any class
	PROPERTY @@ThisForm AS OBJECT AUTO // or AS Form, AS USUAL, etc
	PROPERTY Caption AS STRING AUTO
	
	CONSTRUCTOR( oForm AS Form )
		SUPER( )
		SELF:ThisForm := oForm
		SELF:Caption := "Click me"
		
	// workaround because the compiler needs this method to exist
	METHOD FindForm() AS Form // or AS USUAL, AS OBJECT etc
	RETURN SELF:ThisForm
		
	METHOD Click() AS VOID
		// that's the original VFP code
		thisform.Button.Caption = "test"
		? thisform.Button.Caption

		thisform.Caption := "another test"
		? thisform.Caption
END CLASS

FUNCTION Start() AS VOID
	LOCAL oForm AS Form
	oForm := Form{}
	oForm:Button:Click() // emulate user clicking the button

[RobertvanderHulst]

Chris,
For now I will add a /nothisform compiler option that leaves the (soft) keyword but disables the other functionality.

[cpyrgas]

Robert, that's great, thanks! Can you please trigger a build action, so I can test this and the other fixes?

Btw, I now have a 200,000 line VFP app fully compiling in X# with the alternative gui and am looking into making it fully run, too. Still need to make a lot of changes in the code because of things we do not support yet (compiler/macrocompiler/runtime/gui), but this update will already help a lot. Will post it in the dev forum and will slowly one by one start discussions about VFP features we are not supporting yet.

[RobertvanderHulst]

Chris,
I have triggered the action.
Next time you can do that yourself:

• Goto the Actions page
• Choose Continousbuild on the left hand side
• Press [Run Workflow] on the right hand side
• Choose the branch. The default is main, but if I have not committed to main, the you should choose dev and then press [Run workflow]

Wait and relax. You can open the workflow and see the terminal screen from the server if you want. You should see it perform:

• Checkout of the source
• Install the right version of .Net
• Build the compier and tools
• Run the tests
• etc

[cpyrgas]

Robert,
That's awesome! Didn't know I could do this... But I'm also seeing several problems with running the tests, many are failing while they run fine locally, I'm investigating this. Is there a way to run the tests only in the server, without rebuilding the compiler, so I can just test the tests?

Also thanks a lot for the THISFORM fix, so far this is now working very well! Will do some more thorough testing though before I close the ticket.

[RobertvanderHulst]

Chris,
To run the tests separately we need to create a new workflow and somehow transfer the compiler files from the ContinuousBuild workflow to the new workflow. This should be possible, I have just not found the time to do this.
When that works, then we can also build the runtime in a workflow and run the unit tests for the runtime.
There are actions to upload and download artifacts, so you can share them between workflows.
See https://docs.github.com/en/actions/tutorials/store-and-share-data
Please feel free to test this.

[cpyrgas]

Nah, I think I'll pass, got dizzy just by reading this...
I'll just wait a bit more for the tests to finish :)