Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Question about global vars/procedures
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00356628
Message ID:
00357326
Views:
18
>>>So there is no way to have a bunch of procedures in a file that you can call globally? I have to have a separate file for each procedure I want to call?
>>
>>Nope, if you do a SET PROCEDURE TO a Prg, then you can call any of teh UDFs in that Prg normally.
>>
>>Also consider creating an global object with methods for all these.
>
>I have the "set procedure to" up and running. Care to expand on the global object?

Simple concept, although not my preferred mechanism for lots of reasons. Create an object full of methods that do "neat things". Create a private variable at the top of your app, or a public, or add it to an existing globally accessible resource like _SCREEN or _VFP. You then access the methods of the object through the global reference. eg

* My place that defines the NeatThing
* MakeNeat.PRG
PUBLIC oNeatThing
oNeatThing = CREATEOBJ('NeatThingClass')
RETURN

PROCEDURE CLASSDEF
DEFINE CLASS NeatThingClass AS LINE
FUNCTION Foo
* Code
ENDFUNC

FUNCTION Bar
* Code
ENDFUNC

FUNCTION DoAUsefulThing
LPARAMETER parm
* Code
ENDFUNC
ENDDEFINE

In your main program:

DO MAKENEAT

If you wanted, you could include the class def in your main. YMMV.

later, when you need it's functionality, the functions, now methods, can be accessed as:

Result = oNeatThing.DoAUsefulThing(parms)

There are lots of drawbacks, ranging from a slight performance edge for procedures over methods because no object reference resolution is reserved, to possible issues using it in dexes and views that may outlive the object - if you create an index relying on some method of the global object, you must instantiate the object and give it an identical name every time that index might be active - with a procedure file, the procedure has to be findable, but the order of instantiation, name of the procedure file, etc is immaterial - it can live in the original file, or another file that's in the SET PROCEDURE hierarchy, or just make a standlone .PRG

There are issues of scope that differ between methods and procedures, too.

Plus there's always the opportunity for some wiped-out coder issuing the statement:

PRIVATE ALL LIKE o*

avoidable, but still there.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform