Shell DataAvailable best practice - scope issues?

Hi folk,
I’m a little stuck on this one. I’ve been using Web apps to control shell processes for years but with 2.0 I’m struggling to understand some bugs.

I have an interactive shell that completes a process and fires a dataAvalable event. The issue is that this event often doesn’t catch all the data coming in. But never fires again. Ie, I’m reading a WMIC path in windows 10 and might get half of it. If I put a breakpoint in my code then it completes fine and I can read the entire response. This seems new to Web2 and my thought was to fire a timer from the dataAvailable event to wait a while and then run a readily, but this doesn’t work either. My timer (initiated in code) never fires as I believe it’s going out of scope before it fires for some reason.

Has anyone had success in this area or tell me what’s changed between Web1 and Web2 in this space? I seem to becoming up against a number of issues that I’m hoping are just me… controls going out of scope quickly seems to be the biggest issue.

Have you tried ShellMBS class in MBS Xojo Plugins?
Or the WindowsWMIMBS class in our plugin?

Hi Christian,
Yes I use your plugins quite a lot, but I don’t believe your shells supports interactive modes like Xojo does it?
Some of my apps are initiating a program and then dataAvailable events will fire continually. Some need further interaction or injection of commands. It seems on Web 2 at least that while the intractable shell works for a short while, it quickly falls out of scope and further events don’t fire.

What kind of timer are you using? With Web2 there are 2 types of time. Web Timer and Server timer. Apparently, when you are migrating a project the IDE is not always showing the switch to change the time type.

Hi Jeannot,
Yeah, did catch this one, I basically create the timers manually rather than trying to import. I’m not 100% certain what the difference between the client v’s server timer is. At the moment, I’d love to rely on the data event actually continuing to fire, but I guess a timer created is not the end of the world, it just means a bit messier code.

I’ve tried creating a timer (not webtimer) in code, This works in some of my methods using .calllater as a delay, but doesn’t ever seem to fire if I initiate it in the dataavilable event. Another one of the quirks that I just don’t understand with Web2. Could be a bug, could be a feature;)

my plugin shell is interactive. Just run bash or cmd.exe and feed it commands.

sounds like a bug to me. I suggest you create a feedback case. No one should need to wait for data available at my understanding, either the data are there, or they aren’t.

Maybe I’m not understanding correctly Christian, I’m having trouble getting an interactive shell under web. The example you have (shell under utils) seems to have an error and doesn’t run.

What I have is:

Dim s As New ShellMBS

s.Execute “cmd.exe”
s.Wait 5
s.writeinput (“cd c:\james files\test folder”)

Dim output As String = s.ReadOutput
Dim errors As String = s.ReadError
Messagebox output

All I seem to see is the response from the cmd call, writeinput doesn’t seem to have an effect?

Thanks again Jeannot, I guess my data is asynchronous, I will need to wait a small amount of time it won’t be immediately available. I guess what I’m seeing though is data available firing maybe once and then never again.

Have you checked the many posts about webtimers? Perhaps this one helps you, particularly Greg’s responses. https://forum.xojo.com/t/question-about-webtimer-in-web-2-0/59640

A great help. I still don’t know why timer exists still then. Maybe it’s just so callLater has a home?

This is not just missing a return character on the end?

1 Like

Seems to work now Christian, I thought it was similar to Xojo’s writeline where the return char was automatic. I don’t seem to be able to call multiple command simultaneously though, I need to add delays between that isn’t the case with the Xojo shell.

ie:
s.Execute “cmd.exe”
s.writeinput (“cd c:\james files\test folder” +chr(10))

Should work right?

I would expect this to work. Otherwise it’s not bad to have the cmd first run and wait a bit till it’s ready and prints the prompt.

Wouldn’t it be safer to use EndOfLine rather than chr(10)? Or does the shell requires chr(10) (that is, the Unix EndOfLine)?

I would expect Chr(13) as that is char code for return key.

And the Enter key is chr(3), for example on Mac. But keys don’t always count as official characters…
Chr(10), chr(13), chr(13)+chr(10) are a real mess: operating systems have defined and used some in the past, have kept some for historical reasons (but far not all), have eventually changed some in their life or have made weird mixes or changes.
And then, different components (like the Shell vs a GUI app vs text fields) use either a legacy character, a current version or some sort of unexpected values.
Go figure how to make it right without trials and errors… :man_shrugging:

Sorry guys, you are right. I have actually been use it endofline. I was a bit lazy typing out my post it seems as I was away from dev pc.
It’s just a little painful having to add delays. I’ve been wrapping up individual calls to the shell class in their own methods and calling them with a delay between but this seems a little kludgy compared to web1 where I could call them all sequentially.

First of all, the regular old Timer class hasn’t changed between web 1 and web 2.

I did notice however that in your code example above that you are declaring the timer in the same method that you are using it. Using any interactive Shell, you must declare it as a property of a class or module so it won’t go out of scope.

Also, remember that the Shell.DataAvailable event can introduce reentrance issues. You’d be better served by just reading the data into a buffer in DataAvailable and then using a Timer to process the data later (even if 1ms later).