Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
The m. variable thing, the sequel
Message
De
11/01/2005 15:23:14
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Database:
Visual FoxPro
Divers
Thread ID:
00969478
Message ID:
00976136
Vues:
68
>>Absolutely. My point however, is that it has a side effect that the collision between variable and fielname becomes highly unlikely.

>It doesn't kick in when referencing a declared local variable in method code. It may be my settings, so if you have a solution let me know. Further, it doesn't kick in when referencing an open table in method code either.

One thing I've found that makes intellisense kick in in prg based classes is to have Set Procedure To ... all of the prgs that hold the parent class definitions. Then it works. Since I already have a gen_setproc.prg (which generates setproc.prg with all the Set Procedure To and Open Classlib commands), if I really need intellisense to help me while editing such a beast, I just Do Setproc in the command window, and all of a sudden it shows it all. With the exception of PEMs defined in the current prg, of course.

For local variables... it works if it's defined as an object with "as < type here >". Works in the sense that I get dropdowns for that object's PEMs, but typing m. in code does not get me a list of variables. That part works in the command window and debugger's Watch window only.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform