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