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

If it makes you feel comfortable to call it that, fine. A global object is any object that has a fixed, constant and unique reference at all levels of the call stack. Any object that is attached to a PUBLIC variable is a global object, because you reference its properties and methods as public var name.whatever all the time. You can have more than one. There are some VFP-related global objects with complex properties like _SCREEN and _VFP

In this case, global means in scope at all times. You can, and often do, have several things in scope at all times. An objectcan be global without being your app 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.