Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Looking for feedback.
Message
De
22/07/2001 16:20:32
 
 
À
22/07/2001 15:30:27
Larry Long
ProgRes (Programming Resources)
Georgie, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00533667
Message ID:
00533672
Vues:
11
Larry,

First of all I want to encourage you to (also?) put your suggestion, in its final format, into the UT VFP 8 Wish document. Craig B. periodically sends it to MS (at least I think he still does).

I agree that there could be work done in the VFP product to help developers with these issues. I even have added a small idea myself into the VFP 8 Wish document to help us out a little on this.

One big problem I have with this one is correctly reading your example. While I agree that the final form within VFP wouldn't necessarily look anything like you have here, I find that I can't confidently read your example to "get the point". Maybe a little more formatting would help. [aside: wouldn't the DODEFAULT() in the example actually execute nothing, since it would be executing OtherClass Click() (its parent) that is empty?]

I see that Nancy F. has said that VFP7 addresses at least a small part of what you've got here. Personally I haven't yet seen VFP 7. I'm guessing you have and have found it falls short of what you want. If that's so it might be good to mention that, and why more is needed.

You asked

JimN

>Hi all!
>I am getting a suggestion together for VFP that I would like some feedback before I send it to MS.
>
>Please take a minute to look at this and pls feel free to let me know what you think. I believe that adding this capability to VFP would greatly benefit us all.
>
>********************
>It is very difficult to analyze and debug code in situations where you have a form that has multiple classes embedded within it. It would be of immense help to all VFP developer if we could have a window at both design time and in debug mode where we could see the following...
>
>1) The different class layers for a selected object.
>2) The hierarchy (i.e. order) in which an object's code would go normally go through.
>3) Be able to see the bypassed/overridden code, so we can see if we have overridden any needed code by mistake.
>
>At design time, for example, if we could right click on an object and select a "Code Hierarchy" option, and have a "Code hierarchy window" (similar to the current code window) where we could choose a method and then have the system show us (read-only) the code in order of execution.
>
>For example, say we have a form that was created using a form class, then an object is added to the form that is also based on a class, which was sub-classed from yet another class and then a method's code is modified on this form then the Code Hierarchy window could, perhaps, look something like this...
>
>[Click method]
>baseclass (baseclass.vcx) *None
>someclass (class1.vcx) USE TABLENAME (overridden)
>someclass (class1.vcx) LOCATE FOR .... (overridden)
>otherclass (class2.vcx) *None
>thisform SELECT 0
>thisform DODEFAULT()
>someclass (class1.vcx) USE TABLENAME
>someclass (class1.vcx) LOCATE FOR ....
>thisform IF NOT EOF()
>thisform =MESSAGEBOX(...
>thisform ENDIF
>
>*******************
>
>TIA,
>Larry
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform