Front Call: execute vs shellExec vs launchURL

The first thing you should note about the Table is the last column and the fact that only the launchURL Front Call is available with Genero Browser Client (GBC).  It is also the only one available with Genero Mobile for Android (GMA) and Genero Mobile for iOS (GMI).  Therefore if you are interested in producing something that will work across all our front-ends, then the launchURL Front Call is what you should prioritise.

launchURL

The launchURL Front Call takes two arguments.  The first of which is the URL or URI.  A good way to think of this is, this is what you can type into the Address Bar of a Web Browser, or if you know HTML what can be the value of the href attribute value of a hyperlink. 

A quick example is to try the following …

CALL ui.Interface.frontCall("standard","launchURL","https://www.4js.com",[])

and you will hopefully see the 4js.com web page open up in your default web browser.

What most people don’t realise is that URL or URI can be used to open more than just a web page.  For example try these

CALL ui.Interface.frontCall("standard","launchURL","mailto:",[])

and you should hopefully find your default mail tool open ready to send an email. With this one, replace 1234567 with your phone number …

CALL ui.Interface.frontCall("standard","launchURL","tel:1234567",[])

… on a mobile device it will be ready to call you, on your desktop it might start up Skype or FaceTime or similar, ready to call that number on the press of a button.

The first part of the argument before the colon is known as the scheme.  What application is launched depends upon the scheme value and what application has been registered to handle that scheme on that device.

One scheme that you might not be aware of is the file: scheme.

CALL ui.Interface.frontCall("standard","launchURL", "file:///C:/Program%20Files/FourJs/gdc/license/english.txt",[])

So to open a file you might use launchUrl with http(s) scheme if the file is available via a Web Server, or you might use file scheme if you know where the file is on the network and you know it is a consistent place for the expected users i.e a shared network drive on a private network.

shellExec

The shellExec Front Call was the popular Front Call to use with applications that were 100% GDC.  The best way to understand it was for the parameter to be a filename and what happens if you find that file in Windows Explorer and double-click on it.  That file will be opened in the default application registered on the front end to open that particular filenames extension e.g. .doc would typically be opened by Word, .xls would typically be opened by Excel, .pdf would typically open an Adobe PDF reader.  I’ve given the examples using Windows, Linux and OSX would have similar behaviour.

We have no control over the application used, it will be what was registered on the device, so .csv might be opened in Excel, it might not, depending on how the extension .csv had been registered on the device.  On Windows 10 you can see this by typing default app into the search bar and hopefully it offers you a program labelled “Default app settings”.  This will list the extension and filenames opened, if you look closely you should see .gdc registered to Genero Desktop Client and the likes of .4gl and .per registered to Genero Studio Version Selector if you have those products installed on that PC.

The shellExec Front Call is typically used in conjunction with FGL_PUTFILE.   You create a file on the back-end server using one of START REPORT TO FILE, UNLOAD, base.Channel etc, and then copy the file to the front-end using FGL_PUTFILE, and then use the shellExec front call to open that file.  The key thing to note is that you have to know where on the front-end the file was placed so you will typically use an absolute position.  If you use a relative position then it is relative to the working directory of the GDC executable which may vary between instances.

Instead of double-clicking a file in Windows Explorer, if you right-click on it, a number of actions will appear.  Typically the action at the top will say Open and be bolded.  This is the default action and this is the action that will occur if you double-click.  The other actions can be used as a second parameter to the shellExec front call.  Typically Print is an option and so if you pass “Print” as the second parameter to the shellExec front call, then instead of opening the file using the default application, it will start the Print process, typically bringing up the Print Dialog box.

shellExec used to be the way you played sound files. You should be aware that there is now a dedicated playSound front call that you should utilise to play audio on all our front-ends.

execute

The execute Front Call I like to say is the equivalent of typing in a command at the Command Prompt window (or equivalent for Linux or OSX).  Typically you will find that this command begins “cmd /C” .  For example, this forum post  illustrates the use of execute to see if a file exists on the front end.

LET cmd = SFMT('cmd /C if exist "%1" (exit 0) else (exit 1)',filename)
CALL ui.Interface.frontCall("standard","execute",[cmd,1],[ok])

The second parameter 1 means to wait for the command to finish and the exit status is written into the ok parameter.

As in the forum post, I was able to fine tune the correct command by typing and executing the proposed parameter at the command prompt and then checking %errorlevel% to see the value returned. (Note: spaces are always fun in Windows)

C:\Program Files\FourJs\gdc\3.20.11\bin>cmd /c if exist "gdc.exe" (exit 0) else (exit 1)
C:\Program Files\FourJs\gdc\3.20.11\bin>echo %errorlevel%
0
C:\Program Files\FourJs\gdc\3.20.11\bin>cmd /c if exist "gdc2.exe" (exit 0) else (exit 1)
C:\Program Files\FourJs\gdc\3.20.11\bin>echo %errorlevel%
1

Note also that if a filename is specified relative it is relative to the working directory of the GDC executable, just like shellexec.  So typically any filename portion of the parameter should be specified absolutely.

Summary

One final point at the end, you maybe asking why don’t we implement shellExec and execute Front Calls on front-ends other than GDC.  The reason is that web browsers and the mobile operating systems don’t allow you to.  Ask yourself what a malevolent web-site or app could do if it could do the equivalent of execute and shellExec front-calls.  The equivalent of the execute Front Call could be used to delete files on your work station.  The equivalent of shellExec could be used to paralyse your front-end.

So to wrap-up, use launchURL where possible, only use execute and shellExec if you are 100% GDC.  Understand that launchURL is more than simply launching a web page in a browser.  For each Front Call learn what the equivalents are, and experiment in the browser, Windows Explorer or Command Prompt application to come up with the appropriate parameter syntax.