ExcelApplicationScope taking over and "closing" manually opened Excel

Help
1

Scenario:

ExcelApplicationScope seems to be hooking up to opened Excel process if one is available and taking over it.
This leads to leftover Excel processes as well as unexpected file “closures” in Attended/FrontOffice situations. The files are not really closed and changes are preserved, but to a standard user they are inaccessible without knowing specific steps and would most likely lead to losing any unsaved progress due to killing the Excel process via TaskManager.

In addition, if robot takes over existing Excel process from the user, the Visible flag is ignored (or cannot be set) and Excel files will be visible for as long as robot uses that same Excel process, which in a loop might lead the user not being able to use the computer even if all actions should be in the background.

Steps to reproduce:

  1. Ensure no Excel process is running through TaskManager.
  2. Manually open an Excel file (file1).
  3. Run a workflow with ExcelApplicationScope that operates on a different file (file2) with at least 1 write activity (for confirmation of performed operation).
  4. Observe file1 getting “closed” when ExcelApplicationScope finishes.
  5. Observe file2 operations (read/write etc.) performed normally.
  6. Observe that an orphaned Excel process is still running, but is not accessible via normal means for user (alt+tab doesn’t show, no icon on taskbar etc.).
  7. Observe that file2 handles are properly released (i.e. delete/move/rename the file).
  8. Observe that file1 is still in use (i.e. delete etc. produce a file in use by another process).
  9. Observe that trying to manually open file1 produces a NEW Excel process, without actually opening the file (situation same as with point 7, but now 2 orphaned processes).
  10. Wait for the operating system to clean unused file handles and orphaned processes.
  11. Observe file2 opening “on its own” (~30 seconds).
  12. Close file2.
  13. Observe that no orphaned Excel processes are running.

Current Behavior:

Robot “takes over” user used Excel process and takes it over, “closing” all opened files when ExcelApplicationScope finishes.

Expected Behavior:

Robot runs ExcelApplicationScope in a new Excel process, unless specifically passed a WorkbookApplication to hook up to.

Studio/Robot/Orchestrator Version:

Last stable behavior: Unknown
Last stable version: Unknown
OS Version: Windows 10 Pro, Server 2016
Others if Relevant: (workflow, logs, .net version, service pack, etc):
Reproduced on Office 2016 and Office 365
Excel package 2.5.0, 2.5.2

Sidenote

Same as with the other issue reported here , the issue could be controlled if there would be a setting to force ExcelApplicationScope to run in a new Excel process instead of hooking up to an existing one.

2

@loginerror
As promised, just reproduced this with:
image
image
EatUpExcelTest.xaml (5.9 KB)

As also noted - 2018.4 (or actually any Studio version), according to activities documentation, SHOULD NOT impact how the activities (especially non-core ones) work and if it really does, then something is seriously messed up somewhere.

3

Thanks, I managed to reproduce with Visible property unchecked (should have figured it out myself).

5

Just checked with Visible = True, worked the same on my end (as in - still “swallowed” the Excel that was previously open).

EDIT:
Correction - no it didn’t. It competely closed it.

EDIT2:
Ok, this is pretty inconsistent, will need more testing.

EDIT3:
Ok, so this is pretty funny (well, not really, but it made me chuckle a bit):

If Visible=True:
If file is in EDIT mode, it will work normally and not close it.
If file is in PROTECTED mode, it will be completely closed. No leftover processes or anything like that, just the whole excel process closes.

If Visible=False:
If file is in EDIT mode, it will get “swallowed”.
If file is in PROTECTED mode, it will be completely closed (same as with Visible=True).

If you have a combination of files open, some in edit and some in protected, weird things happen @_@.

I don’t have time to test it fully, but I’d say that for the clarity (and to avoid over the top test scenarios like “if the user has 2 protected excel files, 2 edit mode excel files and 2 csv’s opened in excel, one of which is on shared drive, and Visible=False while having AutoSave = True…”) ExcelApplicationScope should get a public flag property - AlwaysRunInNewProcess and just be done with those weird interactions.
If someone will need to switch it off for a tight loop, he does that on his own risk. Now the risk is still here, but we can’t control that risk.

2 Likes
6

Just to close the loop here, the modern Excel activities handle this much better, so the issue got solved in those.