Humor me :-)

Try PUBLIC oExcel rather than LOCAL oExcel.

>>Hmmm...I've been using Office2000 routinely under Win98SE and Win NT 4.0 SP5 and haven't seen that one. I usually do an oExcel.Quit() AND oExcel = .NULL.
>>
>>Now screwing around with this on my laptop with Win NT4 SP5 I see that EXCEL.EXE stays in the Task Manager (is it a Tasker Manager on your machine?) after an oExcel.Quit but it goes away with oExcel = .NULL.
>>
>>Hmmm.....try using both?
>
>...And oExcel = NULL does it in the command window, but not from a program. Here's the code, which I've only commented

LOCAL oExcel
>lcfile = 'C:\LOTUS97\123\WARPING1.WK4'
>SET CLASSLIB TO OLE_SVR ADDITIVE
>oExcel = CREATEOBJECT('ypm_size')
>RELEASE CLASSLIB OLE_SVR
>* Opens the file
>oExcel.OpenFile(lcfile)
>* Sets .Visible = .T.
>oExcel.MinimizeApp
>oExcel.MakeAppVisible
>* Allow the user to select the range
>_SCREEN.WindowState = 1
>* Maximize Excel
>oExcel.MaximizeApp
>DO WHILE oExcel.oServer.WindowState = -4137
>ENDDO
>_SCREEN.WindowState = 2
>* Transfers data from a spreadsheet to a table
>oExcel.TransferData
>* Calls the .Quit() method
>oExcel.CloseApplication
>oExcel = NULL
>RELEASE oExcel

I got rid of the display problem by always using CREATEOBJECT(), rather than testing for existence of the Excel server (via Is_Run32('Excel'), and calling GETOBJECT() if it exists (in the class Init Method). However, calling this twice, leaves two instances of Excel in the Tasker...I mean Task Manager (how's that Gonz< g >).
>
>Once of the reasons for the sub-classing of the server is that this may (if I can ever get it figured out, end up doing this with 1-2-3 rather than Excel and I'm trying to get a consistent interface regardless of the underlying server.