Hello,
How to run a console application?
I tried this without result:
Var xpfile As FolderItem = SpecialFolder.Library.Child("x").Child("y").Child("destfile.app")
If xpfile.Exists then
if xpfile <> Nil then
sh.Execute("open -a " + xpfile.ShellPath)
end
else
MessageBox("File not found !")
exit sub
end
First off you have your nil and exists check the wrong way round. if xpfile result is nil, xpfile.exists will throw a nil object exception. Equally you can get a nil object exception from items like this:
if the x folder doesn’t exist or the y folder doesn’t exist they will generate a nil object exception.
That I didn’t think console applications had .app on the end of their name? I don’t currently have a licence to build them so I can’t check, but as far as I can recall they’re not application bundles?
You would run it as follows:
sh.Execute(xpfile.ShellPath + " any parameters here")
Are you expecting any results from the command line tool?
Var xpfile As FolderItem = SpecialFolder.Library.Child("x").Child("y").Child("destfile")
Var sh = New Shell
sh.mode = 1
sh.Timeout = -1
If xpfile <> Nil And xpfile.exists then
sh.Execute xpfile.ShellPath
Do
sh.Poll
Loop Until Not sh.IsRunning
If sh.ErrorCore <> 0 Then
// error occurred
Else
// deal with the result
End If
end
else
MessageBox("File not found !")
end
We’ve also used other shell modes to read data from the console app before it completes. Which allowed us to produce percentage completion information as the console app proceeded.
To elaborate a little on what @Sascha_S said, this is safe because of the use of “and” instead of “or”, which allows Xojo (and most but not all languages) to immediately know the IF statement will be false and not bother testing the other condition(s).
Had this been OR, then both conditions would need to be tested.
And some languages are not optimized enough and will test all conditions even after finding the preceding condition(s) will cause the whole IF to be false. So you may have this idea because of a problem with a prior programming language.
It is using Synchronous mode (and could even be Asynchronous), but using the Do … Loop Until loop with the sh.Pool call allows the UI to remain responsive while the shelled task is executing. It also means that you’r function doesn’t move forward until the CLI tool finishes.
In fact - and I get fussed at about this religiously - I also add a call to App.DoEvents(5) for even better responsiveness.
Do
App.DoEvents(5)
theShell.Poll
// handle shell stream data here
Loop Until Not theShell.IsRunning
The reason that this works is that my use of a Shell in this manner is more Functional programming that OOP, so the run order is consistent and doesn’t interfere with other things going on in the parent UI app to worry about recursion. That also works in a Thread as long as you’re not updating the UI from within that loop.
Quite correct. What I should have said is that as soon as the statement is known to be true or false, it can “short circuit” the rest of the tests. In the context of the original question, it was known to be false after testing the first condition so the second is not evaluated.
In your example, it is known to be true to there is no need to test the other conditions.
I believe this is known as “short circuit” in compiler terms, and it behooves oneself to know if the language in use performs it or not.
I understand the point and it is well made. However, for our purpose compared with the fact we are running upto 124 cores at full pelt for days a few % for the monitors are not a major issue.
I’d love to see what a Mac with that many cores would look like
I have no idea what the cost is with the Windows Shell, but if it’s like the Mac shell, you could use the savings towards what you’re actually doing, instead of… what ever it is that Xojo is doing. 5% CPU usage over days could add up to something significant.
Ha… I doubt we’ll ever see one, Apple hasn’t
built server grade hardware for a long time, I’m not even 100% they build “Professional” grade hardware anymore with everything soldered in and un-replaceable.
They still support x86 for the time being, but it’s days are numbered.