>>>Local oExcel as 'Excel.Application'
>>>oExcel = CreateObject('Excel.Application')
>>>oExcel.Workbooks.Add
>>>oExcel.Visible = .t.
>>>Wait window timeout 2
>>>oExcel.WindowState= -4137 && xlMaximized
>>
>>Cetin,
>>
>>While you simply typed it in, I did my own research. I had success with
oExcel.activewindow.windowstate = 2
>>On the internet I found
#define xlMaximized 0xffffefd7
>>#define xlMinimized 0xffffefd4
>>#define xlNormal 0xffffefd1
>>And you use -4137. Now I'm somewhat confused. Is there a compatibility problem?
>>
>>Another thing I'm now trying to find out. I have a global variable goExcel. After having closed Excel (manually), the variable is still an object (of course), but it's also still not NULL. And indeed, the Task Manager (ctrl+alt+del) still names Excel.exe.
>>When I redo the action in VFP, I skip the createobject('excel.application') if the variable is not null. When doing goExcel.visible, Excel will indeed come to the front, but it will not work properly. Is this familiar to you?
>
>About the second question, I found this reference:
>Reporting using Excel, Excel remains open Thread #
765514, Message #
765789 and Message #
765926 in particular.
Peter,
Sorry I can't agree. It's easy to 'kill' the global variable and excel task but still do not trust it. You might never have a chance to call those lines and simply the user might experience a crash before you can do. If you want to test, on different OS, try having a global variable + closing a workbook and excel itself with Ctrl+f4, Alt+f4 combinations. I don't remember the exact combinations but I do remember I spent quite a time sorting it was the global var holding a reference.
If you really need to know when excel is closed interactively by user (hoping you're using VFP7 and later) then EventHandler() was my best friend. Prior to VFP7 I had done that with VFPCOM but unfortunately it didn't work under all OS + Excel versions.
Cetin