xsharp.eu

To all FoxPro users,

We have been studying how we can implement our tool to convert FoxPro forms code to .Net using Windows Forms.
From what we have seen, FoxPro allows you to write Events (Event Handlers) at the control level.
For example if a form has 2 button controls, then each of these buttons can have a Click event
with the code that gets executed when that button is pressed. This click event belongs to the button.
The form on which the buttons are located can also have a click event.

In Windows Forms there are also click events at the form level and the control level, so that looks very much like FoxPro. (On the other hand, Windows Forms controls typically include many dozens of properties and events (for exampleWindows Forms Events ), which is not like FoxPro's compact list).

However, in a normal Windows Forms window, when designed with the Windows Forms editor, the events/ event handles for the form and the events for the controls all become event handlers (methods) at the form level.

We can migrate your VFP form code to Windows Forms fairly easy and we can also migrate the events.
To migrate same named events for different controls and maybe also a same named event at the form we would have to give each of them a unique name. So when your form has OkButton and CancelButton the events would be called something like PROCEDURE OkButton_Click and PROCEDURE CancelButton_Click and PROCDURE Form_Click.

And we would be able to migrate the existing code out of the form into these methods.
For methods that receive parameters we would also be able to send the same parameters to these methods.

So far no problems, however there is one big difference:

Inside VFP in the Click Event for OkButton the variable "this" refers to the control and "thisform" to the form.
When the same code is in an event on the form then "this" is the form and not the control.

If you are using "this" a lot in the button event handlers, then that could be a problem, because you (or we) would have to make a lot of changes.
We could automate that in the conversion and make a local variable "thiscontrol" which points to the control and rename all references from the original code to "this" to "thiscontrol" and then rename all references to "thisform" to "this.
But we are not sure if that would result in a situation that would make everybody happy.

There is another solution to that:
When we detect that you have created an event handler for a control then we can create a subclass of the Button class for the OKButton and another subclass of the Button class for the CancelButton.
The Click event for each button would then be added to the subclass for that button. Conceptually that is not a problem and the code would remain very much like it is in VFP.
Unfortunately the standard Windows Forms editor does not allow us to automatically generate subclasses for controls when events are added.
So that would mean that we would have to use our own "custom" VFP window editor.
Again this is not impossible for us (we have created our own form editor for Visual Objects forms already) but it would be a bit more work for us.

If we would do that then you would have the choice of using the "custom" VFP form editor for existing forms that have been migrated to .Net and then the standard Windows forms editor for new forms.
The differene between the 2 would be (apart from some visual changes of course) that the custom editor automatically generates subclasses for controls with events and moves the event handlers to these subclasses.
And the standard Forms editor would not generate subclasses for controls and event handlers will be placed on the form and named uniquely (usually the control name + event name).
Also with a custom editor we would be able to make it look visually more closer to what the current FoxPro visual editor looks like (including the tabbed approach of the properties window), we would be able to limit the amount of properties/events shown and we will have full control on code generation, to make it look like very similar to existing FoxPro event handling code, without a need for additional code translating from WinForms to FoxPro style code.

Creating a custom editor requires a bit more work on our side but would create a solution that is more familiar to VFP developers. Of course it would be still possible to use the standard VS Windows Forms editor for adding new forms to existing or new projects, and both types of windows can be included in the same running application with no issues.

We really would like your input on this. To simplify the above to 3 questions:

1) Are you using "this" a lot in your event handlers ?
2) Would it be a problem for you if we change "this" to "thiscontrol" for event handlers (and then "this" becomes the same as "thisform")
3) If this is a problem, do you think it would be a good idea to have a special form editor and automatically generate subclasses to solve this problem ?


We are anxious to hear your input on this.

The X# devteam

Robert - you gave a super-simple example of a single control on a Form, where you proposed a method naming like "PROCEDURE OkButton_Click" at the Form level. That's fine for such a trivial example, but you have to realize that *many* VFP form use *many* containers, and even many nested containers.

For example, consider this (very real) example: a Pageframe with 3 Pages, and each Page has 2 Containers, and inside of *each* container there is a Button named Button1. So the methods moved up to the Form level would be this:
And trust me, the nesting quickly gets more severe than this in many real world VFP apps.

I know that people even put Pageframes inside of a Page. So that would be:
It gets crazy really quickly.

Let's see if any other VFP developers chime in to agree (or disagree) with me on these examples.

Besides my previous reply, I also have this comment about a Customer editor.

About this statement you made:

The difference between the 2 would be (apart from some visual changes of course) that the custom editor automatically generates subclasses for controls with events and moves the event handlers to these subclasses.

If you went went with a Custom Editor and your conversion tool made a subclass of each Control on each of my Forms that had local event or method code (or property overrides too, I assume, like font, size, color, caption, etc) well then there would be *hundreds* of new subclasses added to my project source code, and that would become very hard to navigate and get my brain around. The Class naming would get very cumbersome and verbose, it seems.

Many Forms have the same structure of: Form with Pageframe with Page with Container with Control(s).... So peeling out each little control (that has local event/method/property override) and give it a unique class name and code file would be a really long naming convention to navigate, and creates hundreds of files. I guess you could use a subfolder for controls on each Form and maybe even Namespaces to help create some separation, but it's just such a wild architectural departure from our beloved VFP land.

Can you envision any Custom Editor that allows it to remain much more like current VFP editor?

It seems to me that you (smart) guys could easily rebuild an entire Custom Editor to even stick with our current SCX/VCX formats to keep all the separation and local event/method/properties, but that's not the problem... The problem, which is *NOT* your fault, is that it has to be converted to that darn WinForms paradigm of UI stuff. Darn-it ^%$@^%$@ Microsoft.

Matt,

The subclasses we generate would be nested inside the form or custom conrol that they belong to. You would not be bothered with them at all.
And w.r.t. the long names: if you define a button click event for a custom control in the edior for the custom control, then the method will be inside the code of the custom control.

And you did not reply to the most important question:
are you (often) using this inside event handlers.
That is our biggest concern at this moment.
In VFP "this" inside the click event will be the button. If we move the button clicks to the form they will refer to the form.


Robert

Hi guys,

You've clearly put a lot of thought into this, which is very much appreciated. One more slight complication is that a button on a form may not be derived from a button class, but rather be a subclass of some other class (it was considered best practice so subclass all of VFP's base classes so that if Microsoft decided to change, say, the default font against your will in the next VFP you could easily change your subclass back to the way you like it.)

They may also be controls inside of custom containers.

Another thing we had been taught, though this wasn't always followed, is to NOT put much code in the event methods of controls. Yes, we could do it, it was not best practice. The people that did not follow this best practice will be most affected by your conversion.

My intuition is that your first solution is the correct path. Would it be possible to add the object that called the event as the first parameter of the form's eventhandler, a la e in exception handlers? I think that's essentially what you've suggested, and to me this feels like the right way to do it.

Eric

And you did not reply to the most important question:
are you (often) using this inside event handlers.
That is our biggest concern at this moment.
In VFP "this" inside the click event will be the button. If we move the button clicks to the form they will refer to the form.

Yes. Indeed, using "This." in event/method code to refer to the actual control is very, very common.

I wouldn't mind using "ThisControl." instead, as it's very intuitive. And, having ThisForm instead of This at Form level events/methods is fine too.

This.Caption = ...Blah...
This.Enabled = ...Blah...
This.BackColor = ...Blah...
This.BorderColor = Rgb(255, 0, 0)

How about this... A method on a Textbox control in a Container referring to its Parent Container??
I've even seen this mess: One Control1 in a Container referring to Control2 in the same container through the Parent reference:

FoxProMatt_MattSlay wrote:I've even seen this mess: One Control1 in a Container referring to Control2 in the same container through the Parent reference:

Code: Select all

This.Parent.oControl2.

Why "Parent"? - thinking in OO, this would be the Super-Class...
In Vo-Terms: Self:Owner:Button2 reflects the "real" relation IMHO much better.
(OT: Anyone remembers #2 of the Programming Guide for Vo2.5? Still in my cupboard, thick, heavy, but very clearly written... I vividly recall brooding about "has a...", "is a..." and other for me then real new concepts ) /OT

FFF - This is FoxPro… There is no such reference as Self or Owner in this [strike]language[/strike]. Correction... In this dialect.

We have two hierarchies: the containership hierarchy (has a) and the class hierarchy (is a). Parent points to the class' container parent, while the :: notation points to the class parent. There's also DODEFAULT() which can run code in the parent class' method.

I know you all know this, but I'm just writing it down for my own benefit.

1) Are you using "this" a lot in your event handlers ?

Yes. Everywhere.

2) Would it be a problem for you if we change "this" to "thiscontrol" for event handlers (and then "this" becomes the same as "thisform")
3) If this is a problem, do you think it would be a good idea to have a special form editor and automatically generate subclasses to solve this problem ?

To answer 2 and 3 at the same time. I think it is wise to stay as close as possible to VFP. Otherwise, there is less advantage to migrate to X#. So yes, I think a custom form editor is the way to go.