I have been spending hours trying to make a single ASYNCHSHELL line run without success.

Original line called an executable directly with 3 parameters.  Kept getting message that file could not be found.    Then made a batch file to call the executable with %1-%3 for parameters.  Still had no success. 

To help diagnose, I reduced things to a batch file with one parameter passed in as %1.  No success. 

Made many variations with @CHR(34) and multiple variables and strings on all of the trials above, without success. 


Finally I tried @SHELL vs @ASYNCHSHELL for the batch file with the %1 and it works fine. 

If @ASYNCHSHELL does not have to pass a parameter, it runs the batch file with no problem, but "cannot find file" when a parameter is passed.

var vOK as Int
var vSSPath as String
var vPArameter1 as String

vSSPath = "C:\Sesame\Utilities\SensibleSolutions\View.bat"
vParameter1 = @Database

//This line always fails, message that file cannot be found
vOK = @ASYNCHSHELL(vSSPath + " " + vParameter1)

//This line runs OK, (with black DOS box)
vOK = @SHELL(vSSPath + " " + vParameter1) 

I am too close to this right now, it is probably something really basic, but I am burnt out, need to walk away for a while.  While I am walking, perhaps someone else will see the obvious that I have missed ....

Any ideas on why @ASYNCHSHELL "cannot find file" ?

Thanks Steve, but I am not working with an "associated" target file.  I am working directly with the executable and also passing in parameters.  More information about this can be found in the Programming Users Guide, pp 150-152.

And yes you are correct, I do get Inside Sesame, but the article does not help me out here.  The article does a good job of explaining how this will eliminate the DOS black box.  Which, if you see in my message above is coming up when  I use @SHELL, but using @ASYNCHSHELL instead hangs, because it "cannot locate file". 

What is even more frustrating is that the error message is very informative, it gives the EXACT names of the executable, and the parameters that I am trying to pass.  So I know that the variables are translating properly, but ASYNCHSHELL seems to be having trouble parsing the executable from the parameters.  It is like it is using the entire string as if is was one executable filename.

From what I can see, I have tried every combination of creating the string for execution, but I must have done something wrong.
.

Sesame Programming Guide has examples on bottom of Page 151 showing an executable with parameters and a batch file with parameters.  I have tried both with no success.

Documentation says it is same as @Shell, but does not need to wait for completion to return contol to Sesame.  No mention that parameters are not allowed, or that anything is different in syntax from @Shell.  And again, note that the @Shell versions are working with exact same syntax.

I suspect we will have to wait to hear from Mark and Erika on this one.

I am also looking to use @AsynchShell without using batch or wsf files.  If I need batch/wsf files then I have the distribution problems associated with network envirnoments,  Not insurmountalbe, but more problems to deal with and more expense for my clients.

Hmmmm, you are giving me some good stuff here.  I did not see the distinction that you are pointing out re a "target" vs. an executable.  But reading the documentation seems to imply that both will work.

On page 151: Quote:


And since you forced me to take a closer look at the examples, there are no @AsynchShell examples that pass parameters.  The only example are an executable and a target.  Looking at the details under the concatenation in the examples, I see that you are correct.  I took each added section as a parameter, and now see that they are a single string for a "target".

So what I need is an example of @Asynch calling an executable and passing parameters.  Is a batch file a "target"?  Batch files can take parameters, so this is an example of a target with parameters, not different from an executable with parameters.

Thanks again for pointing out that the examples were not what I thought they were.  It's good to have another set of eyes looking over your shoulder.

This is the Sesame code.

vAction="C:\Sesame\Utilities\SensibleSolutions\SesameTableView.exe /DatabaseTableView=tblRooms /MaximizeView=1"
WriteLn(vAction)
vOK=@AsynchShell(vAction) 

When this is run, the cmd.exe black box stays open. Then I can manully close it with "X" in upper right corner.  Then I get message that fille cannot be located. When that window is closed, then control comes back to Sesame.

This was copied from the WriteLn and pasted into Run....

C:\Sesame\Utilities\SensibleSolutions\SesameTableView.exe /DatabaseTableView=tblRooms /MaximizeView=1 

When that is executed, there is no sign at all of the cmd.exe black box. Control comes back to Sesame immediately.

An image of error message, also showing WriteLn results can be seen here.  At this point I suspect this may be happening because of the "=" character in the paramaters that are being passed.  The executable program takes its paramaters in the format /param1=value /param2=value, etc.  Could have from 0-10 parameter values.

But it is strange that running manually from command line and running from the Run window causes no problem.  So iit would seem that perhaps AsynchShell is using "=" as a delimiter before sending string on to Windows?

I should also mention that once the cmd.exe black box is closed and the error message is removed, that the executable does in fact run with its passed parameters.

I can also send the executable if you want to see this firsthand.   But will need special instructions to create proper environment, etc.

Bob,

I've looked at the source code. @ASynchShell does not accept parameters. It can run an exe. It can pass a file (such as an html file or Word doc) to the operating system, which will then attempt to open it using the file associations.

If you want to do this, you can try using File I/O to write a bat file with the necessary parameters, then use @ASynchShell to run the bat file.

Well I made the batch file and used @AsynchShell() to run my executable.  The parameters needed are built into the batch file that is dynamically written.  The batch file is written, used with AsynchShell, and then deleted.  The code to do that follows here.  Error controls will be added in once basic commands are finalized.

var vFileHandle1 as String
var vContent as String
var vShellFile as String

vContent = vAction	    //Defined above
vShellFile = "C:\Sesame\Utilities\SensibleSolutions\TableFullView.bat"

//Start Routine =======================
//Delete file if it exists, should have been deleted at last run
IF FileExists(vShellFile) THEN {
	    FileDelete(vShellFile)
	    }

//Create File =======================
vFileHandle1 = fileOpen(vShellFile)

//Write to File =======================
FileWriteLn(vFileHandle1,vContent)
FileClose(vFileHandle1)

//Run Utility File =====================
vOK=@AsynchShell(vShellFile)

//Delete File when done ===============
Loiter(500)	    //Need delay for batch file to run.  Del %0 will not work.
FileDelete(vShellFile) 

End result is that the executable is run with the necessary parameters.  No hanging, but.....two things now:

1.  I needed to add a Loiter() command to prevent deleting the batch file before it was done.  I guess I could use @Shell() so control to Sesame is delayed, but then I would see the black box........ But Wait!......
2.  The black cmd.exe box still comes up with the @AsynchShell()

Making progress in small steps.  So how do I make BlackBox go away?

What if Windows Script was run instead of batch file? Would that make black box go away?  Since WSH or VSH (Visual Basic Script Host) file is also simple .txt file, it could be written using I/O. I believe windows script is run in pure Windows environment while batch file requires DOS Shell. Just a thought and I could be a way off on this one.