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)
MessageBox("File not found !")
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:
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
Loop Until Not sh.IsRunning
If sh.ErrorCore <> 0 Then
// error occurred
// deal with the result
MessageBox("File not found !")
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.
// 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 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.