Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Best approach about #DEFINE constants
Message
From
15/05/2008 21:01:11
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01316940
Message ID:
01317522
Views:
9
Or simply put, variables declared as PRIVATE only exist as long as the context in which they had been created (i.e. assigned) still exists. Once the PRG that created the PRIVATE variables goes out of scope, the variables go with them. With regards to usage with forms, it's something that is initially confusing -- but once you get get a handle on what's happening "behind the scenes" it's pretty straightforward. Frequently bumped into that when switching over code from FPD/FPW to VFP.
This reminds me of the initial problems I ran into when I first did stuff in dBASE. It took a while to finally figure out that despite what the manual told you, PRIVATE wasn't a declaration in the same way that it meant in other languages (create instance of variable within current context), but merely served to hide instances of variables within calling context so that first assignment creates a new instance within the context in which it is assigned. The other bit that frequently threw me in dBASE was in parameter passing. In other languages, the passed variable and the parameter variables acted as aliases to the same memory location (i.e. if you assigned the parameter variable you can immediately see variable from the calling context change since they were pointing to the same memory location). In dBASE I kept running into situations where variables wouldn't always contain the values I was expecting to find. The switch to FoxPro helped highlight where some weird bugs were occuring (by hiding the variable that was passed in as a parameter).

One thing that kept annoying me in FPD and FPW was the lack of #INCLUDE. As I would've done in most other languages, I would create .H files with commonly-used #DEFINEs, only to discover the lack of an #INCLUDE (there was a similar #INSERT however -- but it only worked with screen files). Although I could've kludged it by using a bunch of dummy screen files (so that I could utilize #INSERT), it proved to be more trouble than it was worth, so that plan was dropped -- although I ended up having to duplicate a bunch of #DEFINEs in each of the PRGs that required them. Another thing I toyed with was creating global variables -- but quickly ran into the MVCOUNT limits, so creating variables only where I needed them was the way to go -- but then that wasn't much better than duplicating the #DEFINEs...
Previous
Reply
Map
View

Click here to load this message in the networking platform