Is the "global object" synonymous with an "application object"?

>>>>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.