Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
The m. variable thing, the sequel
Message
From
11/01/2005 15:23:14
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00969478
Message ID:
00976136
Views:
77
>>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.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform