Duplicate json Files Appearing in SeeShell Browser

Other
1

Whilst running commands using the scripting API, I have come across something a bit unusual.
In this script, I have run ‘GoToSCDSite’ and ‘AboutUsPage’ (in that order). There’s duplicates for these macros with the random string on the end of each (as per the screenshot). These are .json files which are stored where my macros are stored (but are hidden files). When I double click on one, they’re unable to find any images I’m referencing (presumbly this is a path issue). I’m using SeeShell Browser.

What are the purpose of these files?

macro_json
macro_json.PNG331×731 13.5 KB

Another thing to note, is that the ‘AboutUsPage’ macro doesn’t play after the ‘GoToSCDSite’ macro. Below is my code for this script.

$seeShellObject = new-object -ComObject SeeShell.Browser
$seeShellObject.open(10)

$seeShellObject.Play("C:\Users\XFU59478\Documents\SeeShell Demo\Macros\GoToSCDSite.see")
$seeShellObject.Play("C:\Users\XFU59478\Documents\SeeShell Demo\Macros\AboutUsPage.see")

$seeShellObject.close(10)
2

These are temporary files that should be hidden, but are still shown on some systems. It is a purely visual issue and does not affect SeeShell. In any case, the issue will be fixed with the September update.

As workaround, you can delete the .json files in the /macro folder. These are all temporary files.

3

For the second question, what does “doesn’t play” mean? => Does the second macro not run at all? Or does it run and you get an error message?

I tested with a very similar macro and all worked fine:

Write-Host "Hello SeeShell Browser User!"

$comObj = new-object -ComObject SeeShell.Browser

[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") 

[System.Windows.Forms.MessageBox]::Show("Click OK to start the SeeShell Browser")


$comObj.open(10)

$comObj.Echo("Playing D1")

$i = $comObj.Play("C:\Users\ts\Documents\SeeShell.Browser\macros\D1")

$comObj.Echo("Playing D1B")

$i = $comObj.Play("C:\Users\ts\Documents\SeeShell.Browser\macros\D1B")

$comObj.Close(10)
4

After some further testing, it seems AboutUsPage macro returns a status code of -1 (timeout). However the macro never starts playing during this time, SeeShell Browser sits there doing nothing visible to me. A status code of -1 is also returned during the close command, however SeeShell does close upon this command being executed, though I’d guess the result of the code in this instance is due to the previous -1.

I agree it seems odd, I just followed the examples on GitHub, but it seems something has gone wrong.

5

I’ve done even more testing and I think I’ve found the issue. The second macro didn’t have an open command. When I added an open command, the script ran without issue, multiple times. Is there a requirement for macros to have an open command at the start?

I made the macros in this way because GoToSCDSite goes to a website (which will be reused again and again in the batch of tests I need to create) and then AboutUsPage goes to the ‘about us’ section of the site. I want one script to be one test (so each script will be an independent test), calling macros that need to be played. The reason for this is that if a screenshot needs to change inside GoToSCDSite macro, I only have to change the screenshot for that one macro. If every macro I create must include steps to get to the homepage (and validates it), it means when the screenshot changes, I will need to change the macro in many places.

6

Ok, now I understand the issue…

Short answer: By design, there is no need to add an Open command.

The longer answer is: The need to use a open command is caused by the same regression bug that causes the “browser refresh when second play starts” issue discussed here: SeeShell Scripting with C# - #9 by admin - Other - UI.Vision RPA Software Forum | Discuss RPA Automation, Selenium IDE and OCR API Text Recognition

=> We are working on a fix, and it should be available by Monday the latest. I will update this ticket once we have something to test.

7

We just released V3.2.1.2 of the SeeShell Browser, which should fix the issue discussed here.

The updated installer also includes a new Powershell test file SeeShell-ManyPlay-Demo.ps1. It runs three macros one after the other, each continuing where the other macro has left off.

Of course, please let me know if this version does not solve the issue.

8

I couldn’t see the PowerShell script you mention but I know the patch fixes my issue (I’ve tested it with my own PowerShell script). Cheers!