Running a separate console app from within Xojo

That is exactly what I did. I created a new shell in the open event of the window, and the window stayed open at all times. The shell property was a property of the window, not the open event. But when I tried to use a button associated with that window to feed new commands to the shell, the shell was no longer running. Indeed, it appears that the shell went out of scope as soon as the open event finished.

depending on the code

if you did, in the open event

dim s as new shell

then the shell is gone at the end of the open event because you only created a local variable

however if the property on the window is named “mShell” (for instance) and you do

dim mShell as new shell

you STILL have just a local variable - it just happens to have the same name as your property

but I can’t tell which based on just the conversation which you did

I have a window property called mShell of type shell declared.

In the open event, I have

mShell = New Shell mShell.Mode = 2

Does the mShell = New Shell create a new local variable even though I did not include “dim”. I assumed not, but I am begging to wonder if the problem is “New”. But if I leave out the line, the next line throws an error.

So I am confused!

No
That would create an instance that lives until that window is closed OR mShell is set to nil

But that doesn’t start the shell executing either

That might explain why when you tried to do something it says “not running”

I realize this only creates an instance, but then I execute the following lines

path = f.ShellPath+"/stockfish_8_64" output_text.text = path+endofline mshell.execute path +" uci"

and am able to collect the proper response indicating I have started the process and the shell is running and waiting for input.
But then when I try to execute the following statements in the action event of a button in the same window,

if mshell.IsRunning then mShell.Write(sinput) mShell.Write(Chr(13)) else msgbox "The shell is no longer running! most unfortunate!" return end if

I get the “no longer running” message. That is why I am confused. Again, mShell is a property of the window with public scope.

Some commands run then the app quits and to run another command you run the app again
That almost seems like what stockfish is doing

Others literally sit & wait for you to type in another command and then they execute that command and wait for the next one

I’d have to download stockfish to see if it really is acting in a mode that requires interactive mode
It may not

Here - try this (you will need to adjust paths to stockfish etc)

http://great-white-software.com/miscellaneous/stockfish.zip

Your version works very nicely (after I changed the path to the stockfish app) and demonstrated how to monitor output without using a timer! The key statement for me was

and sending the data to a method called datahandler which simply appended the output to the textarea. I conclude that my use of a timer to append the data caused the shell to go out of scope. Your method is far more elegant and keeps the scope inside the window. I think I can take it from here and I appreciate your taking the time to demonstrate how to do this.

Thanks!

In interactive mode you should use the DataAvailable event
And to do that by creating an instance etc you have to use addhandler

Or just drop an instance on the window, set its mode to interactive and implement the DataAvailable event on that instance on the window which is a tad simpler

The net effect is about the same either way

I like your single statement method better. Cleaner and easier to debug.

Oh doing the same with an instance on the window wouldn’t change how the code works
Just how it gets set up (and fwiw dropping an instance of a shell on a window is slightly easier as there is literally less for you to do)

In the sample I gave you the event hander HAS to be hooked using addhandler

That sample would be about 2 minutes worth of work to take the property out and put a shell instance on the window
And the “data handler” code would simply go in the data available event of the instance on the window

They are basically two different ways to achieve a functionally identical result

This is actually one of those I would say would be a good exercise for the reader to enhance their understanding of the subject :stuck_out_tongue: