fbpx
Welcome, Guest
Username: Password: Remember me
This public forum is meant for questions and discussions about Visual FoxPro
  • Page:
  • 1
  • 2

TOPIC: We need your input on how to migrate FoxPro forms

We need your input on how to migrate FoxPro forms 08 Jan 2020 12:48 #12483

  • robert's Avatar

  • robert

  • Topic Author


  • Posts: 1678
  • 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 example Windows 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 18:22 #12498

  • FoxProMatt's Avatar

  • FoxProMatt


  • Posts: 377
  • 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:
    Procedure Pageframe1_Page1_Container1_Button1_Click()
    Procedure Pageframe1_Page1_Container2_Button1_Click()
    Procedure Pageframe1_Page2_Container1_Button1_Click()
    Procedure Pageframe1_Page2_Container2_Button1_Click()
    Procedure Pageframe1_Page3_Container1_Button1_Click()
    Procedure Pageframe1_Page3_Container2_Button1_Click()

    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:
    Procedure Pageframe1_Page1_Pageframe1_Page1_Container1_Button1_Click()

    It gets crazy really quickly.

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

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 18:45 #12499

  • FoxProMatt's Avatar

  • FoxProMatt


  • Posts: 377
  • 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.

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 18:58 #12500

  • robert's Avatar

  • robert

  • Topic Author


  • Posts: 1678
  • 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 19:23 #12501

  • Eric Selje's Avatar

  • Eric Selje


  • Posts: 11
  • 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

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 20:44 #12502

  • FoxProMatt's Avatar

  • FoxProMatt


  • Posts: 377
  • 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??
    If This.Parent.nProperty > 0
       This.Enabled = .F.
    EndIf

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

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 08 Jan 2020 22:13 #12504

  • FFF's Avatar

  • FFF


  • Posts: 919
  • 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:

    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
    Regards
    Karl (X# 2.4a; Xide 1.25; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 09 Jan 2020 00:20 #12505

  • FoxProMatt's Avatar

  • FoxProMatt


  • Posts: 377
  • FFF - This is FoxPro… There is no such reference as Self or Owner in this language. Correction... In this dialect.

    Please Log in or Create an account to join the conversation.

    Last edit: by FoxProMatt.

    We need your input on how to migrate FoxPro forms 09 Jan 2020 01:12 #12507

  • Eric Selje's Avatar

  • Eric Selje


  • Posts: 11
  • 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.

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 09 Jan 2020 10:55 #12511

  • pluisje's Avatar

  • pluisje


  • Posts: 3
  • 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.

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 10 Jan 2020 06:09 #12528

  • Jun's Avatar

  • Jun


  • Posts: 1
  • In addition to what others said about this, thisform, this.parent, we also use WITH ... ENDWITH. For instance, this is how I set up one of my grids. These codes are on the Grid's Init event:
    With This
    	.RecordSourceType= 1
    	.RecordSource='vwADSB'
    	.column1.ControlSource='vwADSB.refno'
    	.column2.ControlSource='vwADSB.revision'
    	.column3.ControlSource='vwADSB.modno'
    	.column4.ControlSource='vwADSB.description'
    	.column5.ControlSource='vwADSB.issued'
    	.column6.ControlSource='vwADSB.adstatus'
    	.column7.ControlSource='vwADSB.repetitive'
    	.column8.ControlSource='vwADSB.compdue'
    	.column9.ControlSource='vwADSB.hrs'
    	.column10.ControlSource='vwADSB.hrsdate'
    	.column11.ControlSource='vwADSB.comprefno'
    	.column12.ControlSource='vwADSB.adsched'
    	.column13.ControlSource='vwADSB.tagged'
    	.column14.ControlSource='vwADSB.origin'
    	.column15.ControlSource='vwADSB.lbk'
    	.column13.DynamicCurrentControl = 'IIF(vwadsb.tagged=1,"imgChk","imgnochk")'
    	.SetAll('Alignment',2,'Header')
    	.SetAll('DynamicBackColor','ICASE(ALLTRIM(vwadsb.description) = "CANCELLED",RGB(255,179,179),'+;
    	'INLIST(ALLTRIM(vwadsb.adstatus),"FE","E") AND ALLTRIM(vwadsb.repetitive) = "YES",RGB(0,190,0),'+;
    	'INLIST(ALLTRIM(vwadsb.adstatus),"FE","E") AND ALLTRIM(vwadsb.repetitive) = "NO",RGB(183,255,183),'+;
    	'RGB(255,255,255))','Column')
    	.RowHeight= gomyapp.RowHeight 
    ENDWITH

    That made it more readable for me than a lot of reference to the same object (This):
    This.RecordSourceType= 1
    This.RecordSource='vwADSB'
    This.column1.ControlSource='vwADSB.refno'
    This.column2.ControlSource='vwADSB.revision'

    and so on....

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 10 Jan 2020 07:19 #12529

  • cisberner's Avatar

  • cisberner


  • Posts: 2
  • 1) Are you using "this" a lot in your event handlers ?

    Yes, and not only buttons but any other control as well. In most cases I create classes of composite controls with generic code that calls THIS and THIS.Parent. These composite controls can be dropped on a form (in the designer or with lazy instantiation) and can interact with the form through eventbinding (BINDEVENTS(THISFORM.cntInfo,"OnUpdate",THISFORM,"OnUpdateInfo").

    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")

    I see no problem at all.

    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 ?

    A custom form editor is a good alternative if point 2) would not be implemented. I stay neutral to this.

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 10 Jan 2020 14:58 #12548

  • mainhatten's Avatar

  • mainhatten


  • Posts: 139
  • robert wrote: 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.


    Hi Robert,

    to avoid writing another of my too-long answers, I'll try to answer in 3 separate posts, this one the easiest.
    As you were unaware of vfp9 report engine in vfp source already availabel, let me point out a few options for analyzing/porting existing GUI code.
    In the xCode of vfp there is the Class Browser, written by Marcus Egger IIRC. That version has an option to write out vfp .prg code for any vcx-based class loaded into Class Browser. The original version had 1 or 2 small bugs which made direct reuse of the generated code impossible - but AFAIK the versions on vfpX fixed those bugs, so that the prg-code returned form Class Browser is runnable code. Probably easier to target only 1 (.prg) based conversion - although you could go the other way, load prg based GUI and save each element in vcx via WriteAsClass.

    I don't know if you are aware of Lianja, which is another system supporting vfp dialect. Lianja has a porting tool for vcx/scx files, creating corresponding .prg files for the whole library. As classes inherited or aggregated on forms most of the times point to superclasses in same or different vcx, this eases identifying precursor classes. I was involved for a few months and rewrote said porting tool from 3-4K by Barry Mavin (lead dev of Lianja) able to handle some classes to current state (12-13K) handling all classes and the special fields in vcx governing new and overwritten methods and properties. This version is still active today and the only problem surfaced recently was a call to also ported Beautifier, which I had to added ease comparison directly or via Source Control (probably pathig to defsult settings...).
    I think the whole resulting source was/is Open Sourced, but feel better if Barry was contacted and asked in advance, as initial start of the code came from his fingertips ;-)
    If really needed, I could probably recreate his starting point as white-room development. If you download Lianja evaluation, latest porting tool should be included.

    About a dozen years ago I wrote a tool creating Python object code from all vfp properties - used that to create a WPF GUI via Ironpython from vfp forms running as hidden COM - similar to FoxInCloud building HTML forms running across the Internet of vfp server side code for local clients running WPF GUI equivalent to the vfp form. Probably not useful in your surroundings - but with tiny changes could write out JSON trees of vfp forms for wholesale debugging effort. I retained rights to the basic feasability proof (but would have to search on old DAT-tapes ...), further dev was made and sold as closed source.

    Hope you find some of the above helpful

    Thomas

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 10 Jan 2020 17:03 #12562

  • Kevin Clark's Avatar

  • Kevin Clark


  • Posts: 68
  • I use "this" and "thisform" all the time. I also use "parent" occasionally and also "bindevents", but that's infrequent enough that manually making a change to those items would be pretty simple. Also, as Matt pointed out, there are lots of times when I will use something like "pageframe1,page1,pageframe1.page2.button1".

    I like the idea of changing "this" to "thiscontrol". I also like the idea of putting all the event handlers in one place like VB.NET does. I've always considered the fact that FoxPro breaks up events into discrete parts linked to objects to be a drawback, not a good feature. Using both VB.NET and Foxpro, I find the VB.NET model much more convenient.

    Please Log in or Create an account to join the conversation.

    Last edit: by Kevin Clark.

    We need your input on how to migrate FoxPro forms 10 Jan 2020 23:30 #12563

  • KoenPiller's Avatar

  • KoenPiller


  • Posts: 1
  • Hi,
    There is almost not any piece of code which makes use of This and or ThisForm, a typical piece of code is:
    With This
    .Combo1.Clear()
    For liMonth = 1 To 13
    .iaMonths[m.liMonth, 2] = Gomonth(.idCurrentmonth, (-6 + (m.liMonth - 1)))
    li1stShowMonth = MONTH(.iaMonths[m.liMonth, 2])
    lcMonth = Alltrim(This.GetFormatedDate(.iaMonths[m.liMonth,2], LOCALE_USER_DEFAULTMONTH, "MMMM"))
    .iaMonths(m.liMonth,1) = m.lcMonth
    .Combo1.AddItem( m.lcMonth )
    .Combo1.List[.Combo1.NewIndex,2] = Transform(m.liMonth)
    Endfor
    .Combo1.Value = .Combo1.List(1)
    Endwith

    or
    With Thisform

    .SetCaptions()
    .cLogfile = m.tcLogfile
    .edtError.Value = Filetostr( .cLogfile)

    Endwith

    2)if you change this to thiscontrol, no problem but it should not be the same as thisform
    3)if ness why not, I would not prefer since this again another layer
    Koen

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 11 Jan 2020 15:36 #12569

  • Chris's Avatar

  • Chris


  • Posts: 1878
  • Hi Koen & everyone,

    For this particular matter, it is not important for us if you actually use the identifier itself or through a With statement, the important thing is if it is a very common practice to refer to the control directly while handling one of its events, or it is more common to refer to controls through "thisform" (with or without a "With").

    Another question is, since it is obvious from your replies, that using "this" is very common, would it be acceptable for you to start using only "thisform" from now on in event methods? So, for example the click event code of a command button control that looked like:

    This.Caption = "I got clicked!"

    would be typed in X# as

    Thisform.Button1.Caption = "I got clicked!"

    Of course if we choose this path, we would not require from you to change manually all your 100s of thousands of lines of code, a tool would do this automatically. And after the application is ported, new code would follow the new pattern.

    Please do not take the above as set in stone at all, it is only a suggestion, as we are trying to find the correct balance for the best way to implement things. Depending on your input we may end up implementing this in an even more VFP compatible way, or we may end up providing more than one solutions... In any case, thank you very much to everyone that has replied so far, your responses are very valuable, please keep them coming!
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Last edit: by Chris.

    We need your input on how to migrate FoxPro forms 11 Jan 2020 17:26 #12570

  • mainhatten's Avatar

  • mainhatten


  • Posts: 139
  • robert wrote: 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.

    Yes, the form will "house" any event code written for controls aggregated on the form. But IIRC that is not a special feature of the form, but of ANY container which has a child control aggreagated, as an "object instance" is aggregated, not a class where properties and methods can be overwritten at the class level. This will result in method names duplicating the object name path from the outermost container.

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

    OkButton can be added to a form many times, as long as it is always surrounded by another container - inside each container the names must be unique, NOT for total form.
    MyForm.Pgf1.PageEntry.OkButton
    MyForm.Pgf1.PageMiddle.Container.OkButton
    MyForm.Pgf1.PageLast.ContainerBottom.CmdGroup.OkButton
    MyForm.Pgf2.PageMain.CmdGroup.OkButton
    is valid vfp structure having all that IN THE SAME FORM - which would not be ok for WinFroms IIRC. I think a naming convention like "MyForm#Pgf1#PageLast#ContainerBottom#CmdGroup#OkButton#click()" for vfp# might be safest, as it sidesteps the already overused dot (object path, namespaces) in Dotnet.

    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.

    Count me among those unhappy with such a solution.
    CAVEAT EMPTOR: the following is only my mental model, NOT verified debugging vfp runtime at C-level
    Some OOP languages have explicit pointers to current/housing object (think Python self as first method parameter or the JS gymnastics with apply, bind and call), others just hide the self reference. I envisioned vfp method call to always follow the pattern of
    procedure MyMethod(Hidden_Implicit ThisForm, Hidden_Implicit This, OtherParameters)
    Of course a hidden property with an access method walking the way up container hierarchy to next containing form or set during addobject() would also work, but "Parent" is a property, "ThisForm" not.
    "ThisControl" is palatable (portable code via preprocessor in vfp), "ThisForm" exchanged with "This" not.
    Better to add a "__ThisForm" property to each control and mangle "ThisForm" on the vfp# side via preprocessor into a call to "ThisControl.__ThisForm" for those methods defined at the control class level.

    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.

    I cannot visualize that idea totally - but include complex controls added in already multiple times overwritten event delegate each called via dodefault() early in your testing. Gut twitches here that you might have to add a stack of events as a single object might be in trouble or not be enough.
    It has been too long since reading about the option to (re)name variables to keywords with leading @ - back when I first read about it, I tought it was probably used to switch IL "this" to IronPython "self", but never looked hard. Perhaps that way the "This" of Winform event could be mapped into "Thisform" and the "ThisControl" into "This" in the event method ?

    [snipped part of custom editor]

    I dislike the idea of a custom editor - alternative POV in 3. post...

    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 ?

    Yes

    2a) Would it be a problem for you if we change "this" to "thiscontrol" for event handlers

    No

    2B) Would it be a problem for you if ( then "this" becomes the same as "thisform")

    YES

    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 ?

    No, I think creating a special Winform editor is not the best solution - next post, but have to order thoughts first...

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    We need your input on how to migrate FoxPro forms 12 Jan 2020 09:00 #12573

  • atlopes's Avatar

  • atlopes


  • Posts: 41
  • Chris asked:

    Another question is, since it is obvious from your replies, that using "this" is very common, would it be acceptable for you to start using only "thisform" from now on in event methods? So, for example the click event code of a command button control that looked like:

    This.Caption = "I got clicked!"

    would be typed in X# as

    Thisform.Button1.Caption = "I got clicked!"


    If I'm getting this right, this would break all of the VFP OOP building because we wouldn't be able to subclass a button to be used in a form or any other container.
    DEFINE CLASS SensitiveButton AS CommandButton
    
      PROCEDURE Click
         This.Caption = "Ouch! I got clicked!"
      ENDPROC
    
    ENDDEF

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 12 Jan 2020 09:39 #12574

  • atlopes's Avatar

  • atlopes


  • Posts: 41
  • Robert asked

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

    As all others said, a lot. To put some numbers on the table, the current project that I have opened right now, "This" as a reference to an object, is used 9909 times in 88 files, so it's a big deal.

    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")

    "This" is used in every kind of object, not only those that can be placed in a form. For me, it would be a real nuisance, but in a less personal tone and thinking of all the VFP documentation that it exists, starting by the incredible help file that supports us, this change (pun intended) would be a major blow. And I didn't mention the code.

    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 ?

    If you can generate subclasses of arbitrary subclasses at any level of class hierarchy... But I confess I'm not able to assess the difficulty and implications of the task and certainly would be too dumb to say if it's a good idea or not.

    Please Log in or Create an account to join the conversation.

    We need your input on how to migrate FoxPro forms 12 Jan 2020 11:23 #12575

  • cisberner's Avatar

  • cisberner


  • Posts: 2
  • Good idea to talk numbers:
    My largest project does mention THIS in 113000 cases in 750 files.My smaller projects mention THIS in 41000 cases in 170 files.

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1
    • 2