Is this a bug in the View Parent Code button?


We received a bug report


 


Steps to Reproduce :


1) Create MyButtonClass1 class of MyButtonLibrary1.  Add code to click method.


2) Create MyFormClass1 class of MyFormLibrary1.


3) Add commandbutton of class created in step1.  Add code to commandbutton’s click method.


4) Create MyFormClass2 class of MyFormLibrary2.  Add code to commandbutton’s  click method.  Include DODEFAULT()


5) Create MyFormClass3 class of MyFormLibrary3.  Press “View Parent Code” button in editor while viewing commandbutton click method.


 


Actual Results :


When the “View Parent Code” button is clicked in step 5 the parent class hierarchy shown does not include the subclass created in step 3.  This is the faulty behavior.


 


However, when an object is created form class MyFormClass3 and the commandbutton clicked, the method is in fact executed.  This is correct behavior.


Expected Results :


I would expect that “View Parent Code” would show all parent classes that in fact are executed as DODEFAULT() is issued.


 


While this is not a “show stopper” it is a clear and important error.


 


 


 


 


After some wrangling, manipulation and guessing, I managed to create code to reproduce the issue (below)


 


When the designer comes up, there are 2 entries in the View Parent Code


MYFORMCLASS2  (which shows “Step 4” in the code)


MYBUTTONCLASS1 (which shows “Baseclass” in the code)


 


When you click the button, this is output to the screen:


 


MYFORMCLASS3.CMD.CLICK Step 5


MYFORMCLASS2.CMD.CLICK Step 4


MYFORMCLASS1.CMD.CLICK Step 3


MYBUTTONCLASS1.CLICK Button Baseclass_


 


 


 


Is this a bug? If so, how many items do you expect to see when the View Parent Code button is clicked? What exactly should each of them say? What if there were more levels of inheritance?


 


 


 


CLEAR


CLEAR ALL


ERASE MyButtonLibrary*.*


ERASE MyFormLibrary*.*


 


 


*1


Create CLASS MyButtonClass1    of MyButtonLibrary1 as commandbutton nowait


ASELOBJ(aa,1)


ox=aa[1]


ox.writemethod(“click”,GenCode(“Button Baseclass”))


KEYBOARD ‘y’      && send a “Y” to “Do you want to save changes” dialog


RELEASE WINDOWS “Class Designer”    && close the designer


DOEVENTS


 


*2


Create CLASS MyFormClass1 of MyFormLibrary1 as form nowait


ASELOBJ(aa,1)


ox=aa[1]


ox.AllowOutput=.f.      && so output goes to screen


ox.left=300             && so form is not on top of output


 


*3


ox.Newobject(“cmd”,”MyButtonClass1″,”MyButtonLibrary1″)


ox.cmd.writemethod(“click”,GenCode(“Step 3”))


ox.cmd.caption=”Click me”


KEYBOARD ‘y’      && send a “Y” to “Do you want to save changes” dialog


RELEASE WINDOWS “Class Designer”    && close the designer


DOEVENTS


 


*4


Create class  MyFormClass2  of MyFormLibrary2 as  MyFormClass1  from MyFormLibrary1 NOWAIT


ASELOBJ(aa,1)


ox=aa[1]


ox.cmd.writemethod(“click”,GenCode(“Step 4”))


KEYBOARD ‘y’      && send a “Y” to “Do you want to save changes” dialog


RELEASE WINDOWS “Class Designer”    && close the designer


DOEVENTS


 


*5)


Create class  MyFormClass3 of MyFormLibrary3 as MyFormClass2  from MyFormLibrary2 nowait


ASELOBJ(aa,1)


ox=aa[1]


ox.cmd.writemethod(“click”,GenCode(“Step 5. Examine ‘View Parent Code’ button”))


KEYBOARD ‘y’      && send a “Y” to “Do you want to save changes” dialog


RELEASE WINDOWS “Class Designer”    && close the designer


DOEVENTS


KEYBOARD ‘{ALT+i}’ 


 


MODIFY CLASS MyFormClass3 of MyFormLibrary3 METHOD cmd.click


ox=NEWOBJECT(“MyFormClass3″,”MyFormLibrary3”)


 


ox.show(1)


 


PROCEDURE gencode(str as String)


      TEXT TO mycode NOSHOW TEXTMERGE


      ?PROGRAM(),”<<str>>”


      DODEFAULT()


      ENDTEXT


      RETURN mycode


 


 

Comments (4)

  1. Bob Archer says:

    Not a bug.

    In all cases the button class MyButtonClass1 is that class.

    However, when you drop a class on a form class you are creating an "instance" not a class.

    So, when you subclass the form the code in the click method of the button instance isn’t in the parent button class.

    The best practice would be to have to button class click method call a method on the form. Then, your form subclass can override that method. This gives you a cleaner UI and allows you to reuse the button class rather than putting code in the buttons instance.

  2. Fabio Lunardon says:

    It is a bug.

    It is not easy to fix it.

    However, if you fix it, can you also fix the similar issue for a columns defined inside a Prg.

    Repro:

    1. It creates a class column in a Prg, with some method.

    2. Add it as memberClass into a grid.

    result:

    In Class Designer "View Parent Tails" for the grid columns are empty.

    Thanks.

  3. David Fung says:

    Sounds to me it is a bug in the purist sense as Bob Archer pointed out that the missing method code belongs to an instance of the class not the class itself.

    However it may be a good idea to show all the methods in the call chain when "viewing parent code" to make it consistent with FoxPro tendency to blur the difference between instance programming and subclassing.

  4. Alex Sosa says:

    Hi Calvin,

    I ran into this problem because I purchased a framework which has a compund object (form plus dataaccess object). I then created an intermediate subclass to which I added objects and code meant to be be shared by several apps. Then I create an app specific subclass from that and from that I create my forms.

    Whether it is good design or not (and it may not be), I think is a bug because the design time behavior does not predict what will actually ocurr at runtime.

    Thank you for your attention,

    Alex