IMHO, never ever use Excel object as a public variable or a property of a public object. Instead create it as a local variable and pass to any method\procedure that would need it as a parameter.
Just my .05 cents.


>Hi: I am doing excel automation but am finding some discrepancies, I think, so wanted to check out some things.
>
>1. I usually begin by making the variable that I will be using for excel, by making it public:
>

>PUBLIC oExcel
>oExcel = CreateObject("Excel.Application") 	
>

>
>2. Where I am beginning to encounter problems is when I refer to oExcel in procedures. For instance:
>
>

>procedure someThingForExcelToDo
>     oExcel.visible = .T.  && here is where foxpro has now begun to say that oExcel is undefined
>                                    && it doesn't help if I try to get a hook into a previously defined oExcel object
>     oExcel = GETOBJECT("",'Excel.Application')  && if the above has occure, oExcel won't be able to find an excel object.
>endProcedure
>

>
>When automating excel, Is it too much to expect foxpro to be able to refer to public variable such as oExcel, in procedures? This is coming up because I am attempting to create a multi-tabbed excel workbook, where each procedure refers to the same excel object as it fills in a new tab.
>
>Thank you,
>Steve