AnsweredAssumed Answered

Waiting for Shell Execute Returns

Question asked by a.fanet on Aug 23, 2018
Latest reply on Aug 24, 2018 by a.fanet


Posted a question similar to this about a month ago and I'm still experiencing issues trying to solve this, so I'm going to get really specific here.

 

I'm in the process of moving an old file from 32 to 64 bit and have to replace a plugin's functionality. What this plugin did was execute an external application and wait for the application to return. The value returned on the command prompt was then returned to FileMaker and stored in a script variable. Here's a good example here from one of our 32 bit file custom functions. I know that this open dialog functionality is available through a majority of the plugins available out there today, but we have other, way more custom apps that would require this waiting functionality to be completed so I'm using this one for simplicity purposes.

 

 

Top line representing the command sent to the command prompt set to variable "comm", second line being where it is called. Trim and getRow are functions used to organize the return value RunApp is the plugin function with parameter "comm" (the command sent to the command line).

 

Overall our example command would look like this

 

     F:\SR1bin\2.6.5.010\Tools\openfile.exe "TEST" "test.txt" "All Files (*.*)@*.*" 1 ""

 

The executable file openfile.exe then parameters. Put this into a normal command line prompt and you get the desired results.

 

 

Double clicking on test.txt will return the file path to the command prompt.

 

 

So as you can see the command prompt is waiting for the value to be returned, and our plugin was doing the same on our 32 bit file. What was going on was that a FileMaker script would wait for that command to terminate before grabbing the return value and storing it in a variable.

 

 

Then that variable could be used in the rest of the FileMaker script.

 

So when trying to replicate this behavior using 3rd party plugins, the call would be initiated, none of our executable windows would appear and then FileMaker would hang. This was true for pretty much every plugin we tried, it included BaseElements, 24UToolbox, 360 ScriptMaster, troi plugin, etc... I just couldn't replicate the behavior

 

Probably the closest I got to solving this was using MonkeyBread's shell execute script steps. Here's the progression used below.

 

 

The problem here however was that each Pause/Resume Script step would change the active window to the FileMaker window, meaning that if a user is typing in input to our executables window, the pause/resume would take the user off of the field they're typing to and back to the FileMaker window. I also have gone and tried to use alternatives to Pause/Resume script (using the Get ( CurrentTimeUTCMilliseconds ) loop, MBS( "Time.Sleep" ), Base_Elements(Pause) ) but these were causing hanging on my executables.

 

I guess I have 2 questions then.

  • Does anybody have experience with shell command waiting that might have an idea why I can't replicate the previous plugin? Does it have to do with the executables we have developed, and if so why do they work when called independently from the command line?
  • Is there any possible way to directly replicate the Pause script step without changing window context in FileMaker?

 

I'm going to throw one more thing down here and attach the file. When we created our old plugin, we used a plug-in creation template provided from a 3rd party. That plug-in is now unavailable for generating 64 bit plug-ins, however we do have the source code for the RunApp plug-in function (written in C++, makes complicated to write over to Java for ScriptMaster). About half of it is a debug writer, but the rest initiates the command line with the command from FileMaker while waiting for the return.

Attachments

Outcomes