Yes, the variable color_menu became a new global variable with windows updates. I first noticed this with Win7. I made a local fix by defining a new namespace for the definition of custom colors. I will upload later this weekend. In fact, I have several years worth of updates to FBGUI to be posted.

@Zippy,
Thanks. xlquitZombies() works perfectly for my needs in xlhelper.

@Zippy,
I should have provided more details. It doesn't matter whether Add.Global is on or off. Quit always reports "success" and yet the process remains active. ZombieCheck finds the PID and successfully kills the process.

@Zippy,
Zombies still present after quit, but your kill PID routine worked perfectly.

@OSchmidt,
I'm away from the university now (at Big Sky Montana :-) ) so upgrades to excel might be behind the latest available. When I get time, I will upgrade to FB 1.05 and try our SimpleVarient code.

@OSchmidt I will be happy to test this with MSO 2016, but I couldn't get SimpleVarient.bi to compile with your code above. In the BI file: line Mssg 74 Variable not declared, CBool 268 Duplicated definition 269 Duplicated definition 270 Duplicated definition 382 Array not dimensioned, before '(' 386...

@Zippy

Thanks for persisting. I am using Office 365 with Excel Version 16.0.4405.1000 64-bit.

I'll see if it's possible to force an update.

@Zippy Zombies, indeed. When I run your code with FB 1.03.0 32-bit in Win 7 Enterprise SP1 64-bit with MS Office 2016, I get two lingering excel.exe processes If, however, I force the spreadsheet to be invisible with: xlstart(,FALSE) then no lingering process. The effect is very buggy. Even after xl...

Update. There are several references to excel remaining active in the tasklist even after executing an .application.quit command in VBA. This behavior was noted back in MS Office 2013. The cause was identified as: "The most common cause of the problem is a 'global' reference to the automated ap...

Thanks for the reference. I agree, looks like Excel 2016 is buggy

If you know of a way to get the process ID for the instance of excel that was launched by xlopen(), then I could selectively use taskkill to wipe out just that image of excel.

I added xlrelease (just after xlquit) -> the excel.exe image is still active in tasklist. Curiously, xlrelease before xlquit generates an error message: application.quit CallMethod InvokeV The parameter is incorrect code: 80070057 Is this expected if xlrelease is attempted before xlquit?

@Phishguy, After installing MS Office 2016, excel remains an active process (shown in Task Manager) even after performing xlquit. The open workbook closes and the application window closes, but the application is active. With multiple xlOpen commands executed, this leaves a huge list of excel.exe ac...

Your suggestion of having Excel Visible helped reveal to problem. I'm trying to read an existing Excel file, not create a new one. I mistakenly thought xlstart() was required to launch the application. xlopen() had a create object call as well xlco("Excel.Application", NULL, @xlApp) and so...

Even this short little piece of code leaves excel.exe running #include once "xlhelper.bas" xlstart (1,FALSE) 'initialize Excel, 1 sheet, not visible xlopen(curdir & "\" & "My_Excel", FALSE) 'Open file, not visible Print Val(xlgetvalue(1,2)) xlquit xlrelease sleep

Excel wrapper is a great tool, but even after closing it down with xlquit and xlrease there still is an excel.exe process running (as shown by the Processes tab in the Task Manager. Moreover, if you make several calls to xlstart and xlopen, then there are multiple processes that are left running.