xsharp.eu

Hi, Robert

I thought of this when I was using the foxpro dialect of X#.

“This” stands for the class/class instance itself and ‘Thisform’ stands for the form in VFP.
But in X# there is no such difference.

We can assume a scenario:
You have a custom class, and in the class method definition, you need to dynamically add a control to the form at runtime when an action is performed.
Then the class instance is added to the form at the moment of design. Because the object hierarchy of forms and class instances is full of variables, if you use “This.Parent.Parent......” this way, it is still a relatively complex piece of code assuming that this can be accomplished.
Everything would be simpler if the existence of “Thisform".

I second this. "Thisform" is extremely handy when you are using custom classes and you want to reference a property or method of the form on which the class is located. As you say, you can do the parent.parent.parent route but that becomes very complex, especially when a class could be used on various levels of a form. Also, Foxpro programmers are accustomed to "Thisform" so it would be good to support it just for compatibility.

Guys,
Event handlers in FoxPro are events of the Control class, in X# they are events of the form class.

In FoxPro, "this" inside an event handler is a reference to the control. This is a bit strange, because strictly speaking, FoxPro does not really generate a subclass for the event, but stores the event with the form. Our converter therefore converts "this" inside an event handler to thisobject.
The alternative would have been to generate a subclass for each control on a form. That could probably work if we had generated our own form designer.
But that would not work with the Windows Form designer from Visual Studio.

After the form was migrated, you can refer to the form itself with simple "this".
Only inside custom control, you can't do that, because "this" is the custom control.
What we can do is declare a "thisform" property that returns the form itself on the form class, and that walks the parent list for a custom control until the form is found.
If you use "this" on the form, then the compiler can check for typos and generate early bound code.
A "thisform" property on the form and custom control class will be declared as object (or usual) and using it will always generate late bound code.

Robert

Robert,

I personally don't see the need for a separate VFP form designer after my short attempt.
Although the property/field/constructor/method signatures are slightly different from VFP, these are easily accepted.

I like the idea of declare a “thisform” property.

Hi Guys,

this is something I had to "emulate" with the VFPXPorter and the XSharp.VFP.UI.

I've made is this way :

In the XSharp.VFP.UI.Form Class, I have added a property :
PROPERTY ThisForm AS OBJECT GET SELF
Notice it is typed as OBJECT to force/support late-binding methods calls

For Controls, I have property that is added to all VFP-Like controls :
PROPERTY ThisForm AS USUAL GET THIS.FindForm()
FindForm() is a standard Windows Forms method that retrieves the form that the control is on.

Unfortunately, as far as I know, we cannot "easily" add a property to an existing type.
.NET supports Extensions methods but no Extensions properties.
The only "official" way is offered by C#13 and called Extensions Types, but you need to use .NET 9 for that.

Maybe there are other way to achieve that, that I'm not aware of.

Regards,

Fabrice,
You're right, this is not easy when the forms and controls use the standard .Net classes.
The only way to do this would be to add some "special magic" to the compiler (in the FoxPro dialect).
We could translate:
- Translate ThisForm inside a Form class or event handler on a form to This
- Translate ThisForm inside a method on a control to a call to the FindForm() method.

It is "dirty" but we have added more dirty hacks to support FoxPro code.

Robert